Game Design, Programming and running a one-man games business…

Knowing what your code does

cliffski

Do you know how your game works? I bet you *think* you do. And if you do, there are never surprises when you suddenly take a look at a frame of it being rendered. Invariably, mistakes mean stuff works differently to how you intended it to.

I use AQTime, which is pricey as hell, but fantastic, as a profiler. You can control it from code too, so I can pause my game mid-battle, hit ‘F’ to go one frame-advance, and that frame is profiled by aqtime. It then will dump tons of stats, telling we call times and counts for every function (or even line)  and let me see this:

This chart immediately tells me that some lightmapbuffer sprite code was being run. It should be skipped in daylight levels, so clearly I have a bug. And that’s before I even begin to look at performance optimisations in this frame.

If you write big complex stuff and don’t have a professional quality profiler, you need one. They are absolutely fantastic.

3 thoughts on Knowing what your code does

  1. I’ve found the ultimate solution for profiling. I’ve tried Microsoft’s, a ton of open source “solutions”, professional toys like AQTime, and they all suck compared to what I’ve got.

    Basically what it is, is a python script that takes any cxx file as input, and does some basic parsing to determine if if it’s an actual statement. If it is, it generates a random 80 character string and inserts a printf() of that string. It keeps track of all the printf random strings and makes sure there are no duplicates.

    Now whenever I run my program, I just capture stdout and I get an endless bounty of profiling information. I can run standard CLI utilities like pipe the output through sort and get counts of the busiest stuff, or I can paste it all into a spreadsheet and shrink the font way down and look for patterns – full on branch prediction!

    If I can completely rule out the need for various strings, I can cut down on my binary’s size, and optimize the shit out of it! What I’m working on now is training up a neural network to try to predict what strings are going to happen next. I’m a little concerned about people reverse engineering my finished products, so I was thinking about shipping it as the strings, all preloaded into a python dictionary (fancy term for a map), which links up the compiled code with the strings. To execute it, it’ll read in 80 characters at a time, search through the map until it finds a hit, and then runs the corresponding assembly instruction.

    Pretty sweet, eh?

    (But seriously, thanks for sharing this stuff Cliffski! I absolutely love that you take the time to share (with pictures!) the sorts of inanities you have to put up with in being a one-man show. GTB screens are looking sexy, any chance pre-ordering will give beta access?)

  3. printf() is an slow, cache-unfriendly function. If you’re using it in the middle of performance oriented code, your performance measurements are likely to be highly incorrect.

Comments are currently closed.