After I upgraded to a 720p display format (rather than just 800×600) the framerate took a little bit of a dip on my slower machine. Understandable really as it’s drawing quite a few more pixels – 921k rather than 480k in the worst case, ignoring overdraw. I’ve spent the last few days optimising the renderer to see how much of the performance I could get back.
Firstly, you’ve got to have some numbers to see what’s working and what isn’t, so I added a debug overlay which displays all kind of renderer stats:
The top four boxes show stats for the four separate sprite groups – main sprites are visible ones like the helicopters and landscape, lightmap sprites contains lights and shadows, sonar sprites are used for sonar drawing, and hud sprites are those that make up the gui and other hud elements like the health and fuel bars. The final box at the bottom shows per-frame stats such as the total number of sprites drawn and the framerate.
Most suprising is the “average batch size” for the whole frame – at only 4.1 that means that I’m only drawing about four sprites per draw call, which is quite bad. (Although I call them sprites there’s actually a whole range of “drawables” in the scene, water ripples for example are made of RingGeometry which is a ring made up of many individual triangles, but it’s easier to call them all sprites).
Individual sprite images (such as a building or a person) are packed into sprite sheets at compile time. In theory that means that you can draw lots of different sprites in the same batch because they’re all from the same texture. If however you’re drawing a building but then need to draw a person and the person is on a different sheet, then the batch is “broken” and it’s got to start a new one.
To test this out I increased the sprite sheet size from 512×512 to 1024×1024 and then 2048×2048. For the main sprites (which is the one I’m focusing on) this pushed the average batch count up from 5.3 to 5.6 and then 16.2. Obviously the texture switching was hurting my batch count – 16 would be a much more respectable figure. Unfortunately not everyone’s graphics card can load textures that big, which is why I’d been sticking to a nice safe 512×512.
However further investigation found that the sprite sheets weren’t being packed terribly efficiently – in fact packing would give up when one sprite wouldn’t fit and a new sheet would be started. This would mean that most sheets were only about half full – fixing the bug means that almost all of the sheet is now used. Below you can see one of the fixed sheets, with almost all the space used up.
Along with this I split my sheets into three groups – one for the landscape sprites (the grass and coast line), one for world sprites (helicopters and people) and one for gui sprites. Since these are drawn in distinct layers it makes sense to keep them all together on the same sheets rather than randomly intermingling them.
One last tweak was to shave off a few dead pixels on some of the larger sprites – since they were 260×260 it meant that only one could fit onto a sheet and would leave lots of wasted space. Trimming them down to 250×250 fits four in a single sheet and is much more efficient.
Overall these upped the batch count for main sprites up to a much more healthy 9.2, reducing the number of batches from ~280 to ~130.
Good, but there’s still optimisations left to be done…