Game Development Reference
In-Depth Information
Notice carefully with each step the call stack window. The moment it is trashed, the
debugger will be unable to display the call stack. It is unlikely that you
'
ll be able to
continue or even set the next statement to a previous line for retesting, so if you
missed the cause of the problem, you
ll have to begin again. If the call that causes
that stack to go south is something trusted like
memset()
, study each input parame-
ter carefully. Your answer is there: One of those parameters is bogus.
'
This kind of bug doesn
'
t have a specific morphology, an academic way of saying
“
”
It does have a common source, which is cutting and pasting
code from one place to another. I know how it is; sometimes it
'
s easier to cut and
paste a little section of code rather than factor it out into a member of a class or
utility function. I
pattern of behavior.
'
ve done this myself many times to avoid a heinous recompile. I
tell myself that I
ll go back and factor the code later. Of course, I never get around
to it. The danger of cutting and pasting code is pretty severe.
First, the original code segment could have a bug that doesn
'
t show up until much
later. The programmer who finds the bug will likely perform a debugging experiment
where a tentative fix is applied to the first block of code, but he misses the second
one. The bug may still occur exactly as it did before, convincing our hero that he
has failed to find the problem, so he begins a completely different approach. Second,
the cut-and-pasted code might be perfectly fine in its original location but cause a
subtle bug in the destination. You might have local variables stomping on each
other or some such thing.
If you
'
re like me at all, you feel a pang of guilt every time you press Ctrl-V and you
see more than two or three lines pop out of the clipboard. That guilt is there for a
reason. Heed it and at least create a local free function while you get the logic
straightened out. When you
'
re done, you can refactor your work, make your change
to game.h, and compile through the night.
'
Everyone hates to run out of space. By space, I mean any consumable resource:
memory, hard drive space, Windows handles, or memory blocks on a console
s mem-
ory card. If you run out of space, your game is either leaking these resources or never
had them to begin with.
We
'
s talk about the other case. If
your game needs certain resources to run properly, like a certain amount of hard drive
space or memory blocks for save game files, then by all means check for the appropriate
'
ve already talked about the leaking problem, so let
'
