I'd always known that drawing the status bar was a slow operation in DirectQ, and that running the game fullscreen with no status bar resulted in a significant framerate jump. This was caused by a number of factors, one of which was that I'd removed the "scrap" allocation system (for status bar icons) from the engine.
This is a form of Texture Atlas which was originally written to save on texture changes. On any non-prehistoric (post Voodoo 2) hardware texture changes are cheap, so it might seem irrelevant these days, but there is another unintended advantage of it, which is batching.
The key to high performance in a game engine is the ability to batch multiple primitives in a single draw call. DirectQ is capable of doing this for just about anything you see on-screen (I think that translucent brush models and the underwater warp update texture are the only things that aren't batched), which is where it gets most of it's speed when handling big maps and complex scenes from, but any state change requires breaking the batching.
By removing the scrap system I had each status bar icon in it's own texture, which meant that each icon needed a texture change, which broke the batching. It doesn't seem like a big deal (it's just the status bar, right), but depending on factors like what you have in your inventory, there could be over 30 individual textures here. That's 30 unbatched quads being drawn, which will suck the performance out of any engine to quite a surprising degree.
So I'm currently working on restoring the texture atlas system. At the moment it's functional in quite a raw state, but sufficient to confirm that the performance gain is worthwhile. It's not a few tenths of a percent, but more like a 5% to 10% increase. I'm hoping to be able to extend it to support external textures, as well as to have it be capable of coping with any size textures at load time but reduce it to the size that's actually needed at run time.
There are further gains to be made in other areas of the status bar code, arising from bad decisions I had made when originally porting GLQuake to Direct3D, and I'll talk more about them when the time comes.
Tuesday, June 15, 2010
Speeds up (yet) Again!
Posted by
mhquake
at
6:03 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment