Category Archives: programming

A mixed bag of stuff this week. I’m crunching away boih at bugs, and balance issues, which make for a poor video, but also luckily we now have lot-expansion plus some zoom-out UI shininess to look at, plus I fire up nvidia nsight to give you a quick preview of how a frame gets rendered in the game. (FWIW I use my own engine, based on directx9 which means I need to worry about draw calls when changing textures. One day I’ll switch to a newer directx version, but I feel no pressing urge to do so yet :D.


There are no comments yet

This is the short ‘story so far’ on animation compression for Production Line, my next game. I use my own engine that runs on directx9,a nd the game is isometyric in style, so uses a lot of spritesheet-style animation frames. In short, this is about how I enable animations like the one below (excuse the crappy gif compression, actual image is less pixelated in the real game), to fit into tiny amounts of video memory. (The disk version of that anim is 4MB, compressed for download its 355k). This is an ‘idle’ anim of a marketing manager in the game checking his phone to make all-important marketing related phonecalls…


You might think that cannot possibly be a 4MB animation, but you would be dead wrong. The actual source graphic is 128 wide by 256 high, after cropping, meaning that a frame of it gets delivered from the artist looking like this:


Thats no problem, but a complete animation cycle is 300 frames long, and I need two versions, one to look towards, one away (I can flip in X axis for the others). 128 x 256 x 300 is 9.8 million pixels, or a 4096 x 2,400 pixel sprite sheet, which takes up 39MB of VRAM. Assume both directions are in use = 80MB, 3 different characters is 240MB. Thats with one skin color and one gender. Ouch. So obviously we need to compress it.

I rolled my own compression system for fun, and to give me total control over how it works. The first step is to cut out any dead space and remove any duplicates. When our little dude is on the phone, the image doesn’t change, so we have a lot of duplication in that colossal theoretical sprite sheet. How did I approach this?

I decided upon a 64 chunk ‘grid’ for any image that would be animated, dividing it into 8 sections horizontally and vertically. With the raw image I get given, that gives me this:


Actually this is annoying because his hair only just clips into another row, which is inefficient… never mind. The most obvious thing here is that a lot of the animation frame is just empty space. In order to kill both the ’empty space’ and the ‘same as last frame’ problems in one go, I work out a CRC (basically a unique signature) for each of those grid squares, for each frame, and store it in a great big list of data as a pre-processing step.

With all that data in memory, I then go through each chunk of each frame, and look for previous frame chunks with the same CRC. If I don’t find any, I mark it as a ‘used’ chunk. if I do, I just make a note of which earlier chunk to use, and increment the use count on the old chunk. Once this is done, I can go through all the chunks and discard the ones that have a zero use count (or are blank).
Stage two is to create a whacking great spritesheet of all of the chunks that I actually *do* use, which looks like a weird mashup of imagery like this:


(It also has an alpha channel). I can then go through all of those ‘used’ chunks and make a note of the UV values for each of them in my new spritesheet. Now, the final stage is to go through every frame of the animation, and make a note of which chunks actually get drawn, and the index into my list of ‘used’ chunks. This means I now have a big text file for the animation that tells me which of the 64 maximum chunks of the spritesheet I need to draw in each frame. In the case of this phone-dude, that shrinks the actual texture memory usage by 95%, meaning I can easily have a bunch of different animations.

Thats where I am right now, and its pretty fluid, and works without bugs. The next step will be optimizing the code, rather than the source. An optimisation I managed today was to actually successfully only draw the non transparent chunks when I do the rendering of each frame, which reduces the number of polys and draw calls. The next obvious optimization is to spot when a chunks ‘source id’ is the same as the previous frame, and then not bother updating it at all. Right now, I redo the UV lookup and apply the values every frame for this dudes legs, even though they don’t move during the whole animation. Thats a bit too much processing for my liking.

I’m sure middleware *does* exist that does this, but I like to code stuff myself so I know 100% how it works, 100% how fast/slow it is, and can ensure compatibility with all the rest of my code and workflow. I’ve probably spent a week doing this, maybe a bit more, but I have a pretty cool system now that lets me knock up a 30 secon text file when I get a new bunch of animation source files, then hit the launch button and the game will do all the preprocessing and give me the compressed data automatically. Yay.

This also means that with only 4MB+4MB of VRAM for an animation for a character, I could double the characters, and have both genders without running out of VRAM. This also makes the game more usable on low end PCs. Now the limit is my art budget, rather than the hardware :D Anyway here is a reminder of the final video, and also that this is for my car factory game: Production Line


Occasionally I see some interesting posts on reddit or gamasutra or some other dev site where programmers are asking about stuff to do with game development, and I find myself thinking ‘these aren’t the things you really ned to know’, but because its such a DIFFICULT thing to articulate, I never even try. I’m going to try now…and it will be messy.


A long time ago, when the world was in black and white and you could get your milk delivered even in the cities, I went for a job as a game programmer with a smallish UK game studio. I didn’t get the job. I remember in the interview being asked about my code, and in some vague way trying to explain that I knew what I was doing and a proper software developer. I waffled really badly about how giving sensible names to variable meant that I knew what I was doing and not some n00b.


In my mind…this:

for(int counter = 0; counter < total; counter++)

Made me so much better a software engineer than

for(int x = 0; x < total; x++)

That just goes to show how much I had to learn. The real problem is that the stuff you need to learn is big ‘hand-wavey’ stuff that its really hard to explain, let alone teach! if you haven’t already read a book like Code Complete, Now would be a good time. I will try and explain the sort of stuff that it really helps to learn, and it will be vague and awkward, and hopefully that kind of makes my point about how hard it is to grok this stuff.

I have a class in my latest game called GUI_Tile. Its the visual representation of an actual tile in the game world called SIM_Tile. Each SIM_Tile has a GUI_Tile, and anything that is on-screen is handled by GUI_Tile. In order to draw my world, I go through all of the GUI_Tile objects and call draw on them. Actually, thats what I used to do, but it turns out there are a lot of them and thats fairly time consuming. When I profile the code, looking at where the time is spent, I realize that a lot of it is not actually directx calls, but its transform stuff, and scaling stuff, and working out the sizes of sprites based on some animation they are doing, and their offsets and whether or not they are even on-screen given the current camera position. The actual DrawSprite() bit of each GUI_Tile call is only the last statement…kind of a footnote.

While all this is going on, the other 7 effective cores of my CPU are chatting about whats on TV and picking fluff from their navels.

So clearly, I should find a way to multi-thread all this, even though I’m using Directx9 which is effectively single-threaded.

Soo… I could create a new thread at the start of the app, and make that my directx render thread. it could then do nothing but make render calls, and all the other stuff could happen in another thread, thus allowing me to double up on what was going on. To keep things from going crazy, and me updating a sprites co-ordinates just as directx rendered it, I need a hard STOP! (or mutex etc) at the time I start rendering, but it will still allow some overlap surely? I could carry on with the windows message handling and sound/input processing in thread 2 while thread 1 was still rendering the previous frame.


I could split the GUI_Tile::Draw() call into GUI_Tile::PreDraw() and GUI_Tile::ReallyDraw(). If all of the stuff in the PreDraw() is self contained or ‘read-only’ (in other words that function never changes the value of any data outside its own object), then I can run a whole bunch of those at the same time. I can keep my directx in the main thread, but pass all the tiles in bunches off to 7 other worker threads to do PreDraw(), then when they ALL finish, I can just quickly loop through the Draw() calls, which are way faster.


I could not do a lot of this transform stuff or drawing stuff each frame anyway. I could use a dirty-rects system, where when I render a frame I keep a copy of the whole thing in an offscreen buffer. I then only bother calling Draw() on those tiles which I know have actually changed or done anything. That way I’m massively cutting down on the number of Draw() calls I make, and I can keep the entire thing in one thread and thus way simpler.



The real thing you need to learn to be a decent game developer, is which one of those solutions will work best for this game, with this hardware, with this API, with this data. Coding any one of those solutions takes TIME. Debugging them takes more time, and profiling and analysing to see which works best takes more. Maybe having 8 threads all running is actually slower than just one (this can happen if you do it badly). Maybe a dirty rects system falls apart dramatically when zooming and scrolling. Maybe assuming PreDraw() is a nice self contained function is a bug-prone disaster waiting to happen in obscure and impossible-to-debug ways.

This is the real hard stuff, and the main reason its real hard is that its very difficult to get on top of this sort of thing until you have done it a LOT. If you have programmed, for example, a sound engine…well done. Take a bow, its honestly not that easy, and I bet you learned a lot. You have programmed your FIRST sound engine. Now delete all the code and program it another way entirely. then again, then again, then again. NOW, you know how to program a sound engine. you know why method A is slow, why method B is buggy, why method C is hard to maintain, why method D doesn’t scale, and method E Is awesome, but only on Playstation 4.

This is why the top jobs often to go to coders with experience, and why the sheer amount of code you have written and the number of hours you have been typing code really does matter. Being a good programmer is rarely about those things that are often bandied around like ‘always comment your code’ or ‘use descriptive source control commit descriptions’ or ‘use this syntax in your code’. Its mostly about the big ‘code architecture’ decisions. The way you lay out your code, the overall designs, the thinking behind how the whole process snaps together.

The most efficient coding you ever do is probably with a pen and paper, or a big chalkboard on the wall. When you have done this a LOT, you can do that in your head, but that takes decades. The more you code, the better you get.


I guess that a lot of people who read my blog are programmers and a lot of them are younger than me. I’m now 47. I was coding a new feature for Production Line yesterday, (the colored overlay & icons for the zoomed-out view) and it occurred to me to kind of ‘live-blog’ it in my head as I was typing, wondering if it would be of interest to people if I recorded doing that sort of thing in a video. Maybe if you are new to coding, or wondered what the real-world dev process for coding a strategy game was like…it might be interesting.

As I did it, I started to realize it would be VERY hard to follow if I did it. Frankly I can code faster than I can describe what I’m coding. Much faster. In fact I write C++ code faster than I write this blog. Visual studio has Intellisense, and I use Visual Assist (from whole tomato) to make use of their even smarter intellisense, so I’m only typing a few characters of each word anyway. Plus…after coding since age 11…I can pretty much write the iteration of an STL container in a for loop and call member functions whilst drinking tea (or on the phone to someone).

I am often AMAZED at how long it takes some people to make a game. I know that sometimes these people are perfectionists and they put a lot of ‘craft’ into their games, and they agonize more about design features than I do..and often it pays off with those mega indie hits that don’t look technically hard to make, but have such good design or polish that they sell a bazillion copies. I totally understand that, and I admit that I don’t spend *enough* time on my games (although I intend to change that with production line, which deliberately has no schedule or end date.

What I do *not* understand is the time it seems to take people, or the effort they seem to think is involved, when it comes to implementing a particular feature from a technical point of view. This is especially true when those people use ‘managed’ code or a higher level language, or unity or some other middleware. Frankly if an old fashioned dinosaur like me can code a feature from scratch in C++ in a day, then the younger more savvy kids with their middleware should be able to do it in an afternoon, but that never seems to be the case. For a long time, knowing this has driven me nuts, until I eventually have concluded that its just because I’m older, and have a scary amount of experience doing one thing day-in and day out for DECADES.

I literally have been coding longer than most indies have been breathing, and its always been in C++ (Actually I think Asteroid Miner may have been C) , and always directx, and always for windows. I went from DX5 to 7 to 9, but thats it, I’m still on 9, and I know it well.  As a result, when I’m coding, unless its some complex multi-threading stuff…I’m probably not  ‘coding’ as much as I am just typing. I know the code to type, and it flows immediately from what I want to achieve. Its just a matter of hitting some keys on the keyboard.


I think this is a big advantage to not being a magpie when it comes to new software and development environments. I still use Visual Studio. I still use C++/DirectX. I still use perforce, I still use Photoshop and paintshop pro, and AQTime and nvidia nsight. In the last year or two, the only change to my development environment has been that I now also use the Visual Studio Concurrency Profiler, which is excellent. Thats one new piece of development GUI I had to learn in 24 months of work.

As you can imagine, this makes life extremely easy. I also coded my own graphics engine, which means it never changes unless I want it to. I don’t have to ‘work out the bugs introduced by the latest changes’ in the engine, because there aren’t any, and if there are, I did them, and I know what I did. And obviously I have all the source code anyway, and can roll-back whenever I like. Its easy. Never underestimate how much keeping a stable work environment can boost your productivity.

In addition, I also am a bit of a workaholic (which helps), plus I have no kids and only low-maintenance pets (cats). I live somewhere incredibly quiet and am rarely disturbed. My office is dedicated to my work, not shared with anyone, and its quiet, and laid out very comfortably with a comfortable chair, big desk and lovely big monitors, so its a nice place to be. This all definitely helps.

My tip to anyone finding their coding productivity low is to resist that urge to upgrade to the new X, or the new Y, or to make any change to your work environment just because you like new things. Sometimes keeping things the same is the best way to boost your productivity.

Drawing a LOT of sprites

August 29, 2016 | Filed under: programming

I’m doing early work on my next game, a completely new IP. I’ll be announcing it in a few months. Anyway… it involves drawing a big world with a LOT of objects in it. tens of thousands on screen probably. Drawing 10,000 objects in 2D is not as simple as you think.

If you are a non coder, or someone who only ever uses middleware, you might think ‘the new video cards can draw 10,000,000 polys per frame, what’s the problem? and indeed there is *no problem* if you want to set a single texture and then splat 5 million sprites on the screen that show it. Thats one (well…probably several) draw call, one render state, one texture. Even really old video cards like that.

The problem is when you have a lot of different textures and want to swap between them, because for engine-related reasons, you need to draw stuff in a specific order. In a 3D world, you can use a Z-buffer and draw out of order, but with 2D objects with some soft aliased edges, that looks BAD. The good old fashioned painters-algorithm is your friend. The problem is, if you draw back to front and the sprite textures needed go A B A B A B, you are kinda fucked…that means a lot of texture changes, and in directx9 (which I use for compatibility reasons), texture changes mean separate draw calls, which stalls the video cards, and is sloooowwwww.

Relevant video from GSB2:

So what are the workarounds?

Texture atlases. This is the obvious one. Stick A & B in the same texture, and you are laughing, suddenly stuff is a LOT quicker. This only solves the texture issue, not drawing to different render targets, but you can defer those draws anyway and do them separately (GSB 2 does this). Texture atlases are an obvious ‘win’ even if they only halve the texture changes. The problems here are that you either need to know what textures will follow each other and pre-compile texture atlases (something I’m trying right now), or you need to dynamically create texture atlases based on recent drawing, and effectively use an off-screen render target as a texture ‘cache’. I tried this recently…and it was actually slower :(

Dirty-rects. Basically draw the whole scene once, and save it in an offscreen buffer, and use it as your background, a single quad blaps the whole screen, and you only draw stuff that has changed / is animating. This, as I recall was used by sim city 4. The only problem is that scrolling really causes hell.

Intelligent grouping. The painters algorithm is only really needed where stuff overlaps. if I draw a tile, then draw a sprite on top of it, I need the tile first, but there is no reason why I can’t draw all the tiles first, then the contents. That means I can then sort the tiles by texture and draw them in a handful of calls (or one, if the tiles all fit into an atlas). You can do this at pretty much any level, effectively drawing ‘out-of-order’ but with caveats. Again, GSB2 does this, with various objects, especially debris and asteroids. In fact it goes one stage further by scanning ahead with each draw call to see if some non conflicting later objects could be ‘collapsed’ into the current draw call.

Multi-threading and other speed boosts. If you have too many draw calls and things are too slow, then you can expand on the time available to make draw calls. Essentially you have two threads, one which prepares everything to be drawn, and the draw-call thread, which makes all your directx calls. This way they both run in parallel (also note that the directx runtime will be another thread, and the video card driver another one, so you have 2 threads less than you think. With a hyperthreaded 4 core chip, you have 8 truly simultaneous threads, so you give away 2, have 1 core thread, 1 render thread and 2 extra ‘worker threads’ spare. Because of my own disorganisation, I tend to have directx called from my main thread, which means I do the inverse. GSB2 did this, with all of the transformation stuff for the asteroids, debris and other bits and pieces handed to a bunch of threads while I was busy with other stuff, then returning to the main thread to present the draw calls. Less efficient, but way better than single threading.

Hybrids. All of the above techniques seem valid to me. Although I am currently fixated on pre-compiled texture atlases, I’ll definitely use multithreading and probably some of the others. With some parts of a game, a specific optimisation system may work well, and with others it could be useless. It really is specific to what you draw, and is why I prefer a hand crafted engine to a generic one.

My basic problem is that (without explaining what the game is), I have a small number of ‘components’ that make up a tiny scene on a tile. There will be a lot of components per tile, as I want a fairly ‘busy’ look, but rendering them all individually may be ‘too much’. What I may end up doing is pre-rendering each conceivable tile as an offline-step, to reduce the number of calls. I’d like that to be a last minute thing though, so I can keep editing what the scenes look like. IU also want sections of each tile to animate, or be editable and customizable, which means there is less scope to pre-render them.

It will make a lot more sense once I announce the game :D