Draw only visible tiles

[fallahn]

Draw only visible tiles

[fallahn]

Tiles are batched in vertex arrays, and there should be no more vertex arrays than there are tile sets per layer - so unless you have a lot of tile sets (or a lot of layers) there should be very few draw calls, usually only 2-3 per layer. On the other hand, yes, vertex arrays which aren't on screen should probably be culled, but most cover the entire layer in a single call. Are you doing something different with your tile map? Could you try loading your map with the benchmark sample included in the examples directory, and compare it with the example map?

[Mars999]

I agree with makao95, I am seeing the same thing! 20-30FPS is VERY bad for such a simple game even with 256x256 wide maps. I have a Core i7 5820K and a Geforce 970 card and get these kind of Framerates! With your Quad tree you should be culling this out anyway and just batch the tilemap into say 64x64 grid patches or whatever the user wants to send in as a parameter to the create() or init().

Update: I just noticed this 20fps is due to DEBUG mode! Ugh, but I am still only seeing 500-600 fps in Release builds and this is with 256x256 maps... this is with nothing else fancy... I will check again once I have a more complete game finished. Still be nice to cull out patches of the quad tree due to the whole maps have been chopped up in to patches based on a value set by user or they can just have one patch the size of the map if it suits them...

[marcindawidziuk]

@fallahn I loaded my map into the benchmark (from repo) and I get FPS lower than 100 fps (original desert.tmx map gives me something around 500-600).

@Mars999 In debug mode it gets even worse - my game's performance drops down to about 5 FPS. But I have pretty old computer and use large maps, so many users propably don't notice the problem I have.

I managed to write that optimalization I was writing about. It gives me about 40% better performance than the original drawing method, however the difference will be bigger as the size of map increase. It also works only for static layers (it won't draw correctly if tiles are moved) and orthogonal maps. The code is a little bit messy and some more optimalizations are possible, but the main idea is well presented and it works great in my game. I think it would be great to have something like this in this project. The only drawback I see is that the map's layer have to be static in order to correctly calculate which tiles should it draw (maybe add new method like setStatic(bool)).

code: marcindawidziuk@a6d9685
map used: https://www.dropbox.com/s/axcm7dfa20xre6i/mapa.tar.gz?dl=0

[fallahn]

OK, thanks for your effort. When you have it more complete I shall definitely consider merging this

[fallahn]

Now I've had a chance to have a proper look at this a quick profile shows that it's not the number of tiles in a vertex array which is the bottleneck, but attempting to update the quad data for any tiles which may have moved. I've updated this with a dirty flag optimisation, so only the quads which need updating are iterated over - which most of the time is zero, leading to a significant improvement. There will still be a performance hit, however, if a lot of tiles need updating frequently but in these cases there may be other workarounds anyway. I've also made sure that any vertex arrays not visible on screen are culled away, increasing performance on maps with a lot of different tileset textures. The upshot is that your map which was running at ~30fps in debug mode on my work machine is now rendered closer to 600fps :)

I've pushed the changes to the repo, so if you would like to try it out, please do so and let me know how you get on. Thanks!

[marcindawidziuk]

Your patch works great, it really improved performance. However the number of tiles in vertex array can be a bottleneck too.
If I load a map with a big filled layer (like 1000x1000) the problem is still there and framerate drops significantly. And I am planning to load even larger maps with maybe even bigger layers. A workaround would be to (as a map creator) divide this one huge layer (1 000 000 tiles!) into few smaller ones, but I think the performance issues should be solved by programmers, not map's developers.

The grid-based culling (like in code I presented) is great and works the best for me. I don't know yet if it could be implemented nicely, without some deep changes, also will it work for isometric maps, but this kind of efficiency is worth it.

Mars999's solution would also be good - let the library to divide this kind of huge layer into parts with reasonable size (like 64x64 tiles or whatever programmer wants it to be) and cull parts which are offscreen. In this case it should be even possible to let the tiles to be moved (and cull "layer parts" based on updated bounds).

[fallahn]

Great! Nice to know I'm on the right track. I agree I think splitting up the layers into smaller sets of vertex arrays is the way to go. Already the loader culls vertex arrays which are off screen, so would automatically improve performance if the layers were split into smaller arrays. It could even be possible to let the user decide the size of grid to use when loading / splitting maps. I'll work on this next, and leave this issue open for now.

[fallahn]

OK, I've pushed another update, I think the picture speaks for itself :)

The loader now splits vertex arrays into smaller patches based on the size provided in the constructor. By default it is set to 10 which creates 10x10 patches of 100 tiles. Any patches not visible are culled. Obviously you want to experiment with the patch size to fit your map - a size of 1 would create a patch from every tile which is a bit silly, but a patch of 50 then starts to get too large and you get slow downs from too many vertices. The actual size depends on the size of your tiles and the resolution of the map view. Oh and as an added bonus it works with isometric maps too, as far as I can tell.

[marcindawidziuk]

That's great. Thank you for your work.