[SOLVED] Converting the c++ VertexArray example (TileMap) to pySFML

[C with a C]

I was creating a small test script to convert the example tile map to python, but I came across a problem. This is my code so far (it can contain other errors, I haven't made it work yet):

01      vertices = sf.VertexArray(sf.PrimitiveType.QUADS)
02
03      def createVertices(tiles, w, h):
04              global vertices
05              vertices.resize(w * h * 4)
06
07              for i in xrange(w):
08                      for j in xrange(h):
09                              tile = tiles[i + j*w];
10
11                              tu = tile % (tileset.width / TS)        # TS is tilesize
12                              tv = tile / (tileset.width / TS)
13
14                              quad = vertices[ (i+j*w) * 4 ]
15                              print quad                                                     
16                      #       ^ <sfml.graphics.Vertex object at 0x0225A1F0>
17                             
18                              # positioning
19                              quad[0].position = sf.Vector2( i*TS, j*TS )
20                      #       ^ TypeError: 'sfml.graphics.Vertex' object does not support indexing
21
22                              quad[1].position = sf.Vector2( (i+1)*TS, j*TS )
23                              quad[2].position = sf.Vector2( (i+1)*TS, (j+1)*TS )
24                              quad[3].position = sf.Vector2( i*TS, (j+1)*TS )
25
26                              # tex coords
27                              quad[0].tex_coords = sf.Vector2( tu*TS, tv*TS )
28                              quad[1].tex_coords = sf.Vector2( (tu+1)*TS, tv*TS )
29                              quad[2].tex_coords = sf.Vector2( (tu+1)*TS, (tv+1)*TS )
30                              quad[3].tex_coords = sf.Vector2( tu*TS, (tv+1)*TS )

On line 14 I get a vertex back from that assignment while in the example they get an array of vertices. I'm a bit confused. How do I get the quads then?

[Laurent]

Your line 14 is not the same as in the tutorial. The tutorial takes the address of the indexed vertex, thus getting a pointer to the portion of the vertex array that defines the quad (because vertices are stored contiguously in memory). I don't think you can do the same in Python, so a simple workaround would be to precompute the index of the first vertex of the quad instead of its address.

index = (i+j*w) * 4

vertices[index + 0].position = ...
vertices[index + 1].position = ...
# etc.

[C with a C]

Ah, that does work. Thanks a lot.

Just out of curiosity...

... thus getting a pointer to the portion of the vertex array that defines the quad (because vertices are stored contiguously in memory).

... is this a difference in how python handles memory, or how pySFML handles VertexArrays or memory?

[Laurent]

This is a language difference. As far as I know, Python can't access raw memory as C++ can. Python is an interpreted language with garbage collected memory.

Each language has its own way of doing things, you can't always translate code from one language to another directly.

[C with a C]

Thanks for clarifying. I wasn't expecting subtle differences from under the hood like that one.

By the way, the frame rates just go through the roof with this! Way to see how the weight of each draw call adds up.

[C with a C]

Well... it goes through the roof only while I'm not doing anything in the test script. As soon as I tested with my actual program the frame rates are actually worse with 1 draw call (~20fps) than they were before with 3600 draw calls (~50fps).

I was using an 80x45 image (size of my tile grid) to store the background colors in pixels (the associated sprite with ratio raised to the tile size, so it fills the screen), and one sprite to draw each of the foregrounds (glyphs - as in a roguelike).

Now, at every frame I'm changing the vertex colors and their texture coords. I raised the frame rate to ~60 by testing if the color and tex-coords are different, and change only if they are. I don't know if there's a better way to do that...

I was hoping to be able to get the frame rate at least over 100. By the nature of a traditional roguelike, I'll have to draw all those tiles every frame.