General Debugging Practice

I write windowed and exclusive mode support, then do most debugging in windows.

Another option would be to open 2 windows and use one for your debug messages. You could then ALT-TAB between your game and the ''debug'' window. I also use the GDI portion of DirectX during debugging, as you can just use the TextOut() function to print right to your drawing surface.

---
Make it work.
Make it right.
Make it fast.

If you are using VC++ and have two computers, you can use one computer to debug the other computer remotely over a network or serial connection. IMO this is the cleanest way of debugging fullscreen apps; your program can run full-screen and breaking doesn''t cause mode/focus changes.

xyzzy

Running everything in a window is by far the most common thing we do. Most of the time there''s no reason to be in full screen apart from when you''re testing things like screen mode changing, Alt-Tab support etc.

Multiple monitors is another good way - get a cheap PCI graphics card and a cheap second monitor - set up Multi Monitor support in Windows (go to the Display settings - it should auto detect that you have a second card and let you configure the second monitor there). Drag the MSVC window onto the cheap monitor. Now run your application in fullscreen - your main monitor will be the primary monitor.
As long as you''re not using exclusive mode DirectInput to take over things like the mouse, then MSVC will still be usable on the cheap monitor - you can single step etc without any trouble.

Using SoftICE would be like using a sledgehammer to crack a nut - totally unnecessary - should only be used when you''re trying to debug things like blue screens popping up in your app.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Very helpful guys, thanks mucho! Was having a buggy, fustrating morning. I can''t seem to run my game in windowed mode, it dies when i try to lock the surface. But, this is another issue all together. I think i''ll probably give a shot at the multipule monitor approach. Thanks again,
~Alan

If the debugger locks up after you hit the Lock call, then:

1. Never "step into" the Lock() call - theres lots of nasty kernel mode stuff in there which will crash your user mode debugger (e.g. MSVC). Always "step over"

2. Use the NOSYSLOCK flag on all Lock calls you wish to debug. This prevents DX from shutting down Windows and going into 16bit mode for the duration of the Lock.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com