Category Archives: programming

Stuck on a normal map thing…

December 12, 2014 | Filed under: programming

My lack of maths skill will be my undoing…

I have some normal maps, you know the kinda thing…


And I have all the code (dot product stuff) that plugs in the float3 that is the light direction, and then gives me a tint I can apply to the final pixel to get a nice pseudo 3D bump map effect. Thats all lovely and works, and is cool. The problem is, when I want to rotate that bump map, it obviously all turns to crap :D

This is NOT a case where I can just liue about the light angle, I already get all that… What I need (for this pre-processing cleverness) is a way of taking that image above, and effectively rotating the whole thing by a given angle, and working out what all the pixel colors would be in that case. This is an arbitrary rotating value (so not just 90 degrees or whatever). I’ll work it out eventually, but I suck at this, and I bet it’s easy. This isn’t speed-dependent stuff so slow is fine, either pure C++ maths or some shader code.

My current shader code for rendering using the normal map:

float4 normalcolor = tex2Dbias(g_samNormalMapColor, texCoord);
normalcolor.b = 0; //experiment to force only r or g channels

//convert it to +/- 1.0 range
normalcolor *= 2.0f;
normalcolor -= 1.0f;

float3 LightDirection;
LightDirection.x = cos(sprite_angle);
LightDirection.y = sin(sprite_angle);
LightDirection.z = 0;

float dot_prod = dot(LightDirection, normalcolor);

Thats just lovely, and obvioously I could lie about the angle I put in, but then how do I get the red and green out of it?

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.

Multithreading concurrency bug?

October 18, 2014 | Filed under: programming

I have a theory, help me out if you know about this stuff. take the following image from the visual studio concurrency profiler for GSB2 pre-draw code…

8156,6792 and 8404 are my additional worker threads I spawn to help me process stuff. Click to enlarge…

threadsWhat I do is basically build up a queue of tasks. The threads are always running and checking for whats next available to process for them. Meanwhile the main worker thread also does the same thing, ensuring it is not idle while the other threads are busy. Critical sections surround access tro the queue stuff to ensure there are no nasty bugs.

I think my problem is illustrated by the red section with the black line connecting above it. This is a thread sat there doing nothing. Here is what I think happens…

  • The main thread builds up the queue of stuff to do.
  • 6792 jumps in and grabs a task to do
  • 8404 jumps in and grabs a task to do
  • The main thread then thinks ‘right then, I’ll do this next task’
  • 8156 wants to jump in now and also grab a task, but the main thread is busy doing actual work. In fact, it seems to ‘miss’ its opportunity to grab a task for ages, even though the other threads do ok getting task after task.

Is this just a problem of my code design because the allocation of tasks is done by a thread that is not otherwise idling? It seems horribly wasteful to have a whole thread work just as a 99% idle ‘task allocator’. I thought cpus were clever enough to allow interruption of one cpu by another in these instances?

I know I could queue up the tasks ahead of time, but each task takes a variable amount of time, and also varies each frame. I *could* work off the last known task timings and write a clever allocator that tried to assign things in the best order, but that seems possibly like overkill, and something the cpu surely handles anyway? Or am I totally misreading this data. IO checked a few frames, they all seem to have the same pattern.

So I thought I’d put together a video showing what I’ve been doing on gratuitous space battles 2 since the Eurogamer show. I’ve also been recovering, and doing under-the-hood engine stuff and bug fixing. Enjoy… (& share/tweet post to websites etc :D)

And on the topic of developer videos.. check out the big pharma dev blog video below…

There are no comments yet

Optimizing dilemma of the day

September 15, 2014 | Filed under: gsb2 | programming

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…