I have an OpenGL project developed using MS Visual C++ 6.0. The debug build version (launched outside of developer studio) works ok but the release build version - although it appears to run ok - does not render anything in the client area. I’m at a loss to explain how the exact same code could behave so differently. What a nightmare…
Hello,
I know nothing about Microsoft and it’s release yada yada stuff, save for this:
you are NOT using the EXACT code stream. As soon as you start adding/removing break points, removing trace writes and assertions and a large manner of other things, then you ARE modifying your code stream.
er, so. yer.
cheers,
John
vc helps you out by not doing what you ask it to in debug builds eg u might ask for an array of 20 numbers
int *num = new int[20]
vc will ignore the 20 + give you more (cause its such a nice compiler)
so u can go printf("%d",num[25] ) quite happily. unfortunately debugs older brother the realease guy is not so friendly it’ll only give you 20 int’s. the penny pinching bastard
Originally posted by zed:
vc helps you out by not doing what you ask it to in debug builds eg u might ask for an array of 20 numbers
int *num = new int[20]
vc will ignore the 20 + give you more (cause its such a nice compiler)
so u can go printf(“%d”,num[25] ) quite happily. unfortunately debugs older brother the realease guy is not so friendly it’ll only give you 20 int’s. the penny pinching bastard
I think what you’re talking about is the ability to tell Debugger to ignore certain types of handled exceptions (e.g. Access Violations) which could cause a crash in Release mode. My Debug is setup to always stop on Access Violations and I’m not getting any. I’m not crashing in Release mode - just nothing is being drawn in client area, whereas Debug renders OK. If it crashed, I could fix it. But it’s not, everything appears to be processing ok so I dont know what’s going on. After weeks of work and testing in Debug mode, to suddenly discover that the Release version inexplicably does not work is shattering. I better quit now before I say something nasty about OpenGL that I may regret.
I quite agree with zed: each time I had this problem was because of bad memory management… I did access an array element beyond the limits, which was OK for Debug but would crash the Release (by the way zed, thanks for the explanation, I didn’t know that !).
You should really investigate this.
Regards.
Eric
P.S.: if what zed said is correct, you wouldn’t have any Access Violation in Debug Mode so the setup of your Debug isn’t important here…
Debug mode also initiates variables to 0 and a load of other nice things that end up makeing life misery when you try a release build. I have a problem with my octree class in release mode. To help solve the problem I built it in release mode but turned of all the optermizations and it worked, then I tried each and ever singular opt. and found the problem- /Ob1 which is used if you have the /O2 opt. This still hasn’t helped me find the problem but at least I can use the release mode with most of the optermizations.
Tim
[This message has been edited by Tim Stirling (edited 07-06-2001).]
Originally posted by Tim Stirling:
[b]Debug mode also initiates variables to 0 and a load of other nice things that end up makeing life misery when you try a release build. [b]
Mystery solved - pilot error! You’re right. In my app the “gldfov” parameter of the gluPerspective(…) function is configurable and it was not being intialized so it was using a FoV of 0 degrees. Not sure what value the Debug build assigned to it.