How can one debug games?
Author
I'm trying to debug my game and DirectX tutorial applications but I don't know how to do it. Up until now I've only managed to debug them only in the initialization phase (before entering the game loop). My problem is that once I reach a break-point in the game loop I can't go to the game by pressing f5 and I'm stuck in Visual Studio. Are there any debugging techniques for games (tips or anything)? All the game programming books I've read don't have a single chapter on this matter.
Quote:My problem is that once I reach a break-point in the game loop I can't go to the game by pressing f5 and I'm stuck in Visual Studio.
Does "stuck" mean the application will not resume when your press F5? Is the right-arrow "Continue" button in the Visual Studio IDE grayed out or missing, or the menu item Debug->Continue doesn't work?
It's not clear what you mean when you say you can't resume.
If you mean that the game goes fullscreen so you can't see what's going on, there's 3 solutions (From easiest to hardest):
1. Run your game in windowed mode and debug it from there
2. Use multi-monitor debugging (Requires 2 monitors)
3. Use remote debugging (Requires 2 PCs)
Personally, I go with 1 usually, and 2 if I'm debugging a fullscreen-only bug.
1. Run your game in windowed mode and debug it from there
2. Use multi-monitor debugging (Requires 2 monitors)
3. Use remote debugging (Requires 2 PCs)
Personally, I go with 1 usually, and 2 if I'm debugging a fullscreen-only bug.
Is the problem that the game keeps hitting your breakpoint every single cycle? If that's the case, a few ideas come to mind. One idea is to have some flag you can set with a keypress, and then have some code that looks for that flag and does something (anything). You then set your breakpoint on that code that doesn't do anything interesting. Something like this
if (debugFlagSet) {
// set your breakpoint here
println("hello world");
}
if (debugFlagSet) {
// set your breakpoint here
println("hello world");
}
evil steve's right if this is fullscreen...many times i have accidentally left breakpoints in the project when testing fullscreen mode, resulting in disaster; 100 yrs to get the task manager to open or having to reboot.
if this is a general debugging technique question, often visual studio isn't enough to tell us what's going on in the program. use text in the app to display debug values. if you don't have text, you can't debug so stop and write write some text support.
later, you can get into thought bubbles, debug windows etc, but start with a single line of text that you display with whatever debug values you want.
if this is a general debugging technique question, often visual studio isn't enough to tell us what's going on in the program. use text in the app to display debug values. if you don't have text, you can't debug so stop and write write some text support.
later, you can get into thought bubbles, debug windows etc, but start with a single line of text that you display with whatever debug values you want.
Author
Quote:Original post by snak
Is the problem that the game keeps hitting your breakpoint every single cycle?
Yes, that's what I meant. The problem that once I hit the breakpoint I can't go back to the game after I press f5 to resume. Sorry if I wasn't very clear!
Displaying some text on the screen with the debug values seems a pretty good idea. I saw that most of the commercial games have that console thing to appear on the screen when you press a button, maybe I could make something like that to help me debugging my applications.
Quote:Original post by fuzzballQuote:Original post by snak
Is the problem that the game keeps hitting your breakpoint every single cycle?
Yes, that's what I meant. Sorry if I wasn't very clear!
VS has conditional breakpoints (right click on the left bar where you normally set breakpoints). You might want to look up a tutorial on them. As a quick alternative I find myself doing stuff like the following:
for (int i = 0; i < int.Max_Value; ++i)
{
if (i >= 5000)
{
int foo = 5; // set breakpoint here
}
}
That would be if I thought my problem started at 5000. Normally you have some idea of where the problem is.
Well, there are two real cases. You either have a logic bug, or a crash.
For crash bugs, there aren't that many options. Usually you want to check out the point of the crash, and see what you can figure about the error. Setup some asserts to validate what you think the problem is, and try to backtrack using those asserts till you find out where your origional logic was wrong that caused the crash.
For logic bugs, there are lots of options.
* Setup a debug renderer. It is always useful to be able to draw line segments, vector directions, and matricies. Graphs are useful for seeing things change over time. Its always nice to be able to display timers, state machine states, and other text messages over the heads of your different game objects.
* Place a breakpoint after/during the funny occurance, and see if you can tell what values are amiss. At that point, you can place some if statements around, and use those as places for your further breakpoints. The objective is to slowly backtrack from "this state is bad" to the point where the state actually went bad.
* Set a hardware breakpoint on a variable you are interested in, and you can see exactly the points in your code where it gets changed. This is useful for finding memory stomps.
* Actively enable and disable code. Sometimes it helps to just make a "test level" where you can put one or two game objects, and play around. As it cuts down on the possibilities. And then, being able to just enable or disable specific game object code helps you narrow it down even more.
For crash bugs, there aren't that many options. Usually you want to check out the point of the crash, and see what you can figure about the error. Setup some asserts to validate what you think the problem is, and try to backtrack using those asserts till you find out where your origional logic was wrong that caused the crash.
For logic bugs, there are lots of options.
* Setup a debug renderer. It is always useful to be able to draw line segments, vector directions, and matricies. Graphs are useful for seeing things change over time. Its always nice to be able to display timers, state machine states, and other text messages over the heads of your different game objects.
* Place a breakpoint after/during the funny occurance, and see if you can tell what values are amiss. At that point, you can place some if statements around, and use those as places for your further breakpoints. The objective is to slowly backtrack from "this state is bad" to the point where the state actually went bad.
* Set a hardware breakpoint on a variable you are interested in, and you can see exactly the points in your code where it gets changed. This is useful for finding memory stomps.
* Actively enable and disable code. Sometimes it helps to just make a "test level" where you can put one or two game objects, and play around. As it cuts down on the possibilities. And then, being able to just enable or disable specific game object code helps you narrow it down even more.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
