I have encountered a most frustrating and confusing problem. When adding scrolling backgrounds to our game, the performance hit is enormous on our HTC Desire.
This is what the game looks like with backgrounds (lags horribly):
And this is what it looks like when BG’s are removed (runs smoothly):
The game uses SpriteManager, so the whole game runs on 1 drawcall and 160tris.
The texture sheet is 2048x2048; material uses Particles>Alpha Blended.
Everything is drawn on Z = 0 (without z-fighting, thank santa). Orthographic camera.
OGLES1.X/2.0 has no impact on performance, neither has texture compression or material shaders.
In short, I have pinned the issue down to the scrolling backgrounds being the problem, but I have no idea why this makes for such a performance decrease.
Could it be that the HTC Desire just doesn’t handle multiple moving objects that well?
We tried the game on a HTC Desire HD, and it ran fine. But looking at the simple construction of the game the Desire shouldn’t have any problems. I, and my whole team, would be greatly thankful for any input in this, because we’re running out of solutions.
And yes, it’s an action hero that punches dynamite-monkeys. In a city.
One trick we have used in the past is to use the background to clear the screen and z buffer. Create a simple shader that has z always in it assign that to your background (I did this on awake as assigning a different material confuses SpriteManager/EZGui and makes it write out a separate atlas). Then change your camera to not bother clearing the screen +10fps.
Let me know how that goes. There are other things to try as well. Simplified shaders, texture compression, mip tuning etc…
Shader programming is unfortunately not any one’s forte over here, so could you possibly paste a simple shader like that?
Also, would it be better to split the scrolling backgrounds into smaller pieces (more objects) or bigger pieces (less objects)?
The ones scrolling are the green-ish buildings and the gray ones in the back. The red texture is our static background.
the most important part is that you don’t use any shader that uses colormask, blending or is transparent, so the overdraw is reduced as far as possible (unless something is transparent naturally)
better have real geometry to cut around drawn forms than having alpha based cutout which makes the whole thing overdrawing the complete stuff behind it after it was drawn already fully
Just to be on the sure side here: having alpha with pixels that are all alpha = 1 still will have the same inpact as if it weren’t 1 cause the whole thing is still rendered with alpha blending etc
We use Particles>Alpha Blended to smoothly cut out or sprites like any 2D-engine (isn’t this what Sprite Manager is for?). Pretty much every sprite we use in this game comes with alpha.
What do you mean when you say that we should use real geometry to cut around our sprites?
Minimizing overdraw and reducing texture size by half did wonders for performance! It looks butt-ugly, but with a quality setting in our options menu we can let our users choose between image quality and playability, so “problem solved” there too!
Thanks dreamora, and especially DTreble for the helpful input!
Looking at your screenshot, it looks like every bit of it has some alpha in it. The blocks along the bottom seem solid, but the polys containing the blocks have the tops with transparency. Is this for some particular reason? If you minimize the amount of transparency to where’s needed, you can maintain performance and your look. Hell, looking again, every building has some transparency in it, when it doesn’t need it. If your polys form-fitted to your building shapes, you’d be better off. These devices are better at pushing polys than overdraw.
