SFML community forums

Help => Graphics => Topic started by: hypnotix on July 01, 2015, 11:03:53 am

Title: How to effectively break up large Tile Map made with sf::VertexArray
Post by: hypnotix on July 01, 2015, 11:03:53 am
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?
Title: Re: How to effectively break up large Tile Map made with sf::VertexArray
Post by: Rhimlock on July 01, 2015, 12:13:49 pm
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.
Title: Re: How to effectively break up large Tile Map made with sf::VertexArray
Post by: eXpl0it3r on July 01, 2015, 12:42:14 pm
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. ;)
Title: Re: How to effectively break up large Tile Map made with sf::VertexArray
Post by: hypnotix on July 01, 2015, 02:14:59 pm
All right then, thanks for the replies.
Title: Re: How to effectively break up large Tile Map made with sf::VertexArray
Post by: Hapax on July 01, 2015, 08:33:11 pm
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).
Title: Re: How to effectively break up large Tile Map made with sf::VertexArray
Post by: Resethel on July 05, 2015, 04:07:49 pm
Another possible solution is to render a zone 2/3 tiles wider than your screen
You can for example:

It's really non-optimized but I used this kind of system when I learned SFML, but it's pretty effective 8)
Title: Re: How to effectively break up large Tile Map made with sf::VertexArray
Post by: BaneTrapper on July 05, 2015, 07:09:00 pm
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 8)
+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
Title: Re: How to effectively break up large Tile Map made with sf::VertexArray
Post by: hypnotix on July 06, 2015, 04:46:42 pm
Would that not entail creating a New VertexArray to be drawn every time the user scrolls or zooms?
Title: Re: How to effectively break up large Tile Map made with sf::VertexArray
Post by: Hapax on July 06, 2015, 06:00:40 pm
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.