Debugging DirectX

Hey everyone,

I'm trying to port my game to DirectX right now, and I'm having quite the time. My biggest problem is debugging, since I can't pop up messageboxes like I could when I was using GDI (or so I think), so I can't really tell if my functions are returning error codes - in other words, my code doesn't work and I don't know what functions are fouling up. Another frustrating thing is that it won't run in the debugger, so I can't run through the code step by step, and see where it crashes. So my question is:

Is there any easy way to figure out what variables hold what values at any given point in a program? Or, for that matter, is there any way of alerting myself if an error occurs?


P.S. Not too related, but does anybody know of any DirectDraw function that will crash a prog if a surface is invalid or something? That's my latest pet peeve - finding it out.

// setError declared here for convienence
void SetError( char* String )
{
OutputDebugString( String );
OutputDebugString("\n");

char *filename = "error_log.txt";
char *text = String;
log_textfile( filename, text, true );
}

void log_textfile( char filename[], char string[], bool overWrite )
{
ofstream a_file;

if( overWrite )
a_file.open( filename );
else
a_file.open( filename, ios::app );

a_file.setmode( filebuf::text );
a_file << string;
a_file << "\n";
a_file.close();
}

Hmm, that seems like a good idea. I'll try it out :) But how do I see what gets sent to the debugger? Is that what you see when you get an illegal operation or something?

Im no expert on the debugger of VC++ 6.0 I skimmed (read skipped) that chapter. but generaly you select the debug tab in the area where you get compile messages.

Ok, thanks. I'll try it out.

Hi!

Quote:

---

I can't pop up messageboxes like I could when I was using GDI (or so I think), so I can't really tell if my functions are returning error codes

---

Why can't you use MessageBoxes? Just run your app in windowed mode - anyhow, you can't use fullscreen mode if you want to debug your code.

You probably know much about breakpoints, sometimes conditional breakpoints are even more useful (just use them carefully, and only if you really need to, as it's not too easy to set them up).

When your program is attached to the debugger, you can specify break conditions as well: the program will break e.g. if you get an exception, etc.

It's also a good idea to keep the "Call stack" window open - you see the function call hierarchy, which is very helpful when searching for bugs.

If you need some more detailed help, just let me know.

May the "return" be with you! :D

I've forgotten something important: nearly every DirectX function returns a HRESULT value.
When you call this function, you should check whether it succeeded or not:
---------------------------
HRESULT aHResult;
aHResult = pDDrawSurface->GetDDrawSurface();
if ( aHResult != S_OK )
{
MessageBox( hWnd, TEXT("ERROR: Cannot get DD Surface!"),TEXT("My example"), MB_ICONERROR | MB_OK );
}
...
return aHResult;
---------------------------
Implement this functionality in your own classes as well. Declare your functions to return a bool or HRESULT value, and check them upon return:
---------------------------
HRESULT doSomething();

HRESULT myClass::doSomething()
{
HRESULT aHResult = S_OK;
...
overwrite default value (success) with error value -if any
...
return aHResult;
}

in the caller function, check for error(!), pop up a message box and/or output trace lines to file - as shown by dbgt goten.

Important: check for NULL pointers, as they can do very nasty things like access violations & Co. :)
---------------------------
if( !myDxDisplayPtr ) // myDxDisplayPtr == NULL !!!!!!!
{
outputTrace( "myFunction -> myDxDisplayPtr is NULL!" )
return UNINIT_POINTER; // some predefined error code is returned, and the program is terminated
}
---------------------------
Implementing error checking in your functions is a good habit, and once you get used to it, you'll never avoid it!

Have fun!

I guess that's my problem then, not running it in Windowed mode :) I'm setting it up with these flags: fullscreen, exclusive, allowreboot.

On second thought, will I be able to have a system menu and stuff like that if I run it in windowed mode? (I don't think I can in fullscreen) Or is there something else I have to do?

A good practice is to run your app in windowed mode if you're going to debug it. Afterwards, you still can switch to fullscreen, this initialization doesn't cause big problems, at least, it can be easily tracked/caught. On the other hand, DirectX apps usually let the user to decide - right upon startup - whether it should be run in fullscreen or not.

[Q]will I be able to have a system menu and stuff like that if I run it in windowed mode? [/Q]

Of course, if you're setting up your app to run in windowed mode, you'll have a system menu. There's no system menu in fullscreen mode (and that's all right so).

However, I don't get it why do you need a system menu for debugging :).

Hmm, well, I need a system menu because the GDI version of the game has one. And also, it uses a messagebox for high scores, and other stuff like that :) The only reason I'm using fullscreen is because it was used in the book and because it looks cooler.