Game Design, Programming and running a one-man games business…

Raw PIX data for gratuitous space battles

I’ve never seen anyone share data like this, but I don’t see why they wouldn’t, it’s hardly source code. PIX is a free program from Microsoft that lets you analyze your games directx performance. I haven’t analyzed this data or changed any code yet, but here is a quick 2 minute start of a battle in the game (release build) analyzed with pix. Click the image for a larger version

This is great for working out why you get occasional slow frames, or working out where bottlenecks are. TYhe FPS seems to never go above 60 FPS, because the game caps it there, making a note of the ‘headroom’ available for potentially enabling higher-demand effect (not all done yet).

This is under Vista, 2 gig RAM, Core 2 Duo 6600 2.4 gig CPU and a Geforce 8800 GTS with latest drivers.

Please feel free to comment on how the numebr compare to agmes you might have worked on or develop now. I’d lvoe to see other peoples pix data as a sanity check. Is 83 set textures a frame a lot?  it seems to depend on what else is going on.

RangeFinder

In my play testing and balancing sessions, I found myself really wanting to know what the ranges were of a specific weapon mid-battle. You get to see this in pre-battle deployment, but that’s only the initial formation. There is nothing more frustrating than watching your ship sit there, minding its own business while an enemy ship sits just out of range and missiles it to pieces :D I should adjust the ‘retaliate’ AI order to allow it to move within range

So anyway, I’ve added in a new range-display GUI to the battles. Basically you just click on your ship to show the window with its details, then click a module with a turret on that window for it to highlight that weapons range on the map. I’ve toggled on the background grid here for extra ‘tactical display mode’ fun.

The last few days have been really hard work battling an obscure texture corruption bug. I was working on it at 1AM last night. I’ve completely rewritten my vertex buffer code to use a different locking strategy, and I’m pretty sure it’s for the better, although I do too much memory copying for my liking. Still, the game runs pretty fast even so.

New Video, just some new gfx fluff

Today is a weekend day, so I don’t feel bad adding graphical fluff. I also fixed a few minor bugs in the UI. Amongst the stuff added was Level-Of-Detail particle emitters for explosions here and there, some new particle effects for minor things like shield impacts, and missiles flares fading out as they run out of fuel.

Particle LODS are interesting, because they only half solve the issue. Not drawing them at lower zooms is all well and good, but each particle still needs processing. Its not enough to assume they will remain off-screen when not being drawn either. I guess I could not update them, and just note the time elapsed, and ‘catch up’ when they are next on-screen, but because they may have moved on-screen during that time, you can get artifacts that way. You can maybe do it for ones clearly massively off-screen.

In any case, having LOD levels for some effects makes it easier to turn them off when the GPU is overloaded, or if we need the time to do other stuff.

This vid was knocked together in 10 mins, so it’s nothing special, but you might like it anyway.

Performance stats for GSB

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.

alt+tab works again

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.