Category: gratuitous space battles

In drawing a typical frame of a biggish battle, the following time is used up:

47% Drawing the ships and their attached particle stuff and effects

12.7% Drawing the debris, and updating debris that is not on-screen

8.3% Drawing missiles and associated effects (it was a missile-heavy fleet, to be fair)

7% Drawing drifting hulks of destroyed ships, and their attached emitters

5.9% Processing gameplay stuff for ships, including target-selection AI

4.3% Post-processing shader stuff

3.18% Drawing the backdrop map.

2.49% Drawing GUI

It seems clear to me that the background map and the missile stuff is slower than it should be, so time to do some digging and stroking of chin, and some speedups…

The tricky thing with all this is making sure that you minimize the amount of work a video card will do, ebcause some people cards may be less capable than mine (GeForce 8800 GTS), but at the same time I don’t want to ‘over-batch’ things, because ideally there is some concurrency betweent he CPU and the GPU. (In other words, the GPU is given things to do while the CPU gets on with non-graphcis stuff, as opposed to the two chips basically taking turns.

There are tools to examine all this stuff, like PerfHUD and Pix. They can be very very complicated to wade through though. I’ll try and gather up some more interesting stats one xactly how its all looking from a performance POV.

For a while i’ve had a problem where alt+tab wouldnt work in the game. I had it working from the main menu, but if you tabbed out mid-battle, it would hang on tabbing back. If you’ve played my older games, you know they always support this easily. I find it annoying when games don’t play well with the underlying O/S, and its often a symptom of a cheap console-port. Nevertheless, the change to directx9 has really complicated matters.

Regardless of this alt+tab works now even mid-battle, no thanks to microsoft. The problem is, you get to a point where you have to call Reset() on the Direct3DDevice. This is fine, and it returns true or false (effectively). If you turn on all the debug output, run with the debug DLLs, and check the debug output at this point you get a message a bit like this:

“Reset failed because you forgot to release a reference count somewhere”.

And the exact piece of code that writes that, knows exactly which piece of your code has its reference count too high, but they don’t bother telling you. Grrrr. In the end I tracked it to me grabbing the render targets surface somewhere (specifically the code that writes fancy layered shield impact effects). If you just grab a surface from a texture, it increases the reference count. Quite why it does this I’m not sure, as the solution is to just call release() immediately.

Anyway, it’s fixed. Several other things are fixed and improved, and the game is looking very playable right now. The actual AI-opponent fleets are not all finished, I need to play through 11 different battles on 3 difficulties, and tweak all those Ai-ships and fleets for a while yet. But then, apart from a few more tutorial things and putting in final music… that will be practically time for a beta.

My smoke and flame textures have always sucked, and now I’ve got a lot of proper gameplay and bug fixing done, I’m having a sneaky graphics-whore day where I make better ones.

My searches for decent smoke clouds took me here:

http://www.herts.police.uk/about/buncefield_incident.htm

Ironically, a rather famous fire in the UK not long ago. Small world etc. Flipping big flames and smoke too.

I also improved my particle effects today. a simple 5 lines of code improvement that means the first 100 milliseconds of any particles life is spent fading and growing into its initial size. This prevents particle ‘popup’ when you are zoomed in, and actually looks really good. It’s something nobody will ever notice, but if I hadn’t done it, the particles would seem less organic.

It’s no good doing a game called gratuitous space battles without serious ship explosions. My current benchmark explosion is this one from revenge of the sith:

I’ve watched it hundreds of times, and taken about 30 still frame captures from the DVD to use as reference. I have quite a complex particle and effects system for GSB, and it’s coming along nicely. Currently, the average cruiser will have 17 distinct events as it explodes, not counting the release of escape pods

Those 17 events are scripted like this:

[explosions]

1 = 0,128,80,EXP_FRIGATE

2 = 11,97,149,EXP_DESTRUCTION_PLACED

3 = 20,199,205,EXP_DESTRUCTION_PLACED

4 = 20,196,238,EXP_DESTRUCTION_PLACED

5 = 101,108,41,EXP_DESTRUCTION_PLACED

6 = 120,143,163,EXP_DESTRUCTION_PLACED

7 = 200,47,189,EXP_FRIGATEBREAKUP

8 = 210,0,0,EXP_STARTBREAKUP

9 = 270,128,128,EXP_CRUISERDEBRIS

10 = 274,53,226,EXP_DESTRUCTION_PLACED

11 = 290,59,229,EXP_DESTRUCTION_PLACED

12 = 310,171,209,EXP_DESTRUCTION_PLACED

13 = 388,61,204,EXP_DESTRUCTION_PLACED

14 = 400,128,175,EXP_FRIGATEBREAKUP

15 = 400,128,175,EXP_PLUMES

16 = 400,128,128,EXP_BLASTGLARE

17 = 900,128,128,EXP_ANGLED_DEBRIS

They relate to particle effects and other graphics. So there are a number of different particle emitters called from different points on the hull, then at 210 milliseconds after detonation the sprite starts to tessellate into pieces. At the same point, the damaged hulk texture starts to cross fade into existence behind it, and the hulk components start to drift.  At 270 milliseconds a shower of permanent debris is spawned. At 400 milliseconds, plumes of wandering particles appear, accompanied by a bright flickering white glare which also generates a shockwave blasting existing debris out of the way. A final shower of temporary particle system debris is triggered right at the end.

This is all configured per-ship-hull, so different ships can detonate in different patterns and styles.

It looks cool :D