Reducing OverDraw

May 31, 2008 | Filed under: programming

When you make 2D, rather than 3D games, the two things that can slow your game down on older video cards (forgetting CPU limitations for now) are State Changes and Overdraw. State Changes are basically texture changes (drawing a different image). Doing this too often can really slow down older cards. Overdraw is the problem I was looking at yesterday on Kudos 2.

Kudos 2 is fixed at 1024 by 768 res. thats roughly 768,000 pixels, in 32 bit color, or just over 3MB to draw the whole screen. Because of the way video cards work, you have a front buffer, a backbuffer and the source art itself, so this equates to around 9MB in practice. Given that even the most wonky video cards have 32MB of RAM, this is no big deal, but this is assuming you just load up a 1024 x 768 texture and copy it to the screen.

The first problem is you can’t have a 1024 by 768 texture. DirectX prefers things to be ‘power of 2’ in each dimension, so you have to have 1024 by 1024, and as a worst case, waste a lot of space anyway. That’s only a minor problem though. The real problem is what happens if we end up drawing the same pixel too many times a frame. This is called overdraw, and its quite easy to let it slow down your game.

The best way to see how bad overdraw can be is to code a version of the game that draws every image as a fairly transparent white box. See below:

That’s kudos 2, AFTER I optimised some of it. The lighter the colour, the more times that same pixel is being redrawn. Sometimes, this is legit, because I am blending two images together, so you can’t just draw the top pixel, but in the majority of cases, it’s just inefficient. You can tell that one of the worst areas of overdraw (apart from the avatar, which is pretty inevitable) is the dialog boxes. These are a pain.

My dialog boxes are drawn on top of an existing background, theoretically giving me the opportunity to ‘punch a hole’ in the background and save some rendering. The dialog itself then has a ‘client area’ drawn using an additional image, which wastes space behind it. Any buttons on the dialog then add a third level of overdraw, and of course the text, or button icons are a fourth layer on top of that. If a tooltip pops up, we are at level five, and six for the tooltip text, seven if the cursor is above that! :D.

For video cards like mine, with an insane ‘fill-rate‘, it’s pretty irrelevant (The game runs at around 200 FPS right now), but I’m determined to make Kudos 2 easily usable on a low spec laptop with an Intel video card. I don’t lose *that* many sales due to poor performance with my existing games, but I’ve never made a game that looks casual enough for many owners of low spec PC’s to play before.

2 Responses to “Reducing OverDraw”

  1. Andrew says:

    How do you deal with all the various weird PC incompatibility issues and the wide range of hardware people have as a one-person development shop? Do you test it on a variety of hardware that you have, rely on some kind of public-ish beta process, or just hope that because your games aren’t very demanding it won’t be an issue?

  2. cliffski says:

    I have a few PCs, and try the game on friends PC’s too, but apart from getting people I know to try the game, it’s a case of coding very carefully and crossing your fingers. It’s much easier knowing I’m not using any fancy pixel shaders or vertex shaders, as those are the things that seem to cause most grief right now.