Slow on Android, too many sprites ?

One of our games Black Nebula is quite slow on Android which much going on, meaning many enemies and shots.

Question is why exactly… I have now put eeeverything on one big 1024x1024 spritesheet because I thought it might be texture swapping, but didnt seem to help.

Since I can’t really profile on Android, JProfiler on Desktop says that Display.swapBuffers takes a long time…
Does that mean that there are simply too many sprites on the screen ? / fillrate problem ?


http://img521.imageshack.us/img521/3289/asdfxa.jpg

Unfortunately a little hard to tell without any more details. I see you are using libgdx?

Also - what hardware? How many sprites? What do you define as “slow”? :slight_smile:

Give us some more insight into what goes on in your render loop and we might be able to point out a few weak spots. Fillrate issues could definitely be a candidate.

Cheers,
Bach

Debug your sprite batch with renderCalls to find out how many times per frame it’s rendering/flushing.

//at start of frame...
batch.totalRenderCalls = 0;

// ... render frame ...

//output the result somehow, e.g. sysout or LWJGL Display title
Display.setTitle("Calls: "+batch.totalRenderCalls);

Things that flush the batch:
[]Using a different texture
[
]Changing the shader
[]Changing the projection matrix
[
]Changing the view/transform matrix
[*]Rendering more sprites than the batch size allows

For example, you should only change the projection matrix when the viewport/display is resized.

Other things to keep in mind:
[]Use nearest neighbour filtering where possible to improve performance
[
]Minimize overdraw; i.e. for blending effects, use a shader instead of drawing sprites many times over each other
[]Try changing resolution… If the FPS improves dramatically, it may be an indication that your game is fill-rate limited.
[
]Put an option to cap your particles, e.g. a slider UI, and try testing that on your Android to see if reducing particle count improves performance. If that’s the case, it may be another indication that you are fill-rate bound

alright lets check this out again - havent worked on this game since

Ok I get kinda 9 on average and like 16 if everything explodes (bomb)

How do you do HUDs ?
I use a second camera and change projection matrix to it for HUD, when everything else was rendered.
I only have 2 textures (excluding the particle pngs), basically only 1, just the explosion effect is a large image getting bigger so this one is a texture by itself

Resolution well… I dont really have a problem on a low end PC, just android devices, but they even have 2 cores…
Im gonna try on my single core laptop to check out the performance there…

yes particles - I will double check, but I’m pretty positive that its not particles because I made this performance test:
I just stood still - enemies will come and corner you, and shoot - the hits on you is just a color filter going red on the player sprite
as more enemies approached it got slower

also going to check out on my new Galaxy S3, but I don’t expect it to lag there.

Also different issue, well not really maybe, might be related.
For many reasons I wanna avoid delta timing stuff, so we have in all our games a 60 fps mode for desktop and a 30 fps mode for mobile where we just move everything twice as fast and do forth - because you can never know what the vsync fps is going to be on mobile
and my method of frame throttling may be suboptimal