Archived

This topic is now archived and is closed to further replies.

Mephs

DirectX debug mode, is it really worth using?

Recommended Posts

Heyas, just a quick question. When I installed my DirectX SDK, I decided to go for the non debug version (dont ask why, I don't remember =p) Now I keep seeing people say that they recommend the debug version cos it's easier to find faults, but is it really necessary? I mean I'm no DX expert but nothing I have done so far has been impossible to debug just using standard debug features, I've had absolutely zero problems with anything DX related, any problems have been 100% due to incorrectly setting up data structures or small syntax errors (eg the occasional missed semi colon). Is the debug mode really only relavant if your hardware plays up with certain features, or is it useful for other things? Now I'd say I've used quite a wide variety of commands and had no fault with sound, input, graphics, networking or anything at all, is there still any good reason to reinstall the debug version instead? I probably will at some point anyways, but I'd rather do it for a purpose than just for the heck of it =) [edited by - mephs on June 14, 2002 11:17:15 PM]

Share this post


Link to post
Share on other sites
You''ll appreciate the debug mode when you spend half of your day trying to figure out why all you get from your 5000-line program is a blank screen, post about it here, someone will tell you to use the debug runtime and once you do, it will take you ten seconds to read the error message and fix your bug.

Share this post


Link to post
Share on other sites
Hmm, not so sure about that one. I tend to thoroughly test my program every time I write a new routine into it, and usually severaly times through its implementation. Therefore it''s not all that difficult to pinpoint errors without debug mode, generally if I have an error, I''m only searching in around 100 lines of code at most. I could imagine it becoming a problem if the problem was created due to some kind of incompatiblity between the new section of code and older sections, but to be honest I don''t see this ever being a problem so long as it''s programmed methodically. Perhaps once my engine expands this could become more of a problem, but on the other hand, I dont think it will.

Share this post


Link to post
Share on other sites
I wish I was as lucky as you. I spend much more time in the debugger, so any and all debugging aids are welcome. The debug runtime is usually of greatest use when you''re adding a new feature that can''t be tested in pieces, and you have a load of new code all over the place. Sometimes the debug runtime doesn''t catch your bugs, but still I think it''s quite silly to throw away free programming help.

Share this post


Link to post
Share on other sites
Most programmers make mistakes, I don''t think I''ve ever met one who could honestly say he didn''t. Add the fact that the SDk docs are occasionally a little vague, and I find it hard to believe anyone could spend a significant amount of time developing with DirectX and not screw up occasionally.

But here''s more reason to try the Debug. It will warn you when you do naughty things that might work in retail on YOUR card, but crash on someone elses. It will warn you when you do things that are bad for performance.

Using a debugger is not required, but I use it because it helps me find mistakes faster, the Debug runtime does the same. Maybe you can limit your errors to a hunder lines of code or so, ubt sometimes the Debug Runtime will tell you exactly what you''re doing wrong.

Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites
Oh by all means I''m not saying I don''t make errors, just when I do Im pretty good at tracking them down fast, tho there are probably many faster than myself also.

Share this post


Link to post
Share on other sites
I didn''t know I had the debug runtime version installed. And then, last night I was debugging a small D3D app which I made to try out some of the lights settings. But the crappy app kept crashing....and I debugged and debugged and debugged...but alas I couldn''t find the little bugger

BUT THEN I noticed this debug runtime when the app crashed. And with ONE, YES ONE, click of the mouse I was pinpointed to error. God damn brilliant I''ll say.

A year spent in artificial intelligence is enough to make one believe in God.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
i have also installed the debug version but don''t know how to use it correct. i know just the vc debugger with F5, how can i use or where can i get the "debug runtime magic one click"?

Share this post


Link to post
Share on other sites
IMO the debug runtime is essential, always has been, its a tool you should always use. IMO you''d be MAD to be seriously developing any DX program without the debug runtimes.

With the RELEASE DX runtimes, many programming errors, such as passing invalid pointers etc *ARE NOT CHECKED FOR* (for performance reasons), and so most DX calls will only return errors for things which aren''t necessarily programming faults.

This means that instead of getting an error code (D3DERR_BLAH), you''re much more likely to get an access violation (etc) inside a DirectX DLL - not much fun to try and track, particularly if the problem was caused by an earlier DX call. And even when you DO get an error code, it won''t tell you much about *WHY* the error occurred.


With the debug runtimes, amongst other things you get:

1. Error, parameter and data checking for ALL DirectX calls, means that any problems show up immediately in the place where they occur rather than later.

2. Default values for empty buffers - for example debug DSound fills sound buffers with static/white noise so that you can tell whether your code is playing a buffer before filling it with data.

3. Resource leak tracking and "break on leak" functionality - if you forget to release a DirectX resource (e.g. a surface, a sound buffer, a vertex buffer etc), it can slowly degrade the performance of your machine. And any normal memory leak checking WILL NOT detect the leak since DirectX uses its own heaps.

4. Proper "English" descriptions of *WHY* a DirectX call failed sent to your debug output window, much more information than just what the error code, instead exact details of why D3D decided that error code was appropriate. You can also tailor the level of messages for each component to suit your needs.

5. Warnings, hints and information - again sent to the debug stream - e.g. set a render state which is already set and the debug runtime will tell you about it.



AP:

Go to the control panel (Settings from the Start Menu) and double click on the DirectX icon. If you don''t have a DirectX icon or the selections in the dialogue which appears are greyed out, then you don''t have the debug version of the DirectX SDK installed.

If you don''t have it, uninstall the SDK, and reinstall, chosing "Debug Runtime" when the installer asks you.

In the control panel (if you do have it), for many components, you''ll see a slider labeled "Debug Output Level", turn it up, try full on.

Next time you come to run your own DirectX code, run it in the debugger with F5. When the program finishes or crashes, look in the Debug Output window of MSVC. You''ll see messages from DirectX components in there, like "Direct3D : (ERROR) : blah failed because blah".


If you don''t have MSVC or want to see if pre-compiled programs, then you can use a debug viewer like DbgView from www.sysinternals.com

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

Share this post


Link to post
Share on other sites
Paladin:

Yes it will run slower since it validates all parameters etc. Its not that much slower though - an app running at 60Hz will probably still run at 60Hz...

However, the main place you''ll see slowdown is in D3D components (though Max Payne seemed ok on my 1.3Tbird at home in debug!).

For that reason, when you install the Debug runtime, if you look at the control panel applet, under the D3D debug settings, you''ll see a radio button to choose between Retail and Debug D3D... so it needn''t cause any (noticable) performance drop in games.

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

Share this post


Link to post
Share on other sites
It''s better to install the debug runtimes in any case, because the retail ones are installed with it, and you can switch to retail at any time. If you install the retail runtimes, I don''t believe you can switch to debug.

Share this post


Link to post
Share on other sites
Okay I bit the bullet and reinstalled DirectX SDK in debug mode..... but umm... I have no debug controls in my control panel. I thought it appeared there? Not to mention the problems I had installing the SDK from the programming RPG''s with DirectX book, it never installed 95% of the files. So I used the directX 8 SDK from another disk I have which did install correctly and I find that there is no control anywhere over the levl of debugging. Anyone have any idea why this might happen? Before anyone asks, yes I did uninstall the previous SDK installation first!

Share this post


Link to post
Share on other sites
You need to install the newest DXSDK. If you have DX 8.1 and you install DXSDK 8.0, then DXSDK won''t overwrite the 8.1 runtime. You probably can just install 8.1 ''developer runtime'' (see componentized download on MS site, if they have it), but I would recomment that you install the whole 8.1 SDK at least because of the improved D3DX.

Share this post


Link to post
Share on other sites
I thought I might as well resurrect this useful thread rather than start a new one, in this age of no search facility.

quote:
Original post by S1CA
2. Default values for empty buffers - for example debug DSound fills sound buffers with static/white noise so that you can tell whether your code is playing a buffer before filling it with data.

Yeah... I get this on some commercial games when I have the debug versions installed

quote:
4. Proper "English" descriptions of *WHY* a DirectX call failed sent to your debug output window, much more information than just what the error code, instead exact details of why D3D decided that error code was appropriate. You can also tailor the level of messages for each component to suit your needs.

But I always had problems running fullscreen DirectX apps under the debugger... if it crashes then generally I''m back in the debugger with a fullscreen DX app blocking the view. I usually have to Ctrl-Alt-Del out of this, which sometimes gets me out of MSVC, but just as often reboots the computer. Which is why I usually use Execute rather than Debug. How come no-one else gets these issues?

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Share this post


Link to post
Share on other sites
quote:
Original post by S1CA
2. Default values for empty buffers - for example debug DSound fills sound buffers with static/white noise so that you can tell whether your code is playing a buffer before filling it with data.

quote:
Original post by Kylotan
Yeah... I get this on some commercial games when I have the debug versions installed


Is that what that *pfsshhhh* sound is when you start up a game that uses a DirectSound library? It happened on UT1 all the time, and then it started happening on my game, and I just said to myself "Oh well, if it happens to Unreal Tournament, it must be unavoidable!" Now I know...at least none of my non-devver players had this issue

Peace,
ZE.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

Share this post


Link to post
Share on other sites
quote:
Original post by Kylotan
But I always had problems running fullscreen DirectX apps under the debugger... if it crashes then generally I''m back in the debugger with a fullscreen DX app blocking the view. I usually have to Ctrl-Alt-Del out of this, which sometimes gets me out of MSVC, but just as often reboots the computer. Which is why I usually use Execute rather than Debug. How come no-one else gets these issues?



I always debug in windowed mode. The differences between windowed and fullscreen mode are generally pretty minor. Another alternative is multi-monitor debugging. A lot of cards have dual outs now, and you don''t need a great monitor for the debugger.

Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites