Game Development Reference
In-Depth Information
One solution to this problem is to have an in-between build that has some of the
debug functionality enabled, but also some of the optimizations. Another option
is to run in Release, but turn off optimization for the particular file you are trying
to debug. In Visual Studio, you can right-click the file in question in the Solution
Explorer and turn off optimizations specifically for that file. But don't forget to
change the settings back once you're done debugging!
Call Stack
The
call stack window
shows you which functions called the function that the de-
bugger is currently in. This is especially helpful in the case of an unhandled ex-
ception or an outright crash. When you get a crash in Visual Studio, you will see
a dialog box with a Break button. If you click the Break button, the debugger will
pause right at the point of the crash. This allows you to inspect the values of vari-
ables as well as see what was on the call stack when the crash happened. The latter
is especially important when you can't figure out why a particular function was
called at a particular point.
What you definitely
should not
do when you encounter a crash is put print state-
ments everywhere to try to pinpoint where the crash happen. This is an absolutely
terrible (and often unreliable) way to find the source of a crash. You have a debug-
ger designed to help with this problem, so you should most definitely use it.
Breakpoint Conditions
An issue with putting a breakpoint in a function that gets called single every frame
is that the game will pause at that line over and over again. But suppose you only
wanttopauseatthebreakpointwhenaparticularconditionistrue,likeforinstance
when a particular member variable is zero. This is where conditional breakpoints
come into play. To add a condition to a breakpoint, right-click the red breakpoint
circle and select Condition. You then will get a dialog box in which you can type
the particular condition, as shown in
Figure B.3
.
