Jump to content
  • Advertisement
Sign in to follow this  
Hoover85

Debugging tips and tricks

This topic is 4467 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
BTW I always use disinfectant. just in case its real bug, you know, alive. always spray them first, then debug

Share this post


Link to post
Share on other sites
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.

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Quote:
Original post by Hoover85
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?


- 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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!