Making games run faster is a pet topic of mine. Code samples are too specific to help many people, so here are some general principles I’ve learned.
1) Design to avoid the code.
Sounds horrid doesn’t it, but people do it all the time. ‘Skinned’ animation at points like shoulders and knees is CPU intensive and tricky. Ever noticed how many characters in games have big shoulder-pads? Makes life much easier. GSB is a 2D game, mainly because I prefer 2D gameplay, but I can’t ignore the fact that it would be horrendously more draining on the CPU/GPU to be in 3D
2) Run the code offline.
If the output of your code is a one-off, only ever do it once, and before you ship the game. The GSB campaign game code has some really inefficient slow brute force stuff for calculating planet-travel distances. It’s done as a one-off, and the results loaded in at run time. If there are calculations your game makes at run time that are based on data that never changes, just pre-calc them and load in a table, assuming the table is small enough
3) Run the code once, and cache it.
This is the ultimate big win. In the old days, people used tables of cosine/sine lookups, rather than calculating them. Hold on! GSB does that for some stuff too (nothing gameplay critical). Never make a calculation twice in a function if you can do it once and reference it later. It’s amazing what a difference this makes. even simple stuff like STL list end() calls can mount up with really large containers
4) Don’t run the code every frame.
Not much code has to be run every frame. The minimap in GSB isn’t updated every frame. Can you notice? I can’t, because most frames a ships movement would be ‘sub-pixel’ anyway. If stuff like this seems to jitter, update half the code one frame, the other half the next frame. A frame should be 1/60th of a second. Nobody will notice.
5) Don’t process what isn’t seen.
GSB does some cunning code for all kinds of cosmetic things that only applies if that activity happens onscreen. In theory you can pause the game, scroll around and spot very minor inconsistencies (good luck). With strategy games, most of the time, most of the action isn’t being viewed, so you can skip allsorts of stuff. I don’t update timers for running lights offscreen, for example.
6) Re-order and group stuff.
Graphics cards like to do things in big clumps. give them a single texture, and 50 sprites to draw and they are happy. Give them 50 sprites with different textures and they are not. This is why all the GSB debris is clumped into a single texture, ditto the laser bolts. I also re-order ships in the game code so that similar ones are drawn one after the other, even when drawn as icons. This minimizes texture swaps. Because GSB doesn’t use a z-buffer(for blending reasons), that makes for some spaghetti like code, but it’s worth it. The easiest system I’ve found is to maintain spritelists for different textures. You still draw sprites as normal, but when they draw they just get thrown into the relevant list, and the list gets drawn later.
7) Save stuff for when you are not busy
GSB does this. It’s very tricky, but you can have code that only runs when the CPU is idle. If a laser bolt hits some debris in GSB, the debris explodes. This ONLY happens if the CPU is idling. People spot it occasionally and think it’s l33t. They never spot that it doesn’t happen all the time.
8) Optimize the UI
People get a fast engine then slap some super-slow UI on top. Madness! With a lot of text, icons, dialog box backgrounds and multi-part buttons, you can have crazy overdraw, crazy texture-swaps and huge inefficiency. Keep an eye on it.
Don’t forget that you can also optimize textures too. Some textures are ripe for compression, others not, but you can also do crazy tricks with some stuff, like chop a circle texture into one quarter, and raw it as 4 flipped and mirrored sprites (I do that a lot). Not everyone has 512 MB video cards, and its quicker to load a small texture than a big one anyway.
Most coders probably know all this already, but it doesn’t hurt to recap. It’s easy to forget about optimising and just worry about features, but gamers will thank you for it. I get a lot of people remarking how surprised they are at how well GSB runs on their machine. This is no accident :D.