CDisplay Display;
CRenderer Renderer;
Display.Set()
Renderer.Draw()
CDisplay::Set()
CRenderer::Draw()
Graphics Debugging & Console Output
Author
I''m making a 2D game, focusing on the engine right now. I have separate classes (& files) for debugging, the display, the renderer, settings, and the console. I seem to have worked out a debugging solution for now, but I was wondering if anyone has experienced any problems with their graphics systems needing debugging support but their debugging systems needing graphics support (like a console). If so, how are you handling it? I am using one instance of most of my classes. Would it be better to use static member variables, something like this?
Instead of:
What I do is immediatly when the program starts I check the command line for a debug command and if its there I create a standard windows dialog box from a resource which has an input and output pane. I also open a text log file and timestamp it. For the duration of the program, any calls which print text (I actually only use one call - Sys_Printf - which redirect the message from there to where it needs to go) also has the text sent to the log file and the low level console.
Usually if the engine crashes and kills the console window before you can read the message the log file still catches there error. In the ver rare event that something fails below the level of the console or log file then it gets sent to the screen by a MessageBox call. So far I haven''t missed any error messages.
Usually if the engine crashes and kills the console window before you can read the message the log file still catches there error. In the ver rare event that something fails below the level of the console or log file then it gets sent to the screen by a MessageBox call. So far I haven''t missed any error messages.
In my case, all my DirectX libraries are split out to seperate Classes and are united to by a scenerender class. Within each of the Direct Classes (sound, 3d, 2d etc) I have a static class for error handling for which all logging goes too.
I would suggest that you abstract your error handling into 2 groups, hardware surrounding Direct X calls. And another log which you could implement in the console. I would only suggest that you log everything to a file during debugging. This is so that you get some idea of what happened if you app goes belly up.
To answer your calls on static members, I have only one in my program, thats the error loggingm, for good reason, so I dont get more than one call in multithreaded code and it causes error logging to die.
I do create instances of my classes for rendering etc (even though you only ever have one), as a good rule of thumb for programming.
Andrew
I would suggest that you abstract your error handling into 2 groups, hardware surrounding Direct X calls. And another log which you could implement in the console. I would only suggest that you log everything to a file during debugging. This is so that you get some idea of what happened if you app goes belly up.
To answer your calls on static members, I have only one in my program, thats the error loggingm, for good reason, so I dont get more than one call in multithreaded code and it causes error logging to die.
I do create instances of my classes for rendering etc (even though you only ever have one), as a good rule of thumb for programming.
Andrew
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
