Category: programming

I’ve never liked health bars in RTS and Tower Defence games. They always seemed annoyingly crude to me, like the designer just thought ‘err…health bars? lets just copy the games from 1980 ok?’. They really break immersion badly for me. Worse still, if you wanted 3 different indicators, for health, armor and shields, you got 3 bars, which was silly.

Gratuitous tank battles solves this with cunning health ‘discs’ only on selected units. The image below shows some infantry with full armor and health, and a damaged turret that has lost some armor. I need to change the code a bit to make the colors relative, rather than always splitting them equally, for situations with high health/low armor etc… anyway…

The problem with this system is that to draw the discs programatically you need a lot of triangles to be smooth. Given GTB supports VERY high zoom in and out, that means either blocky hexagons when zoomed in, or triangle-calculation nightmare framerate if you select 500 guys when zoomed out.

The solution is ‘continuous level of detail’ which 3D engines sometimes do with meshes (not sure how common it is), where you basically add triangles as you zoom in, so you have a constantly varying image complexity. The human eye should never notice. With a simple triangle fan, it’s relatively easy. With a big complex mesh, it’s way harder. I know, I worked on Elixirs ‘infinite polygon engine’.

You might think drawing a few hundred triangles here and there makes no difference to frame rates, but it all adds up. I like to write the fastest code I can. It’s also pretty cool to play about with stuff like this. I can’t actually see it happen, even though I know it is, because I can see it happen in wireframe. Nobody playing the game will ever care, but it does add some polish to the game. it makes my GUI look much smoother than it otherwise could have done, given the framerate I’m expecting.

On my todo list for ages was fixing damage sprites so they glow in the dark. It always bugged me that my damage sprites were not really good enough, to my mind. We have wood-burning stoves at my house, which I light almost every day right now, and for a lot of the time I worked on GSB I used to sit there staring an a blazing inferno of logs and coal and feel annoyed that the damaged bits of spaceships didn’t look that awesome. I am using a very similar system for GTB, although with less hassle for placing the individual damaged locations, which makes it a bit easier for modders. They still do not pulse and glow the way i want.

One complication though, is I have lighting in GTB (not real 3D lighting, but cunningly faked), which means they needed to glow in the dark like this:

Which they now do, and I’m very happy about it. Unfortunately it took 2 days work, because in investigating it, it turns out I had to totally re-write my lighting system. The game uses multiple render targets for the lighting and composes them right before displaying the end image, which means that anything that actually gives off any light, such as a searchlight, laser beam, particle, or damage sprite, needs to also render to the offscreen lightmap buffer. It also means you have to batch these, and there are all kinds of annoying  unlikely scenarios where it actually breaks down, in some way, although I doubt anyone will ever notice.

At the end of those 2 days, I was very glad I took the effort. Maybe one day I’ll manage to get them pulsing properly, and have particles flitting around ‘inside’ the damaged areas. Maybe!

So…. it runs! and it runs in places at 60FPS, but in other places….not.

My dell video card has a 64MB VRAM intel GMA chipset, so hardly a gaming laptop, but my aim was to get GTB to at least run on it, even if the framerate sucked. That way, I know people with 128MB or 256MB cards should be fine, and I’d like to keep the min spec as low as I can.

The game already had a ton of stuff you could turn off, such as shadows, shaders etc, but running it on the Dell, and then profiling it using the awesome free intel GMA tools showed up a ton of stuff that I could do to increase the initial 20FPS rate. These were:

• Realise that the refresh rate on the dell was set at 40FPS not 60FPS initally, hence making an artificially low limit. DOH!
• Removing a redundant Clear() at the start of each frame. I fill the screen anyway, so why bother? I don’t use a Z-buffer.
• Removing some render-target sets and clears when the shader options were turned off. With these off, I can render direct to the back buffer, old-school style and save time on render target changes.
• Adding code that detects a jpg when loaded, and mip-maps it. Previously, they had no mip maps at all. Could possibly reduce some memory consumption
• Add a graphical detail slider to options which can turn off a bunch of frilly details like window shadows, and drifting smoke on menu screens.
• Providing a separate list of lower-res textures that get used in some cases when the graphical detail slider is below 25%. Such as mech legs and the shadow maps for scenarios. Any texture of 2048 or higher gets a lower res replacement. I had tried auto-scaling them on load, but this gave unexplained errors and I don’t trust D3DX to do this reliably on all video cards to be honest, so separate low-res textures it is.

I think the biggest wins were the texture-size reductions and the removal of the render target clears. It was interesting to note that the dell considered the game to be GPU limited, despite it being a fairly old and crappy chip (and only a single core). I guess at 1920×1200 res with all the options on for the desktop, things may be very different though.

Things may start to race ahead from here. The game is definitely very playable in its basic form, with the majority of extra work now likely to be the online challenge and integration stuff. That will take months, but still, the end is definitely in sight.

AQTime is my friend. Now… to the optimizemobile!