Monthly Archives: June 2009

After a few minutes playing Arm-A II today, it was obvious that camera-motion-blur is really cool, and I needed to get on with putting it into GSB. Half a day of monkeying around with poor documentation and I have it in and working, and togglable etc. It needs some fiddling to get it right still. The nice side effect is that when a big explosion makes the camera shake, the blur kicks in automatically. You can’t really tell with a small jpg, but it’s quite a nice effect in motion. Of course it does have a drawback, in that if you freeze the game in mid-shake-blur and then move the camera, everything is blurred, because you were near the explosion when it happened. I think thats quite acceptable tbh.

I also got some more optimising done today, which means I can consider adding in a few more gratuitous effects for peoples whose gaming PC’s are as good or better than mine, and want the game to look as gratuitous as possible :D

Some people have asked me if the GSB ships are sprites or 3D models. They are put together by an artist in a 3D modeller, then rendered out as sprites top-down, with some fairly neutral lighting. The game then draws them as sprites. There are additional ‘damage’ and ‘hulk’ sprites for damaged ships, and the turrets are drawn separately on top, and flashing lights and engine trails are done separately too.

As normal 3D models they look pretty good, like this in fact:

The problem is, these are VERY high poly models. You might be able to have a game with 4 or 5 of them, but not fity at once, and not with tons more going on, all on an older PC. I think space strategy games work better in 2D than 3D, unrealistic though that may be. I also think that using 3D models to do 2D sprites can give you a good compromise between high detail and decent performance.

Having real 3D models in the art pipeline opens up more possibilities for editing and doing variants of those ships too. I’ll probably do a few renders for the loading screens and the website as well.

I think GSB will turn out to be a game that has some decent screenshots. This is the first one I’ve taken for use as a desktop wallpaper. I’ll get some better (more frantic) ones done at some point, but here is the first one:

Here are the links:

1920×1200 res

1680×1050 res

1280×1024 res

It’s more of an indicator of how much stuff fits onscreen at higher resolutions rather than any attempt at showing off the engine right now. I’ve toggled the UI off for this screenshot. Any thoughts?

I’ve been testing a bit of a worst case situation for the battle screen in the game where there are just TONS of fighters, and they all have contrails and running lights and you try to see as many of them as possible onscreen.

Not surprisingly the game chugs pretty slowly during that. I’ve been looking at ways to speed the rendering up and have realised something I haven’t been doing enough of is lazy execution.

So what is lazy execution in non coding terms?

Imagine your program is designed to tell a robot how to cook (hey why not?). You might have a bit of code that says “Go to the fridge and grab some butter”. That involves a ton of steps, it would involve moving towards the fridge, locating the door, opening the door, removing the butter, etc.

So what you probably do is write some code like this:

FetchItemFromFridge(item)
{
Find fridge
Open Door
Take Item(item)
Close Door
}

And all is lovely and wonderful. Now later on in the programs development you realise you need to do that a lot of items, so your code in another area of the game looks like this:

FetchItemFromFridge(butter);
FetchItemFromFridge(milk);
FetchItemFromFridge(ketchup)

Weird recipe huh? Anyway. this sort of code gets written a lot, especially on big games, because the guy writing the fetchitem code is a different guy to the one writing the recipe code. Often recipe-coder has no idea what happens inside the fetchitem code, so he can’t see any reason to not call it multiple times.

Of course, the sensible re-written code is this:

Find fridge
Open Door
TakeItem(butter)
TakeItem(milk)
TakeItem(ketchup)
Close Door

Now the downside is, that’s a pain to code, because you need to be aware of the circumstances and write code in each case to handle it. This is what lazy execution solves.

Lazy execution means that when I write the code that says “open door”, I don’t actually open the door at all. I just make a mental note that someone wanted the door opened, for reasons we can only speculate about. The good news is, if someone else asks to open the door immediately afterwards, I don’t need to do anything at all.

The real ‘action’ happens when someone calls the ‘takeitem’ code. At that point, the clever lazy stuff says “whoah! you cant take an item without the door being open, I better open that now. At this point, the previous instructions that had been ignored actually get put into action.

The drawback is that the fridge door close needs to be lazy too, which would impact on your carbon emissions :D

Obviously its more complex than that. Incidentally, this is how a lot of directx works. When you call SetRenderState or SetTexture, sod all happens. It only actually does anything if you render something.

The really good news about using lazy code, is that you can optimise anyway all redundancy. In my case the pseudo code causing some issues was stuff like this:

LockVertexBuffer
for each particle
CopyToVertexBuffer
UnlockVertexBuffer

By making the Lock() lazy, the lock is never called (nor is unlock) in cases where no particle needs to be drawn. On big maps, with most of them off screen, this is quite common.

Light Of Altair

June 13, 2009 | Filed under: Uncategorized

I don’t normally blog about other indie games, I find most of them to be a bit too casual and cuddly for my liking, but I just added a new game to the ones I sell through positech.co.uk and I think it might appeal to any of you who are following gratuitousspacebattles.

This is it:

When I tried the demo, I ended up playing it for much longer than I assumed I would. Give it a go.

Linky here:

Light Of Altair