[libgdx] Culling needed ? SpriteCache

Newbie & Debugging Questions
#1

First of all my question is: How much needed is culling in general ? 2D Tilemap based game in this case.

I’ve been using the libgdx SpriteCache and I cache a whole layer and later draw it - by itself you cannot clip/cull it since its one big mesh; Via SpriteBatch its easy since you just stop drawing them at some point.

So I guess the solution is to seperate the cache into chunks and thereby cull it. Of course small enough chunks defeat the purpose of the SpriteCache.

but yeah bottom line: if I send a mesh like that to the GPU where like 80% of the mesh is not within frustum anyway, doesnt the driver/GPU does some sort of culling anway ?

How costly is it to draw something which is not on screen ?

#2

Your GPU only does “frustum culling” after transforming every triangle you render to screen space. It won’t render pixels that are outside the screen, but it still needs to process and transform every vertex you tell it to render since OpenGL has no idea what’s outside the screen before it transforms the vertices. This vertex processing is obviously not free, so if you’re rendering tens of thousands of tiles that are outside the screen, it’s much faster to add some rough frustum culling on the CPU, for example by splitting up the world into chunks and only rendering the visible chunks like you said.

If you need to optimize this mostly depends on how many tiles you’re trying to render. If your game isn’t slow on the slowest hardware you intend to run the game on, it’s not a problem and not worth optimizing.

#3

Check this class:


It uses SpriteCache to render a Tiled map. It stores the tiles on screen and a number of tiles around those (see the overCache field). As you move through the map, it caches again as needed.

Here is a game using it:


#4

I’m mainly making a note here for myself for later reference.

I’m going to ignore this performance problem for now and at the very end look at it, if an performance improvement makes sense @ this might be premature optimization.

One uses a spriteCache so that you dont have to send all that static geometry data to the gpu all the time like with spriteBatch, however to implements culling you will have to recache all the time depending on the projection matrix. question is which is worse, whats the butter zone, which costs more.

Another note: Caching seems to work in a thread, I first though it might not since its an OpenGL operation; This might be done to remedy lag if you need to cache often and if does create lags, then you can cache beforehand in the background…
however I already experienced synchronization problems, which is to be expected if you draw when another thread is caching…

I wonder how old fast games like GTA 2 did this. Or even Sonic being on an even more restricted system.

#5

Your main worry here is probably GPU performance. Here’s how to do proper GPU profiling: http://www.java-gaming.org/index.php/topic,33135.new.html

#6

That will be helpful most GPU profiling tools are kinda dodgy…

In my example: Tiles are 32x32. A big map example here is 256x128 tiles. thats 32k tiles.
with a windows size of 1600x900 I renderlike 1400 tiles leaving 30k left outside the frustum.
and thats per layer.
of course many layers have a lot of empty tiles which wont be added. nevertheless foreground plus filled out background even without parallax… its a lot…

#7

32k isn’t that big of a deal. It’s only 128k vertices and 64k triangles. Even weak GPUs can handle hundreds of thousands of vertices, but you may still wish to optimize it if it’s easy just to give you some headroom for other effects.