Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (803)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [libgdx] Culling needed ? SpriteCache  (Read 5597 times)
0 Members and 1 Guest are viewing this topic.
Offline Cero
« Posted 2014-05-09 00:58:28 »

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 ?

Offline theagentd
« Reply #1 - Posted 2014-05-09 02:54:13 »

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.

Offline Nate

« JGO Bitwise Duke »

Medals: 167
Projects: 4
Exp: 14 years

Esoteric Software

« Reply #2 - Posted 2014-05-09 08:59:57 »

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:

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Cero
« Reply #3 - Posted 2014-05-10 22:09:49 »

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.

Offline theagentd
« Reply #4 - Posted 2014-05-11 00:48:25 »

Your main worry here is probably GPU performance. Here's how to do proper GPU profiling:,

Offline Cero
« Reply #5 - Posted 2014-05-11 02:06:34 »

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...

Offline theagentd
« Reply #6 - Posted 2014-05-11 02:18:33 »

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.

Pages: [1]
  ignore  |  Print  

Riven (397 views)
2019-09-04 15:33:17

hadezbladez (5280 views)
2018-11-16 13:46:03

hadezbladez (2204 views)
2018-11-16 13:41:33

hadezbladez (5544 views)
2018-11-16 13:35:35

hadezbladez (1150 views)
2018-11-16 13:32:03

EgonOlsen (4584 views)
2018-06-10 19:43:48

EgonOlsen (5462 views)
2018-06-10 19:43:44

EgonOlsen (3119 views)
2018-06-10 19:43:20

DesertCoockie (4015 views)
2018-05-13 18:23:11

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!