Category: programming

EDIT: I’ve fixed it. It’s my own dumbassness. I was setting the sprite_angle variable in the shader AFTER the shader had started, and it was presumably never being set, and populated with garbage (or the ship beforehand) it works a charm now :D

Right so, despite being good at AI coding and optimisation, i suck at this clever stuff you people call ‘3D math’. I was in the pub that day of school. So I enlist you, the all-knowing internet to explain to me like a child what I am doing wrong. Here are 3 images:

The left is just the ship, the middle is a normal map thingy (thanks to charles!) and the right is what it looks like on screen given a single light source. The end result is exactly what I wanted, and there is much rejoicing… BUT. It’s screwed up, the position of the light source is wrong, and seemingly random, and sometimes jumps and cycles all over the place. I reckon I have everything sorted except the shader, which is an fx file as follows:

sampler2D g_samSrcColor : register( s0);
sampler2D g_samNormalMapColor: register( s1);
float sprite_angle : register(C0); 

float4 NormalMap( float2 texCoord : TEXCOORD0 ) : COLOR0
{  
    //get the value of the normal at this texturecoord
     float3 normalcolor = tex2D(g_samNormalMapColor, texCoord);

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

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

     float dot_prod = dot(LightDirection, normalcolor);

     //apply as a tint to the final pixel
       float4 original = tex2D(g_samSrcColor, texCoord); 
       float4 final = original;
       final.r *= dot_prod;
       final.b *= dot_prod;
       final.g *= dot_prod;

       return final;
}

As an idiot, I’m not really sure what I am doing here. What I *think* I’m doing is this: I am drawing a sprite which has a separate normal map (g_samNormalMapColor) I also pass in the current angle of the sprite. I sample the color of the normal map, and convert it into the required range. I then convert the sprites angle into a light direction vector (probably wrongly) and I then do some magic which kids call ‘dot’ which I’m guessing gives me the brightness of the pixel given the angle and the default light direction. I then multiply the original texture color by this brightness to tint my final rendered sprite. Yay.

it’s something clever to do with angles and vectors and stuff isn’t it? explain it to me like I’m an idiot :D

 

And yeah…I’m playing about with Gratuitous Space Battles. It’s a Sunday morning, don’t read too much into it :D

I’m enjoying myself with some optimizing today (yeah I’m weird like that). So I thought I’d jot down some of my tips for making your game faster. These are general, not language-specific tips.

Never run code you don’t have to run

Seems obvious but few people actually do this. For example, in democracy 3, the simulation calculates the popularity of each policy by asking every voter if they benefit from it. That question is complex, and there are a few hundred policies and 2,000 voters. This takes time. Solution: I only ask them about a policy if I need the answer right now. Some policies can go a dozen turns without the player ever checking their popularity, so why keep calculating it?

Batch Stuff

If you have a dozen icons that are always drawn one after another on the same screen, stick them in a texture atlas. If you are 100% they will never overlap, then draw them in a single draw call. the less texture swaps and draw calls, the faster your code. This is trivial to do in 3D, an absolute nightmare to do properly in 2D, but it’s worth it.

Cache Stuff

If you have a variable that is complex to evaluate, evaluate it once, then cache it until it changes (we tend to call that setting it ‘dirty’). If there is some data that is going to be accessed a LOT, then make a local copy of it. And if you have a lot of stuff to write to disk, to the same file, buffer it. Writing to or reading from a file is slow, especially if you are going to do it a lot. Reading in a single file is much quicker than opening 200 of them one after another.

Don’t use sqrt()

Do you ever use sqrt()? never realised how scarily slow it was? Most of the time you can keep the squared result and use some clever tricks to not actually need the sqrt() result. If you were going to get the sqrt() and compare it against a value, just multiply the comparison value by itself and check it that way instead. it’s amazingly faster.

Use the right container class

Sometimes you will use a list where a vector will do. The vector is MUCH faster. And you know what is faster still. I mean REALLY fast? An array. If you really need speed, and the array size won’t change that often, allocating an array of items is much faster and is worth the overhead.

Re-use objects

If you have a collection of objects that keep getting created and destroyed, you want to wrap that up. Stick a factory object around them to handle their construction and destruction. That way, you can just set them inactive on destruction, and save yourself the hassle of the creation and destruction when it comes time to re-use them. Setting a single flag to say an object is ‘dead’ is way faster than calling a destructor, and resetting is way faster than a constructor.

Obviously there are lots more tips, and you should get a decent commercial profiler. That PC you develop on is a super-computing beast. if your game takes more than a few seconds to load, you are being sloppy.

 

I’m not a multi-threading expert. my main process trundles along nicely then when loading the game it calls CreateThread() to do some loading stuff. Then, while the main thread is rendering my lovely loading screen, and the new thread is loading in data, some evil player hits the top right X button, or alt+F4s the game…

Instant crash!

Unless I add code which calls my thread manager and then calls TerminateThread(). This works…but then the app does not actually properly quit, so it can’t work right. Also… I now read that TerminateThread() is not the way to exit a thread anyway, and I’ve been using it all this time… arghhh!

How do you handle quitting a multithreaded app when the player arbitrarily exist it? Nobody seems to have a definitive answer…

How I envy developers working on arcade games, or anything that has a very simple game ‘state’ that can be easily saved and loaded with no grief. For the game I am currently working on (announcement later this month), it’s a bit of a pain, because the actual game ‘state’ is horrendously involved, and every single byte of it has to be loaded and saved perfectly. The problem is mainly due to my tendency to code systems that have a huge number of objects that all have pointers to each other, in complex and arcane ways.

In theory, stitching everything back together after a load is fairly easy, but in practice, it’s a bit of a pain, and the REAL pain is to know that it has all worked perfectly. if 99% of the pointers are right, and 1 isn’t, then I have a horrible dangling bug somewhere…

My current process for preventing this is to have the game completely save out it’s state and load it’s state back in every turn (it’s a turn based game). At the moment, due to arcane debugging issues this is horribly slow, but eventually will be super fast. At least doing it this way means that during development I’ll spot any save/load inconsistencies really quickly.

I’m aching to get on with some GUI stuff to make it look nice, but I’ve learned the hard way that I have to put that off until the foundations work better. Better to have it stable now, rather than fix it later.