Debugging and Profiling Your Game - Game Coding Complete - page 803

Using the Debugger
When you debug your code, you usually set a few breakpoints and watch the con-
tents of variables. You have a pretty good idea of what should happen, and you

' ll

find bugs when you figure out why the effect of your logic isn t what you planned.

This assumes a few things. First, you know where to set the breakpoints, and second,
you can interpret the effect the logic has on the state of your game. These two things
are by no means trivial in all cases. This problem is made difficult by the size and
complexity of the logic.

'

Where Is That Bug Anyway?

A screwed-up sound effect may have nothing at all to do with the sound
system. It could be a problem with the code that loads the sound from the
game data files, or it could be random memory corruption that changed the
sound effect after it was loaded. The problem might also be a bad sound
driver, or it might even be a bogus sound effect file from the original
recording. Knowing where to look first has more to do with gut feeling than
anything else, but good debugger skills can certainly speed up the process of
traversing the fault tree a catch phrase NASA uses to describe all possible

permutations of a possible systems failure.

—

Debuggers like the one in Visual Studio can present an amazing amount of informa-
tion, as shown in Figure 23.1.
The debugger provides some important windows beyond the normal source code
window you will use all of the time.

n Call stack: From bottom to top, this window shows the functions and para-
meters that were used to call them. The function at the top of the list is the one
you are currently running. It

'

s extremely useful to double-click on any row of
the call stack window; the location of the function call will be reflected in the
source code window. This helps you understand how control passes from the
caller to the called.
n Watch/Locals/etc: These windows let you examine the contents of variables.
Visual Studio has some convenient debug windows like “ Locals ” and “ Autos ”
that keep track of specific variables so you don t have to type them in yourself.

n Breakpoints: This window shows the list of breakpoints. Sometimes you want to
enable/disable every breakpoint in your game at once or perform other bits of
homework.
n Threads: Most games run multiple threads to manage the sound system,
resource caching, or perhaps the AI. If the debugger hits a breakpoint or is

'