Archived

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

debugging graphic stuff

This topic is 5669 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

Hi..I want to know what is the best way to debug the graphic part of a game. I''m learning the basics about graphics development but I want to have a better understanding about what to do or use when I''m debugging this stuff.. Thank you in advance!!!

Share this post


Link to post
Share on other sites
Well, if you''re doing full-screen stuff then you really want to have a logging system. This is simply two or three functions that write details to a file for later inspection. For example, you might have a ClearLog function to open and erase the log file and a WriteLog function that opens a file, appends a string to the file and then closes it.

Another handy thing is a debug mode that creates a windowed display instead of a full-screen display. It''s always a bonus when you can see what the error messages are .

Other than that... whatever floats your boat. If you give some more details about what you want to achieve then we can suggest further ways to make life easier. Most debugging is related to judgement - "that pixel should be green, not red!", "that texture is upside down," "that normal must be the wrong direction because it''s dark instead of light," or "dammit! My computer has locked up and is on fire!"

Share this post


Link to post
Share on other sites
Easiest - Ensure you can start your game in a windowed mode and use IDE of choice to walk through code.

Also Easiest - Dump ALOT of info out to a file so you can analyze the data ( verts, collisions, etc.. ) slowly - use data sets to ensure boundary conditions work, etc..

Harder - Use two video cards / monitors, one has the scene the other your windows stuff (only did this for driver stuff - never tested a DX app - asside from input capture it would seem to work).

Harder - Build custom profiling, tweaking, monitoring tools and expose functionality in the in-game console. Unit test the individual pieces so you know they work and then test higher level functionality in your in-game console.

Even Harder - Set up a remote console that allows you to do the above and just ''telnet'' into your game and go from there.


There may be a few other techniques but I think this covers most of them.


Share this post


Link to post
Share on other sites
Just a few additions/comments:

>> Even Harder - Set up a remote console that allows you to do the above and just ''telnet'' into your game and go from there.

You don''t usually telnet in. YOu use the remote debugger supplied with your compiler.

>> Harder - Use two video cards / monitors, one has the scene the other your windows stuff (only did this for driver stuff - never tested a DX app - asside from input capture it would seem to work).

It should be noted that this scheme does not work well if you are debugging an OpenGL application since the Windows OpenGL system doesn''t work well with multiple monitors (unless, I think, you have two identical videocards)

Share this post


Link to post
Share on other sites