Attention!!! Everybody knows this situation: You are programming on your latest state-of-the-art-game; everything is fine, but when you try to compile, Windows crashes. You can´t obtain any feedback or error message, from DirectX or your Debugger, cause you are using fullscreen mode ): I have heard of the following solutions: (1) -redirect the debugging-output via network to a second Computer (2) -using during the phase of development windowed mode and translate your project after completion to fullscreen (3) -wait until you get Windows2000(tm), which doesn´t use the WIN16-Lock, so that you can debug fullscreen without problems (4) -use the Multimonitor-Support of Windows98(tm) to use one monitor for your game-outputs and the second for the debugger ------------problems/ usefulness-------------------- (1) Who has two wired computers at home? I have heard that it is difficult to get this to work!? (2) This is the common approach. But you have to learn to share ressources with other applications (these parasites!). It´s not as easy and straightforward like programming in fullscreen. (3) Hmmm? When you live not in America, you´ll possibly have to wait a very long time (1/2 year?). It will cost much more than Win98 (ca. double the price?) (4) You´ll need 2 monitors and 2 graphics-adapter. Look at Andre "game programming guru" LaMothe´s article on this web-page: www.gamedev.net/reference/programming/directx/article590.asp It describes how to write an own debugger, which operates on the second monitor. My question: Is it possible to use the multi-montior-approach with the Visual C++ Debugger??? The Smiling One (:

I''d be interested in learning about topic #1 (remote debugging), but the NIC that I got in the "Instant EtherNet" kit didn''t install!!! >

You forgot the debug from log file approach.
I''ve found it''s the only workable solution because when *my* programs crash they take down the whole computer, making any process that runs on the same CPU unavailable (i.e. nixs options 1 and 4).

I use methods #2 and #4. Multimon is probably the most useful tool you can have for debugging full-screen apps.

I run two monitors - a main monitor hooked up to a V550, and a 2nd/debug monitor running on a POS Trident card. When I want to test full screen, I maximize DevStudio to the 2nd monitor.

It does not help with locking surfaces, and it has a few quirks (i.e., some apps/toolbars don''t like to live anywhere but the main monitor), but overall I''d say it''s definately worth the effort.

It''s not OK to assume that Windowed mode exactly equals full-screen mode... remember that in Windowed mode you''re blitting the new frame onto the window, but NOT taking what was on the window and making that your back buffer.

This means that some things that run in window mode might give you little phantom screen artifacts in full screen mode.

For example, if you use the common "grab bg/draw sprite/erase sprite by bltting previously saved bg" method of animation, in full screen mode, you have to keep track of the last *TWO* places the sprite was, because you have to erase it on both buffers. Three places if you''re using triple buffering, and so forth. With windowed mode you can get by with just remembering the last place.

I''ve found that remote debugging is slow, even over 100MB netlinks. There''s about a 1-2 second delay between when you push F7 and when the debugger updates the GUI, which I find irritating.

Remote debugging is great if the machine you''re having a problem on is 1/2way across the nation, but running two machines side by side just to debug full-screen IMO seems wasteful. I''d be interested in hearing others'' experiences, tho.

Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com

The work from debug approach is a good one and you are in
control of the debugging information that you get. I have one suggestion. I personally use a single debug log file but have different methods writing to it. I use a method to write debug stuff, one to write true error stuff and one to write specifically for directx errors and make sure all input to the file is labeled as such. I always include the class, method and directx method that caused the failure. It has been extremly useful as I just was able to debug a crash in my system yesterday in just a couple of minutes.

I use remote debugging (#1) along with my own log file information. Remote debugging is actually quite slick, of course, you gotta have 2 computers. :-(

--Shannon Schlomer, BLAZE Technologies, Inc.

Just to let everyone know, Win2k probably won''t be a viable gaming platform. PCmag and GameSpot recently did reviews testing game performance on the latest beta. Both had problems getting games running at all and when they did the games were sickingly sluggish.
__Still, it could be useful in debugging, as it is less prone to crashing, just be aware that the performance will be extremely skewed compared to Win9x.

It depends what you mean by "viable gaming platform." I''ve been using Win2k since beta 3 came out. OpenGL applications are extremely quick (using my TNT2). Quake III framerates are far above anything I was seeing under Win98 (128 Mb RAM in both cases). Quake II and (GL)Quake I both look awesome, too. With RC3''s inclusion of DirectX 7 (and - finally - decent driver support for the TNT2 in D3D on Win2000), I''ve found it to be very stable on new(ish) games. Unreal Tournament works beautifully. Alpha Centauri likewise. I had problems with Ultima IX (who didn''t?), but with the latest patch its noticeably less choppy under Win2k than it is under Win98. Also, Win2000''s networking layer seems to be better - lower ping times in multiplayer games (admittedly, with an ADSL connection I don''t really notice it). I''ve heard from people (I''m a computer consultant) having problems with it, and in most cases its been due to: unsupported hardware, requiring use of old drivers (its sometimes possible to reuse an NT4 driver, which won''t support most of DX7 except through the largely nonexistent HEL). Its also noticeable that Win2k - like NT4 - uses a machine more thoroughly, so overclocking failure is more common (for some reason, a lot of people seem to think that if a machine will boot the overclock worked; this is not the case. If it doesn''t overheat after being at 100% CPU usage for, say, 24 hours then its acceptibly clocked!). Also, if you have less than about 70 Mb of RAM, you won''t want to use it for high performance games..... because you won''t have very much physical RAM free without switching off services, etc., and thats just a pain.

As for development - Win2k is wonderful for writing games. Assuming that you want to use uptodate calls (ie. no execute buffers!), the entire API is supported. On top of this, you gain incredible stability (especially when compared with Win98). I''ve recovered from some really nasty crashed apps (due to bad programming on my part), and I rarely (if ever) have to reboot.

As for debugging... I debug over a network, use log files, AND use Win2k''s ability to debug fullscreen apps (although this can still fail, sometimes). There is never just one right answer!

I''m using Win2k RC2, and I''m just wondering how you debug fullscreen aps?
When my apps crash they just sit there and I have to CTRL-ALT-DEL switch to VC6 (the app is still in the FG so I can''t see anything) and then hit SHIFT-F5 to cancel debugging so that my app exits. How can you hide the app and get back to the debugger while it''s still running?

I''ve got a dual monitor config. on my NT box ( Matrox G400 DualHead ) and I''m doing remote debug to a Win98 computer about a foot away. I always considered it to be the most optimal situation ( never experienced any sluggishness ) because I could have MSDN on one monitor and be programming on another and debugging on a third, but the thought of using a log file is something that I consider to be a great idea no matter what kind of debugging your doing. However, since I do the majority of my debugging remotely then the OutputDebugString function pretty much covers everything I need. Except when my workstation crashes...then I''m screwed.