Visual Studio 2008 + OpenGL + Release Configuration looks terrible
Author
Hi All,
Got a problem that's making me pull my hair out. Wonder if anyone can shed some light.
I'm working in Visual Studio 2008 (under Windows Vista 64-bit), using OpenGL and C++. The Debug configuration works fine, but when I switch to the Release configuration the image quality becomes terrible.
For comparison, here are two snapshots:
Debug: http://www.stellaralchemy.com/debug.jpg
Release: http://www.stellaralchemy.com/release.jpg
If I set "Basic Runtime Checks" to "Both (/RTC1, equiv. to /RTCsu)" in the release configuration properties, then the problem goes away, but this setting is said to be "incompatible with any optimization type other than debug" and I'd rather not have to forgo optimizations.
Has anyone else ever seen anything like this? Any suggestions?
Cheers,
Lee
I haven't, but it looks like precision is being lost.
Maybe disabling floating point optimisations only might help?
Really just a guess, but it might help
Mathmo
Maybe disabling floating point optimisations only might help?
Really just a guess, but it might help
Mathmo
What are you doing exactly?It looks as the color depth has switched to 16bits in release mode.
It could be something as simple as an uninitialized variable.
It could be something as simple as an uninitialized variable.
Author
Thanks for the suggestions, guys.
@Mathmo:
I'm not sure which optimizations you're referring to. I've got "Floating Point Model" set to "Precise" and "Enable Floating Point Exceptions" set to "No".
@Black Knight:
Wouldn't an uninitialized variable cause the problem in both configurations if it were responsible? I'll hunt around to see if I have any, though! Thanks. Will post reply if I find any.
I've experimented a bit more and I can be a little more specific - the "Basic Runtime Checks" option can also be set to "Stack Frames" or "Uninitialized Variables". When set to "Uninitialized Variables" the problem persists. When set to "Stack Frames" everything is fine again. I hope that narrows down the possibilities.
@Mathmo:
I'm not sure which optimizations you're referring to. I've got "Floating Point Model" set to "Precise" and "Enable Floating Point Exceptions" set to "No".
@Black Knight:
Wouldn't an uninitialized variable cause the problem in both configurations if it were responsible? I'll hunt around to see if I have any, though! Thanks. Will post reply if I find any.
I've experimented a bit more and I can be a little more specific - the "Basic Runtime Checks" option can also be set to "Stack Frames" or "Uninitialized Variables". When set to "Uninitialized Variables" the problem persists. When set to "Stack Frames" everything is fine again. I hope that narrows down the possibilities.
Author
Quick note:
I deliberately set color depth to 16 bits in my PIXELFORMATDESCRIPTOR and the drop in quality is nowhere near as bad as seen in the snapshot image. Must be something more drastic afoot.
I deliberately set color depth to 16 bits in my PIXELFORMATDESCRIPTOR and the drop in quality is nowhere near as bad as seen in the snapshot image. Must be something more drastic afoot.
Just a small fyi: un initialized variables are actually zeroed out in debug mode, but just a random chunk of memory in release mode. (zeroed out may not be the right term, but it is close enough.)
Author
Quote:Original post by vs322
Just a small fyi: un initialized variables are actually zeroed out in debug mode, but just a random chunk of memory in release mode. (zeroed out may not be the right term, but it is close enough.)
Thanks! Good to know.
Author
By initializing OpenGL before initializing my model (although nothing in my model initialization makes any OpenGL calls) I seem to have solved the problem - perhaps only temporarily, time will tell.
I'm none the wiser, but at least the problem has gone for now ;)
I'm none the wiser, but at least the problem has gone for now ;)
Author
Last update (hopefully):
The problem returned, but I think I found its root cause. It seems I was exceeding the limit on a matrix stack in OpenGL. Problem was solved by avoiding pushes and pops and just reversing all the transformations (scale, rotate, translate) that were previously done between glPushMatrix and glPopMatrix calls. Seems to have solved it. No Basic Runtime Checks needed anymore.
Cheers!
The problem returned, but I think I found its root cause. It seems I was exceeding the limit on a matrix stack in OpenGL. Problem was solved by avoiding pushes and pops and just reversing all the transformations (scale, rotate, translate) that were previously done between glPushMatrix and glPopMatrix calls. Seems to have solved it. No Basic Runtime Checks needed anymore.
Cheers!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
