PDA

View Full Version : Glut isn't working



strates
06-08-2000, 04:50 PM
Ok, I just converted a project of mine over to glut, and now it seems that it isn't reading my initFunc(). anybody have any reason for this? I could send the code if that would help.

thank you
strates

06-13-2000, 08:04 AM
Please send code

strates
06-13-2000, 05:09 PM
Originally posted by Big T:
Please send code

whats your email?

john
06-13-2000, 07:28 PM
argh?! can't people debug these days?

i don't know if you have some cool magical glut that has its init as a call back... i'm guessing not, because it needs to be initliased somewhere along the line. Can't you add trace writes to find out what your program is doign? even better.. can't you use GDB or equivilent to step through your executable?

argh!
John

strates
06-14-2000, 04:36 AM
Nope, I have absolutly no clue as how to go about successfully debugging a program, I usually just stare at the code until I think of something that might be wrong with it. I guess I should probably learn. Any good resources on how to debug with VS6.0?

strates

Random_Task
06-15-2000, 04:51 PM
strates,
Actually, there are some GREAT tools for debugging in Visual Studio 6. Your most powerful tool is the Visual Studio Debugger. What you do is set a "breakpoint" somewhere near the beginning of your code. The next thing to do is go to the build menu as select "start debugger" Now you have two main tools once the debugger loads. One of them is "next" which is F10 and the other is "step into" which is F11. You can methodically test your code by first stepping by each function call, and then if you notice poor behavior you can step into the suspect function. It also provides you with a variable screen which will show you the states of current variables as well as a watch screen which will allow you to tell it what to monitor. I really can't go into to great of detail right now because it is a big program.

Another tool that you can use is something called the "TRACE" macro. Look up how to use it by pressing F1 and typing in TRACE in the search section. What this will do is output a message of your choosing into the compile window at the bottom of the screen. This way you can monitor what functions are being called and in what order.

Maybe your init function is never being called at all! The debugger will help you find it. The first thing I would do is put a TRACE("Got Inside the Init function"); message inside of the init function to see if it is being called. Then you can go from there.

What I do is create a common return type (usually a class) which all functions return. This type can hold different states depending upon the error. Now, when I need to return an object from a function I use an [in out] or [out] parameter (&refObject) or (**handleObject.) Then before I exit every function I return an instance of my error type set to some error value, success or failure types. This helps me trace problems in my code. I have it set up so that if a negative error type is returned it will call the TRACE macro to output where the error occured.

One final thing that I do now is in every function at the beginning, before any other code is executed I put in this small sequence:

#ifdef DEBUG
cout << "classTest::myFunction::Enter" << endl;
#endif

And then at the end of every function, right before the return I put:

#ifdef DEBUG
cout << "classTest::myFunction::Exit" << endl;
#endif

At the top of my program, if I have bugs that I cant seem to find I just define DEBUG like so:

#define DEBUG

When the compiler compiles it will compile in the messages only if DEBUG is defined. This way I don't loose any performance if I want to compile a release version.

I hope these ideas helped.

Randmom_Task

[This message has been edited by Random_Task (edited 06-15-2000).]