Game Development Reference
In-Depth Information
Data Breakpoint
Suppose in a C++ game you have a member variable called m_Alive that tracks
whether the particular game object is alive or dead. While debugging, you no-
tice that sometimes the m_Alive variable is changing even though the object
in question never called the Die function to set it to false . This has to mean
that somewhere and somehow, the memory location that stores m_Alive is being
clobbered by bad values. This can be one of the most frustrating types of bugs to
solve, because the culprit could be a bad pointer access literally anywhere else in
the code.
One feature that's immensely useful to solve this problem in Visual Studio is
the data breakpoint, a type of breakpoint that only works in C/C++. A data
breakpoint tells the debugger to pause the program whenever a specific range of
memory is modified. The size of the memory range typically is 4 bytes on 32-bit
systems and 8 bytes on 64-bit ones, and the number of data breakpoints allowed
depends on the system.
In our scenario with the m_Alive variable, in order to set a data breakpoint we
would first put a regular breakpoint in the constructor of the game object. Once
that is hit, we could then select from the menu Debug, New Breakpoint, New Data
Breakpoint. For the address, we would type in &m_Alive , which is the address
of m_Alive in memory. Then whenever that value changes in memory, the de-
bugger will break, which will help us find the bad code that's modifying it.
Source Control
Imagine you are working by yourself on a simple spaceship combat game that has
code spread out across ten files. There's a bug that if you pick up certain power-
ups in a particular order, the ship stops being able to fire its weapons. You spend
a couple hours debugging the problem (using a debugger, of course), and find the
root cause in the code. You fix the bug and are happy that you solved the problem.
You then move on to many other features and continue to change the files count-
less times.
A week later, suddenly, the bug appears again. You're perplexed. Was it that you
never fixed the bug in the first place, or that one of the numerous other changes
you've made since then broke the code again? Well, you have a problem remem-
bering what you changed to fix the bug in the first place, because you have ab-
solutely no history of when the files were changed and for what reason. Even if
you kept your computer on and IDE open for the entire week, it's unlikely you can
Search WWH ::




Custom Search