Hello,
I have debugged my program for over 2 months now. It works fine in debug mode. In release mode, I can load one object. When I try to draw another object, it does not show up. I stepped the program as an attached process. The program reaches the proper rendering calls. Nothing shows up on the screen. I store the coordinates class in a vector. Would that cause a problem? Just wondering if anyone has seen this before. Otherwise I’ll keep checking for buffer overflow.
Thanks,
John
I suggest you do a XML/text frame dump of OpenGL calls using http://glintercept.nutty.org/.
Do one in Debug when it works, then do one in release and compare the logs. (WinDiff is good for this)
Originally posted by johnnalley:
I store the coordinates class in a vector.
By vector did you mean std::vector? If you do, you need to be carefull about any pointers into the vector. When new element is added into std::vector, content of the vector might be reallocated into different memory which means that the pointers into it might become invalid and also the copy constructors and destructors might be called on the objects stored within it.
What I would do, and this is just for simplicity’s sake, I would open a file, and write certain things to that file when certain things happen, say you’re allocating an object, print the pointer value into the file. Then whenever you render an object, log the action with that pointer value. You’ll see whether these things are drawing or not from your application’s perspective.
This debugging technique works in any situation where the debug mode program works, but release mode program does not work so well. Also, I suggest you carefully look over all areas in your code that’s different between debug and release modes.
You could also invest in a bounds checking app, like boundschecker or rational purify. They save a lot of time in certain circumstances.
I replaced the std::vector with my own version. Nothing new. So it wasn’t the vector.
I dumped the translation coordinates as I was calling the rendering function. They looked fine.
I added more asserts. Nothing turned up.
I used gDEBugger to check for errors. Nothing.
I’ll try some of your other suggestions.
I glintercept program worked well. I found some uninitialized variables being used for matrix multiplication and rotations.
In the future you can use the gDEBugger State Variables Comparison Viewer for this task:
This viewer allows you to inspect the OpenGL state variables values. You can compare the selected context state variables values to the OpenGL default values, compare two state variables snapshot files, compare the selected context state variables values to a snapshot file or compare the selected context state variables values to the values recorded at the previous debugged process suspension.
I suspect that your error has nothing to do with OpenGL itself, but with the compiler/optimizer/your code. If something runs in debug mode, it should also run in release mode. Maybe you could try compiling your application with another compiler (MinGW if you use VS, VS if you use MinGW etc.). Unfortunately, I have no idea about C++, so I can’t suggest more…
Another thing to double check is any code you have wrapped in #ifdef DEBUG or #ifdef NDEBUG - maybe you stuck some code in one of those (or outside of one of those) that you meant to be outside the block (or inside of it)
as zengar pointed, it should have nothing to do with opengl. in many, many cases it’s, that you forgot to initialize some variables or zero allocated memory etc., which is done automatically in debug mode but not in release mode.
this is at least the case if you use visual studio. I often had problems like this and it always turned out to be something of the above mentioned.
further reading: http://www.flounder.com/debug_release.htm
–styx