Jump to content
  • Advertisement

Archived

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

Mephs

DirectX debug mode, is it really worth using?

This topic is 5734 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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
I was under the impression that the debug mode runs slower. How much slower is it? AND, will it affect just my programs or games I run on my box?

Thanks,

Paladin

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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!