Howdy all. I''m new to the whole game/windows programming thing and bought myself Lamothe''s book as a starting point (let''s not comment on the book, I''m just adding that so you know where I''m coming from). I''m programming in VC++ 6.0 and going through the examples, and have been tweaking and changing alot of the code. Now my question is, as a guy who''s never done any kind of graphical programming, are their any good tricks or techniques for debugging games? Currently what I''m doing is just using a log file and printing out the variable values I want to look at. Is there a better/faster way? I suppose I could draw text on the screen while the game is running, but there''s only so much room and if the problem I''m trying to diagnose happens very quickly (as in a switch to a wrong state), I might miss it. Any suggestions? Thanks "I''ve never seen that. I''ve never seen anybody drive their garbage down to the side of the street and bang the hell out of it with a stick. I''ve never seen that."

A few tricks you can choose among:

* Write your app so it can run in both windowed and fullscreen mode. When you need play around just it in windowed mode - that way it can be easily debugged.
* Buy an extra monitor and video card and use one for the debugger and one for the full screen app. (Does not well with OpenGL though but fine with DirectX)
* Supplement you log file with data sent to the debug console. Free apps such as debugview from sysinternals does this for you. Install the debug version of the DirectX SDK to get better output here.
* Use remote debugging over a network.

I personally prefer the first since the debugging itself is most plainless this way and the app can be easily closed since it will not get exclusive access and then suddenly crash.

[edited by - felonius on June 7, 2002 3:46:31 PM]

I''m useless at debugging my own programs, but many sources I''ve come across have mentioned using "assert" to check if variables are the value they should be (in conjunction with the ideas proposed by felonius).
Sorry I can''t be more help, but I hope this might point you in the right direction.

-pan narrans
-Always right! Except when I''m wrong.

Read this thread for DX debugging tips. The debug runtime should always be running when you''re coding.

To diagnose memory leaks and corruption, use MSVC''s debug heap. Look up _CrtDumpMemoryLeaks and follow the links. In short, include this in your program:

#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>

To help yourself find logic errors, use assertions. You can use <assert>''s assert macro, MFC''s ASSERT macro, <crtdbg.h>''s _ASSERT and _ASSERTE macros, or ATL''s ATLASSERT. Insert them everywhere, literally. If you make an assumption, verify it with an assertion. Since these checks are debug mode-only, they will not speed/size of your final program.

For efficient debugging, learn to use your debugger. It''s really not that hard. Press F10 to step over, F11 to step into, and Shift-F11 to step out of functions, Ctrl-F10 to run program to current line. Use the debug windows (watch, variables, debug output).

Thanks for the replies all.

Nehkmet: That sounds like a nifty way of handling when to sound output.

Indirectx: I do use the debug window, but so far when I''m trying to do it in conjunction with these graphics programs, I haven''t had much success. It might help having two monitors I suppose. I''ll look into using assertions.

felonius: I''ve got the debug version of the sdk, and it sounds like having a second monitor would help me out, but that brings up a couple more questions: Does that add alot of extra work when drawing graphics if I have to do checks like "only run app on monitor one" or is that more of a settings kind of problem? The second question is, where the hell am I going to put that other monitor? My desk is overcrowded as it is

"I''ve never seen that. I''ve never seen anybody drive their garbage down to the side of the street and bang the hell out of it with a stick. I''ve never seen that."