# Great debugging tips!

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

## Recommended Posts

Hey everyone, let me share a slight problem I've been having and how I fixed it. I think this may be useful for someone else. I'm working on a 2D DirectX application (Chess) which uses direct draw in fullscreen mode. I'm finally getting pretty good at working with linked lists, but I started running into some problems when I was attempting to delete a peice off the board. I finally solved the problem, but heres how I got there: Here's some of my debugging styles which I'm sure many are probably familiar with and use, and some which you may not use as much or not at all. 1. First and foremost, my best debugger is my whiteboard! I have a pretty nice white board I picked up from staples for \$20 and everytime I need to draw something out such as my linked list structures and the pointers, it really helps me out to get a visual on where my pointers are going in reality and where they should be going conceptually. 2. I really like the power of the VC++ debugger tool, however its nearly impossible to use when running a full screen directdraw application! I tried to code in a boolean "Fullscreen=true/false" variable which I could toggle which would initialize my program in windowed mode or fullscreen. However, its not working for me since DirectDraw crashes when I attempt to attach a surface:
lpddsprimary->GetAttachedSurface(&ddscaps,&lpddsback);
However, the intent for going into windowed mode would be to watch debugger information while plunking through the full screen application. I thought of a better solution: Since I have 2 computers right next to each other and they are networked, I can use one to run the game while I remotely debug on the other! Andre Lamothe wrote a really old article on how to get a monocrome monitor to interface as a debugger, which to me seemed kinda like a worthless article since I don't have dual monitor support. I read up on remote debugging from the microsoft website and got the following info which should get most people started: -The networked debugging machine needs to have these files in the same folder: -MSVCMON.EXE -DM.dll -MSDIS110.dll -TLN0T.dll -The networked debugging machine needs to have the exact same versions of: -Kernel32.dll -User32.dll -GDI32.dll (You need to install the correct microsoft patches to update these files. simply copying them over from one machine to another won't work since the files are constantly in use and thus locked) -The networked debugging machine needs to have a copy of your project files, including the .exe you build. I just copied my whole project directory over to a network share. -Next, in your VC++ IDE you setup remote debugging by: 1. Build > Remote Debugger Connection 2. Toggle to TCP/IP and enter the remote IP or network name -Finally, last step: Go to your networked debugger machine and start running MSVCMON.exe and configure the network settings and set it into the "Connecting..." state. -I created a batch file which copies the new .exe into the network share everytime I build my project to ensure my files are recent on both machines. Normally you'd have to do it manually. There you have it, remote debugging! much better then running in windowed mode and trying to debug on the same machine. 3. Creating functions which write information to a file. I created a function "Debug_Logfile(char* string,int flag)" which dumps the input received into a text file. Its good for tracking where my program logic path goes, and good for seeing the last values or place my program was before a crash. I also have overloaded that function with int and the POINT structure. 4. Outputting debug info to the screen in-game: Sometimes I want to keep track of general info which is only practical for being displayed in real-time, such as the mouse cursor coordinates, the framerate (good for detecting function lag), and other general stuff. There may be other methods for debugging games, but I've either never heard of them or used them. I listed these methods in order from most useful to least useful. Now, you should be able to figure out what the hell is going on in your computer. :) Oh and one final note: Do yourself a favor and comment the heck out of your code! It helps a ton with debugging when you're trying to decipher what the heck you were thinking earlier. At the beginning of all my functions I have this: int Largest_Number(int Num1, int Num2) { /* PURPOSE: find the largest number and return it INPUTS: Num1 - The first number to compare Num2 - The second number to compare OUTPUTS: Returns the largest number NOTES: this function assumes that the inputs are unsigned integers. */ code... return(LargestNum); } (If you're working on a team, it may be a good idea to include a timestamp and the last modifier to each function too)

##### Share on other sites
All good tips, especially the whiteboard one. Tracing things out on paper (or a whiteboard, blackboard, whatever) is an excellent and often overlooked way of solving problems and/or figuring out how to structure something.

I'd just like to comment that I use dual monitors, and although it didn't suit you this is also an excellent method of debugging fullscreen applications if you have support for it.