Category: programming

Getting explosions right is HARD. Explosions are (obviously) a big part of Gratuitous Space Battles 2, and I want the GBS2 ones to be better than GBS1 by a noticeable margin. They already are, but I’m aiming for greater heights. Currently the explosions look like this:

And this: (smaller ones)

Which is ‘ok’, but I’d like them to be better, which means spending a lot of time looking at video of space battles (oh the things I have to suffer), freeze framing, stroking my chin and looking at code. There are a number of things people assume about this task which I’ve found not to be true.

Assumption #1: You can do it all on the graphics card. Not so, because different people have different cards, whose capabilities may vary dramatically. I want GSB2 to be playable on a standard laptop, not demand a DX11 driver and card. Plus a lot of these techniques assume Directx11, and you then need a DX9 backup for people who still have windows XP anyway so….

Assumption #2: it’s simply about the number of particles. Not so. I have a fairly efficient particle system that can handle lots, but I have found more does not always equal better. In short, it doesn’t seem to be how many particles you have, but how they interact, what textures they use, and how they move. Render modes (additive vs normal) also factors in a lot.

Generally, my approach has been to have a bunch of particle emitters all clustered together into one explosion. I have some big black clouds that build slowly, some firey small particles that fade out quickly (additive ones), some flame-texture particles that are additive, and some not additive, and I render them in a deliberate order and it looks like the stuff you see above, which is fine, up to a point.

The thing I haven’t managed to really convey is the ‘billowing’ effect of an explosion. Here are some of my reference images…

This sort of thing is very hard to get right ‘in-motion’ because it involves some 3D movement of frankly millions of particles, so obviously the first question is how on earth to ‘cheat at it’ and get it looking vaguely right. In Gratuitous Stank Battles I tried a complex system where particles had #heat’ assigned to them, and cross-faded between white hot to black smoke (and different textures) over time. it looked ok, but probably not enough difference to warrant a bucket of extra code that was associated with it.

I am starting to think that decent explosions are 90% physics, 10% graphics. What I need is some more complex control over the movement of individual particles, rather than just more of them. With the explosion at the bottom, I’m thinking that there are a bunch of different ‘focal points’ of the explosion, different ‘billow-centers’, if you will. There has obviously been a central ‘bang’ and this has ‘spawned’ a bunch of airborne ‘flame emitters’ which continue to create new burst of flames which are created, balloon up, and then down and dissipate.

Currently I have zero support for such a system. An explosion is a single event, which may have a bunch of timed emitters with it, but it has a single focal point. Secondly, a particle has a single growth variable, which means it either is spawned and gets bigger over time, or it gets smaller over time. What I may need is the capacity to associate a timed sinewave with the size of a particle.

So my latest explosion todo list (fun stuff I do when I’m not busy) is something like this…

Add support to particle configs for a ‘sinewave-based’ growth variable, with starting size, max size and duration.

Create a new class of object called a GUI_SubExplosion, which can be spawned by an explosion and drift off from the central point slowly over time. Have that sub-explosion itself contain a list of particle emitters that it manages.

Should be worth a try anyway… In the meantime here is the latest big pharma blog video. and a nice article on showmethegames about banished.

Below is an image from Gratuitous Space Battles 2‘s ship design screen. On the left is my problem. That’s a load of ship components you can add to a hull, rotate, change size, color etc. All very cool. The problem is that you might choose to have BIG versions of some of them, as main structure bits, so the source graphics have to be big, normally 256sq for sub-components.

Ok, so that’s cool, but the problem is, when I load in those icons I’m loading in a DDS file that is 256 square, which means about 170k in the format I’m using. If I have 300 of them (rough guess) then that’s 51MB of file access, which is bad but not catastrophic, but it does mean 300 distinct file accesses, which is slow, even after I’ve rewritten the DDS loader to be massively faster. As a result, when you click on ‘edit appearance’, there *might* be a slight delay, which is intolerably awful for someone like me with zero patience. And I have a FAST PC, I want this to be fast and smooth on low-spec.

So as I see it the options are:

1) Only load visible ones, then load the others as you scroll (could be irritating for scrolling)

2) Load in placeholders, and spin off the file accessing portion of the texture load into a separate thread, then when they are all there, interleave the texture creation with the display frames of the main thread (DX9 so only main thread may do DX stuff). This seems ultra complex and hacky.

3) Save out small preview images for each item, and load those instead. Less memory, but a bunch of useless duplicate files AND still 300 file accesses.

4) Stick em all in a single big pak file and see if that’s quicker. This is easy, but I find it messy during development as I’m always adding/removing/editing files in those folders, so I need a hybrid debug/release system.

I think I might have to go with 4…