Category: programming

Today, I was awake at 6am as it was holiday morning. Not for me, I’m staying here, but it means I was awake at 6am, and naturally, ended up programming by 7.30am.

Sooo… I thought I’d get the screen res code done today, and here it is at 11.55PM and it’s still not 100% what it should be. I’ve stopped for food twice, and didn’t linger over it. Bah.

Now granted, I spent maybe two hours dealing with the upcoming German translation of Democracy 2, but the rest of the time I’ve had my head buried in the directx documentation trying to find out just how the hell it’s supposed to handle a screen res change under directx9. I finally got there, and I’m still ironing out the bugs in certain circumstances, but my main objective now at least looks doable, which was to retain the feature all my games have of ‘in-game’ resolution toggling.

I HATE it when games ship with a separate ‘launcher’ app that you use to set the screen res. It’s just so fiddly. I much prefer being able to fiddle with such things, especially windowed / fullscreen toggling ‘on the fly’. I doubt it will be possible mid-battle, but at least it will be a part of the main app itself. Plus it makes it trivial for me to test that the GUI works in all resolutions. 768 really pushes it height wise, but I’ll sort it.

Today was not fun, it took longer than it should had, and it was seriously frustrating and involved. The idiot who knocked on my door to try and doorstep-sell me energy supplies got told where he could shove his special offer :D

I spent part of today adding new explosion effects to the game. Until now, all my particles have had random rotation. This makes them look natural, but for some explosion effects you want the particles to be ‘stretched’ and thus for them to be angled in the direction they face. Anyway, that’s in and looking good.

Also today I added some basic physics to debris so that when there is a big white explosive flash, it’s applied as a force to the debris which makes the explosion seem more 3D and impressive.

I’ve also been thinking about techniques to reduce the number of texture-swaps per frame, which is currently scarily high in some cases. I can’t easily use z-buffers for the game because the huge amount of alpha-blending that I do. (I tried it, and its slower). One thing I’m considering is more use of (manually assembled) texture atlases, another is to make greater use of concurrency by scheduling some tasks for processing by the CPU while the GPU is busy swapping textures.

I havent implemented resolution changing yet, but I’ll be taking everyone’s suggestions for doing so on-board on monday when I do it. I suspect I’ll display all options above a certain minimum height.

Currently there are two anti-missile weapons in Gratuitous Space Battles. Point Defence Lasers and ECM beams. The point defence laser basically tracks incoming missiles and just zap them. They always hit (at the moment) and take one out. Of course, they can be overloaded,e specially by multiple-warhead missiles, but they are pretty cool. The other one (ECM beam) does exactly the same, but rather than destroy the missile it scrambles its guidance system and there is a cool wibbly wobbly effect as it veers everywhere. In the final game, the choice between them will probably be some sort of crew/power/cost/weight trade-off.

The thing they share though, is that they can ONLY target missiles that are aimed at their ship. You can’t have an ECM frigate at the spearhead of your fleet zapping all the incoming missiles to screen your capital ships from attack.

Clearly this sucks.

The solution isn’t trivial though. There are a LOT of ships in GSB and a LOT going on. if I’m to enable anti-missile weaponry to select from any missile on the map, that will involve a lot of processing. My mind is agog with quadtrees and other methods of limiting the amount of times each weapon has to do this:

for(each missile)

{

are_you_the_closest_one?

}

etc. It would normally be a trivial thing, but it’s something that isn’t in the game yet because it hasn’t really been necessary. The question is, do I write some big generic system that every piece of taregt selection will reference to find the nearest object? if so, that involves a fair bit of re-work, and it’s likely to be a several-cups-of-tea and a free morning sort of problem.

Stuff that is currently slow in really hectic games:

• The ‘smart’ sprite texture for the shield impact sprite gets created and destroyed a lot at runtime
• The sound engine spends a lot of time looking for free sound channels or cached sounds
• Drawing of blast textures for bullet turrets is slow somehow. Lots of small 2-primitive draws I suppose.
• Drawing Missiles and missile glares and trails
• Drawing debris

I love optimising, and the frame rate isn’t too shabby even with all hell breaking loose, but it would be cool to get it much better in the hope of adding some really gratuitous extra effects later on for fast cards.