Debugging tips and tricks
Author
Are there any good tutorials or something of how to debug games with Visual Studio 2005?
I mean that, when I have programmed stuff with Winforms, it was really easy to just start debugging and trace the errorlines and then fix them. But with Direct3D in games - I haven't figured out a good way to debug other than just pop out error messaged with Try - Catch and show them in MessageBox.
If I add Breakpoints to game, like I would add in Winform-application the game just crashes when it hits the line I added breakpoint. And when I get out of the game the Visual Studios error message has also disappeared, so it won't really tell me what has happened. Should I just write somekind of logfile.txt to track down what happens if program crashes?
I have two monitors, so would it be possible to somehow make use of both of them? For now I have just used one monitor but would it be possible to somehow show the game in one monitor and then the line where I'm going in another while debugging?
And last but not least, how can I get memory information from my computer in games? I was thinking of drawing something like this, but haven't found where the information is located:
Memory usage: memUsage / memTotal (MB)
This would really help while working with heavier programs that has lots of graphics and audio files.
Btw. what is this "Start With Direct3D Debugging" -button in Visual Studio, I didn't see any difference with that when comparing to the "normal" debugging I used with Winform-applications.
BTW I always use disinfectant. just in case its real bug, you know, alive. always spray them first, then debug
Here is an article by superpig on debugging. I dont' think it was written with games particularly in mind, but the same concepts apply.
I'm not quite sure where you are having problems, since you can use break points wherever you want, just like you could in your other winform apps. It's just a matter of deciding where to place them.
However, we have a nice little section in the FAQ on D3D Debugging. It will teach you how to use the debug runtimes, which outputs additional info into the 'Output' window of your debugger.
Application-side debugging continues as normal. However, once you start, that menu has a lot more options (like view RT, view texture, ect). Also you can debug shaders.
I'm not quite sure where you are having problems, since you can use break points wherever you want, just like you could in your other winform apps. It's just a matter of deciding where to place them.
However, we have a nice little section in the FAQ on D3D Debugging. It will teach you how to use the debug runtimes, which outputs additional info into the 'Output' window of your debugger.
Quote:Btw. what is this "Start With Direct3D Debugging" -button in Visual Studio, I didn't see any difference with that when comparing to the "normal" debugging I used with Winform-applications.
Application-side debugging continues as normal. However, once you start, that menu has a lot more options (like view RT, view texture, ect). Also you can debug shaders.
Author
circlesoft, thanks for your reply. Will check those out.
Basicly the problem is with my device, since I am unable to reset it when I jump out of the program. So if I add a breakpoint into my Gameloop and run the program in fullscreenmode and when the program gets to the breakpoint the program just crashes when it jumps to Visual Studio.
Basicly the problem is with my device, since I am unable to reset it when I jump out of the program. So if I add a breakpoint into my Gameloop and run the program in fullscreenmode and when the program gets to the breakpoint the program just crashes when it jumps to Visual Studio.
Run in a window for debugging.
Occasionally you might be unlucky enough to run across a bug that only happens in fullscreen. Your best option then is to use remote debugging.
Occasionally you might be unlucky enough to run across a bug that only happens in fullscreen. Your best option then is to use remote debugging.
Quote:Original post by mattnewport
Run in a window for debugging.
Occasionally you might be unlucky enough to run across a bug that only happens in fullscreen. Your best option then is to use remote debugging.
Agreed. In my experience about the only things you ever really need to run in fullscreen for during development are:
- lost device handling (Alt-Tab, fast user switching, etc)
- anti-aliasing support development/testing
- multi-monitor support development/testing
- mode/refresh rate testing
Multiple monitor debugging is another alternative to remote debugging for fullscreen - the primary monitor goes into fullscreen, the secondary stays windowed (with the debugger running).
Author
Quote:Original post by S1CA
Multiple monitor debugging is another alternative to remote debugging for fullscreen - the primary monitor goes into fullscreen, the secondary stays windowed (with the debugger running).
Hmm.. this sounds like something I could try, since I have two monitors. Where can I configure the Visual Studio 2005 to use this feature? I couldn't find any configurations for this. Should I first attach the second monitor to my workstation and the Visual Studio then automatically tries to use this feature?
1) Support a windowed mode.
2) Use PIX for Windows.
3) Use a log file (or OutputDebugString()).
2) Use PIX for Windows.
3) Use a log file (or OutputDebugString()).
Quote:Original post by Hoover85Quote:Original post by S1CA
Multiple monitor debugging is another alternative to remote debugging for fullscreen - the primary monitor goes into fullscreen, the secondary stays windowed (with the debugger running).
Hmm.. this sounds like something I could try, since I have two monitors. Where can I configure the Visual Studio 2005 to use this feature? I couldn't find any configurations for this. Should I first attach the second monitor to my workstation and the Visual Studio then automatically tries to use this feature?
- connect 2nd monitor & set up so that you have one big desktop
- move the Visual Studio window to the second monitor
- start debugging - when you start your application in the debugger, only the first monitor will go full screen. The second monitor will stay in windowed mode showing the Visual Studio IDE/debugger.
I second hplus0603's recommendations, particularly using PIX, which is the main tool you should be using to debug the graphics output of your application.
Personally, I prefer using the _RPTn() macros in crtdbg.h instead of OutputDebugString() since 1)they dissolve away in Release build configurations [OutputDebugString() doesn't], and 2)they offer printf() style format strings so save the need to use sprintf() and have a temporary string buffer.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
