I was wondering what you guys consider the best method for debugging games? I used to use a monochrome monitor, but I made a stupid move when I bought my new computer and it didn''t have any &#%$ ISA slots.. (I''m still on the lookout for a PCI monochrome card, if anyone knows where to find one...) I bought another VGA card a while ago to use for multiple monitor debugging, but it wasn''t one of the ones on the list, and it didn''t work, so I took it back, but didn''t try again. Is MM debugging good, or is it too clunky to be very useful? What other suggestions do you have? ------------------------------ Jonathan Little invader@hushmail.com http://www.crosswinds.net/~uselessknowledge

Although this doesn''t affect your multi-monitor debate, a useful trick that I do is to create a function named "debugString" in every one of my important classes. It returns a character string which lists all of the member variables in the class. This way, I have a quick way to access class information and dump it to the debug window (and the class handles its own debugging and referencing) without having to trace through the functions.

Not a miracle or anything new, but merely a useful little tidbit. This also helps because you don''t generate messages unless this function is called (so your class isn''t slowed down by generating debug information or checking condition statements every time a member function is called -- only when the debugString function is called)

-Chris

---<<>>---
Chris Rouillard
Software Engineer
crouilla@hotmail.com

I saw this post on gamedev and well, I thought I would
email you about how you are writing your information to the
debug window, reason being is that I would like to write a
function that times another function and writes this
information to the debug window as well, but I could never
figure out how. I have emailing you personally and on
gamedev, just in case you dont check gamedev regularily
anymore and you might be willing to help me

thanks

Chris Thomas

oops, my last post, that was addressed to Chris and it referred to his writing to the debug window post above mine

so sorry

My major debugging function when I program fullscreen apps is to write a log file. That is really useful when people beta test it too.
(Almost) every function returns 1 if it it''s successfull or it return the error code along with writing a ErrorDescription + ErrorNumber + SourceFunction string to the log file.

============================
Daniel Netz, Sentinel Design

"I'm not stupid, I'm from Sweden" - Unknown

For super-quick "did it get this far?" debugging, I throw a PlaySound into a function. Log files are much nicer in the long run, but if all I care about is whether or not a function was actually called, PlaySound is a very quick and dirty way to do so.

-fel

If you have the money, I recommend getting a second system for remote debugging over a network. The test computer doesn''t even have to be any good, I currently remote debug on a Pentium 166. It helps make you write faster code because if it isn''t fast enough you get all pissed at the computer and yourself for writing code that''s soooo slow. Also, using log files is great too.

Heheh yeah that''d work Fel...although I find myself often working in areas where quiet has to be kept, and I absolutely love, adore, and have memorized a nifty little function in the Win32 API called MessageBox() A little "you have made it to SuchAndSuch() ...good for you!" can always brighten up my day during a stressful debugging session.

As for the MM support, I''ve never done it, but I have seen someone who did, and it looked great! I''m sure that once it is set up, it is well worth it...

Yeah, I use PlaySound all the time too. But wouldn''t this conflict with DirectSound? The main reason I want to use the MM debug is because with an output window on another monitor, you can always see where you are, and it helps to detect more "long term" bugs. That is, if you always have output going, you are more likely to find a problem where you didn''t expect one.

------------------------------
Jonathan Little
invader@hushmail.com
http://www.crosswinds.net/~uselessknowledge

I use multimon debugging and think it is great. DirectX has some pretty good support for it and I would recommend it highly. I have a TNT2 Ultra running at 1600x1200 as my primary video card and a Matrox Millenium II running at 1280x1024 as my secondary card.

It is also great for coding as well. I run the VC editor on my primary monitor fullscreen and place my VC output window and project window on the secondary monitor. I also run a copy of the MSDN on the secondary monitor as well. I have lots of screen realestate for editing multiple files while still having the other windows close at hand.

I also build my projects so that they support multiple monitors. (You can do this in DirectX 6.0 +) They can be forced to run on a specific card from the command line so that I can test two different video cards on one machine.

It is even better when running Win2k because it is possible to debug fullscreen through a DirectX surface lock without hosing the system.

If you are looking for a multimon solution and happen to need a better primary video card, you can buy a Matrox G400 dual head card. This card supports multiple monitors on a single AGP card. If you don''t want to go this route then what you need to look for is a video card that can disable it''s VGA support (not normaly a feature you see on the side of the box ). Most modern cards can do this but some older PCI cards can not.

I have had personaly had success with a 2MB Trident based card, a 4MB S3 based card, an Intergraph Intense 3D, Matrox Millenium, and a Matrox Millenium II.

You also need to be running Windows 98 or Windows 2000.