How to effectively break up large Tile Map made with sf::VertexArray

[hypnotix]

So I successfully made this tile map sort of thing with an sf::VertexArray, it has around 1.5 million points in it and is of type sf::PrimitiveTypes::Triangles. The problem is, frame rates aren't particularly high (low 80s) at the moment because of its size. Now, there will definitely never be a time in which all of it will be in the screen space to be drawn, so I suspect dividing it into groups and drawing only the ones that are visible would be better right now. So the question is, at what point does the increase in draw() calls offset the performance gain of me having divided it and thus not drawing everything?

[Rhimlock]

That would depend on the hardware you are using.

A few draw call wont be a problem so my suggesting woul be to split your tilemap into chuncks which are about the size auf your screen. At worst you would have 9 draw calls, which is as good as nothing.

You should just test for yourself to find a size fitting your needs.

[eXpl0it3r]

A few hundred draw calls should not be a big issue, in the end however you can only know for sure by benchmarking all the hardware.

[hypnotix]

All right then, thanks for the replies.

[Hapax]

It might be worth consider creating the tile map vertex array with a size that fits the screen and then update the tiles from your tile data when different tiles are displayed. That way, you're only ever using the amount of primitives that fits on the screen (you may need a little extra to allow for smooth scrolling).

[Resethel]

Another possible solution is to render a zone 2/3 tiles wider than your screen
You can for example:

• Get the view center and the view size
• Transform them in your tile coordinate system
• Choose a starting tile ( like startingTile = your center - your mapSize - Vector2<T>(2,2)
• Render your map from (StartingTile.x) to (StartingTile.x + mapSize.x + 4) same for y axis

It's really non-optimized but I used this kind of system when I learned SFML, but it's pretty effective

[BaneTrapper]

Another possible solution is to render a zone 2/3 tiles wider than your screen
You can for example:

• Get the view center and the view size
• Transform them in your tile coordinate system
• Choose a starting tile ( like startingTile = your center - your mapSize - Vector2<T>(2,2)
• Render your map from (StartingTile.x) to (StartingTile.x + mapSize.x + 4) same for y axis

It's really non-optimized but I used this kind of system when I learned SFML, but it's pretty effective

+1, it is robust way to do it. The amount of draw calls depends on screen size Y / primitive size Y. All in all 10/10 IGN

[hypnotix]

Would that not entail creating a New VertexArray to be drawn every time the user scrolls or zooms?

[Hapax]

It's not that big a deal to re-create the vertex array. Most of the time, it could be just changing where on the texture the vertices point to and possibly moving them.
You may want to resize the vertex array if it changes and, as it turns out, that isn't actually much of a problem.

Note that it's not creating a new one; it's just updating the current one from recent data.

It's obviously dependent on what you need it for but this can be done every frame with hundreds of primitives without any significantly noticable delays.