Category: programming

It’s amazing what bugs you find when you just sit and play through the game for hours (I’m playtesting and balancing the game so that the AI fleets give you a bit of a challenge).

Two bugs squashed today are these:

Firstly, the code that detected that an enemy target was being ‘painted’ by a target painting laser (and thus easier to hit for missiles) was just not working at all. I’d checked and double checked it many times, but because the ‘is it painted’ code is just one of about 6 factors determining optimum target selection, it was hard to tell if it was working right without stepping through everything each time.

It turns out that code worked fine, but some *other* code which told a targeted module whether or not it even *was* a missile launcher, was buggy, and so the code was never even being run. doh!

The second bug was investigated after I noticed some very slow missiles which looked like multiple-warhead missiles but never split into their sub-munitions. It turns out that this code has never worked correctly! The code works fine the first time a missile splits into sub-munitions, but if it gets to live long enough to shoot another missile later, the sub-munitions are never triggered. That was an easy fix.

Unfortunately, that means I’ve been underestimating the destructive power of multiple-warhead missiles all the time, which means I need to re-play through every battle, on every difficulty, and both re-balance the fleets, and maybe re-balance the cost and strength of the appropriate missile modules too. This will take all of today at least.

Damn :(

One thing I did notice, that was pretty cool was an imperial AI fleet I’d put together that sends its fighters in ahead, and the rest of the fleet shows up afterwards (moving slower). By lucky hap, although the fighters were useless against the heavily armoured federation cruisers, they did manage to blow the crap out of the row of point-defense equipped escort frigates that flew alongside them. So when the Imperial cruisers got into range, they could bombard the feds with missiles without opposition. This is exactly the kind of design and thinking I hoped the game would reward, so it’s cool to see it is all about strategy and not just luck :D (Obviously when you play against that fleet, make sure you don’t have a line of unarmed frigates sitting waiting to be blown up :D)

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.

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.

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.

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.