Category: programming

There was a bug in Gratuitous Space Battles: Galactic Conquest until today. It was a bit obscure, and very baffling. Basically, in seemingly random circumstances, regardless of file version, people would develop a bug where the campaign backdrop was just plain white. I could not reproduce this. Re-installing seemed to fix it, for *some* people.

Anyway, someone noticed when I asked about it, that a line in campaign.txt storing the background texture name was missing. They had the latest version, and I KNEW that line was in there. It made no sense. Then they noticed that they could paste that line in, when the game was running, and voila, it worked. How weird.

So I looked at my code, and sure enough found some code which overwrites campaign.txt. Old, boring, unused, debug code for doing the campaign editing from about three months ago. This was before that file had this line in it, so because that code had never been updated, it meant that whenever it ran, and  saved out campaign.txt, it overwrote it with a new copy that had no data for the background texture (it used to be hard coded).

What a dork.

But even worse, I had left in this debug code mapped to the ‘H’ key (S was in use), and never remembered to remove it. So if anyone ever pressed ‘H’ during the campaign, it ran.

What a huge dork.

Anyway, it’s gone now. The bad news is, I am obviously a clueless muppet who could not code his way out of a paper bag. The good news is, I fixed this on Christmas Eve. Hurrah! It’s in patch 1.54, you will get it today / tomorrow.

Happy Christmas / Holidays / Festivus / Ascension of Kahless day to everbody!

version 1.51 is live. This does the following:

version 1.51
1) [campaign] Fixed exploit where you get 1 crew when you scrap a fighter.
2) Added new order 'Last Stand' which overrides the auto-behavior of ships retreating if all of their weapons are destroyed.
3) [campaign] Some difficulty balance changes.

it MAY be causing a bit of a crash. I just spotted it, when looking into something else (typical). I’m working on a  quick 1.52 now. It should only happen if you capture enemy fighters, i think, and it s a popup message you can click ignore to, anyway. Ironically, it’s a pop-up message helping me find a rare bug, that I still can’t find :(

Anyway… I have fixed a bug where fleets dissapear on retreating if you viewed the post-battle stats. that will be in 1.52 as well. Plus, I’m working RIGHT NOW on a fix for a retreat related crash bug. I think it’s caused by retreating with a fleet where there is a friendly planet to retreat to, but your ships cannot move there due to anomalies. It should be fixed in 1.52 as well.

The sheer tonnage of code in GSB is staggering.

I hope I get this bug squashed before the apprentice is on :D BAGGS THE BRAND!

I haven’t been working on memory optimisations in GSB for a few days, in fact I’ve done nothing but work on features and bug fixes and other stuff for the campaign game. The game is getting better, and looks nicer now, but there is tons to do, a whole host of niggling little things, and some vital balancing and optimising still to do.

But as I work, I keep thinking back to my attempts to optimise the memory footprint of GSB. I wrote an overriden new and delete, to track all my memory (I never use malloc or free). I have spreadsheets showing all the allocations. However, it seems that the memory I allocate is just a trivial percentage of the RAM the game seems to use if you look at it with windows task manager or the windows performance monitor. Of course, there are about 36 different measurements of memory, such as ‘private bytes’ and ‘peak working set’, And nowhere is there a definitive answer on which one to use. However, even using the lowest one, there is still at least 50% of memory unaccounted for. At one point, I checked my stats were not reporting MB as KB, it was that bad.

Sadly, it’s hard to optimise when you can’t see the wastage. I suspect a big chunk of it is particles, but the maths don’t support that. It could be directx making system memory copies of video texture buffers and sound files, but would that be inside the GSB.exe memory footprint? Who knows!

In other news

1) The ecofan really works. In fact it is awesome.

2) Chopping wood from 3 year seasoned timber is trivial next to 10 month felled holly, which is like cutting neutronium with a spork.

3) The UK has a major apple glut. We have some apple trees in the garden and so many apples we literallty can’t walk in the garden for the fallen ones. I actually knocked on neighbours doors to hand them carrier bags full of apples today, just to get rid of a few hundred. It’s insane. We are eating as many as we can, and making apple cakes galore.

I’ve been working on about 16 different things, but one of them was to reduce the memory leakage of GSB. I know some people design very cunning survival-mode fleets and have battles that can go on for an hour or more, and basically GSB leaks memory quite badly right now. Also, if I ever want this game ported somewhere, it will need to get it’s memory use under control. Plus campaign games sometimes lead to some VERY big battle, which makes the issue worse.

Lots of fiddling around (writing my own memory allocation debug stuff) means I could watch exactly what was getting allocated mid battle. I dumped every memory allocation during battle to a text file, then chopped off the first 10,000 (so I don’t worry about early allocations, which are then cached and re-used anyway), so I could see what the long term persistant offenders were.

The next step was to ensure I was looking at the *amount* of RAM being used, not the number of small trivial 20 byte allocations. Those need optimizing too, but not now. To do this, I stuck all the text which looked like this:

file:..\src\GUI_Particles.cppline:429 28672
file:..\src\GUI_Ship.cppline:733 204
file:..\src\SIM_TargetedModule.cppline:905 48
file:..\src\SIM_TargetedModule.cppline:981 12...

Into Excel, and created a pivot table out of it, to nicely summarise each allocation type by number of calls and total RAM allocated. It was clear that particle allocations were rare, but huge. It was immediately clear that I was allocating memory for a big mega explosion even for the tiniest 7 particle fighter-impact effect. All I did was re-write the particle code to calculate on application-start what the maximum number of particles were that this emmiter could ever need, and then ensure it never allocated more than that when I created it.

Some more work with extensive debug display code mid-battle was done to ensure the new system was working as expected, and that the majority of the allocated RAM was indeed needed and being used.
End result? My test battle (Multari nebula, a fair few fighters, fought to the end with all options turned on) went from a peak of 403MB for GSB.exe to 305MB. That’s pretty darned good. The savings on bigger, longer battles will be pretty noticable.

Expect that improvement to be folded into a future update.