Advertisement

debugging graphic stuff

Started by June 03, 2002 01:15 AM
3 comments, last by anekin 22 years, 5 months ago
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!!!
------------------------------I prefer to be the worst of the best than the best of the worst------------------------------
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!"
Advertisement
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.


"C and C++ programmers seem to think that the shortest distance between two points is the great circle route on a spherical distortion of Euclidean space."Stephen Dewhurst
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)

Jacob Marner, M.Sc.Console Programmer, Deadline Games
Thank you..the information is very helpful
------------------------------I prefer to be the worst of the best than the best of the worst------------------------------

This topic is closed to new replies.

Advertisement