Each chunk represents a static part of the map. So it's set once at first, and never ever edited again.Correct
The visible chunks are picked and drawn. Since the visible part of the map can move (or we wouldn't need culling in the first place), it means we have to translate the chunks to their correct positionYou can (and should) create the chunk's vertices directly at their final position. For runtime you can them use sf::View to scroll the map.
VertexArrays are not transformableNot directly, but you can pass a sf::Transform when you draw a vertex array.
If not, would it even work ?That's more or less what SFML does internally as an optimization. As long as you draw small entities with the same texture, SFML pre-transforms them and batches them inside a bigger vertex array.
which is the best practice ? I'd say moving the view, as it's semantically more correct (and eases the placement of other layers).Yep.
Can two quads in the VertexArray overlap ? If so, is the last one on top ? Or is this undefined ?They can overloap, and the last one should be on top. I don't know if it's strictly defined in the OpenGL spec though.
If a quad's vertices aren't axis-aligned, but still define a correct rectangle, will this rotate the texture correctly ? Can this be used to draw rotated (or any other linear transformed) sprites ?You're right. As long as your quad looks like a rectangle it will be ok, but if you try to simulate a perspective effect the texture mapping will most likely be wrong.
EDIT : ok, just saw that quads were actually two triangles, which may affect some trapezoidal transformations. Linear transformation should be fine, though... shouldn't they ?
Also, since SFML already does the optimization for us, is there really a point in using VertexArrays ? As long as we're careful to use the same texture for consecutive draw() calls, there souldn't be too much of a difference... right ? It does make culling much easier...It's more expensive if done by SFML, because:
You can (and should) create the chunk's vertices directly at their final position. For runtime you can them use sf::View to scroll the map.
By this i assume you would say that if i was using a vertex array, my current system of storing each chunks screen position and the character moves by moving all chunks to the opposite direction to what the player wants to move, would be incorrect?This is not incorrect, but not the way it's supposed to be done.
See i did this so that i didn't have to move a view across a pseudo-infinite map because i figured that eventually the coordinates would be larger then the floats and int's that store the positions of thingsAre you sure that you can reach the max value a float can store (10^37)?
Secondly should i attempt to use my current method then but with vertex arrays even though you say they should be placed in their final positions.... if possible. If not, then you must find another solution, and I'd say that yours is not bad ;)
Last up, what would be the performed way of doing perspective on tiles then?Perspective?
By perspective i mean some way to make it so you are not looking straight down on perfectly square tiles, something so that tiles in the distance are smaller or something to give the illusion that the top of the screen is farther away.I don't know if there's a robust way of doing that with SFML. If you make your tiles trapezoidal, texture mapping will be incorrect because there's no perspective correction.
But how do you insert a texture into it. You don't have to copy each individual pixel, right? Because that seems to be a lot less efficient than drawing tile per tile. So the question is: how does one copy a texture into a VertexArray?You don't 'copy' it into, you pass it as second parameter in the draw call, i.e. draw(vertexarray, texture). It will then call the constructor of the RenderState class and then get passed to the draw function.
If you want to change for example an image of a closed door with an opened one, changing the variables doesn't seem like a big task. Why should it be stationary?You're right, it's not a big task. And you can do it. What would be wrong is to change all the vertices every frame -- but it would probably still be ok (think about a particle engine, for example).
For my particle system I had to create my own vertex array implementation which reuses already allocated memory for vertex array. So I don't have to allocate it every frame.What was wrong with sf::VertexArray? You can allocate the vertices once (with the constructor or resize function) and then overwrite them every frame without touching the allocated memory.