Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Necrosis

Anyone experience anything like this?

This topic is 6192 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, I use MSVC++ 6.0 . I finished writing a game using the Dos Console App project (ascii graphics, nothing very complex). I tested it as much as I could, running the exe it made in my debug folder of the project. I then fired up the complier again, and recompiled in release-mode so I can have a smaller exe without the un-needed debugging information, just incase I wanted to send a copy of my program to a friend or whatnot. However, after running the new release-mode created exe, the program did NOT run like it had when I compiled in debug-mode. Very hard to describe just how wacky my program acted. I ended up loading up Dev-C++ and building the project without debugging info to get my "release" program. Though I disliked having to load up a FREE compiler to do this, it got the job done. I suspect this wouldn''t happen when I''m past the dos console. Anyways, I''m not looking for a solution to my problem, and I''m not asking what I did wrong (which is why I left out details). My question is what kind of things are changed from the debug version to the release version of a console app beyond stripping the debug info? I''ve never seen any difference in performance before, which is why this is startling, and without the debug info, I cant go through the program and see what it''s doing different. Perhaps if I know what kind of changes happen, I can avoid this problem in the future

Share this post


Link to post
Share on other sites
Advertisement
In MSVC, the differences are fairly major. There''s a whole lot of sanity-checking code that is left out in release mode. One of the major differences is that debug fills memory areas with key values so you can hope to tell if you''re accessing an uninitialized variable, or if you''ve overflowed your memory area. None of that filling or checking is in the Release. _DEBUG isn''t defined, so if you''re doing anything special with that it won''t be in there. Other than that, it''s all optimization I believe (unless there''s something I''m forgetting).

It''s hard to tell what behavior is giving you a problem--it just worked with a different kind of efficiency? Or are you getting crashes? If you really, really need to debug a crash that only happens in Release mode, you can turn on the program database in your release mode build and then use the debugger. However, be warned--you are almost guaranteed that none of your watch variables or anything will make sense from the beginning of the function till the end. The compiler is free to do any number of zany things with stack pointers and such to optimize your code, which makes things very hard to track.

Share this post


Link to post
Share on other sites
Wel, I dont crash. I have a matrix I''m using to simulate a Connect 4 game. User has a choice of 7 columns to drop their pieces in, and it drops the chip into the lowest available row of that column. Couldn''t work better in debug mode, but release... first chip that drops all of a sudden appears in the first row of every column, after, you cant see other chips that drop, it''s just really bizzare behavior

Share this post


Link to post
Share on other sites
When you get used to Visual Studio, Debugging in Release mode becomes almost a religious experience. In a project I''ve been working on the past 2 years (250.000 lines), everything seemed to be working fine in the debug build - no errors, warnings, exceptions, it ran fine.
In release mode, it didn''t even start up. In the end, we''ve located 3 specific bugs, 2 of which should NEVER have compiled, and 1 which is so odd that nobody can explain it. (A static member in a class getting initialised three times).

Your only option is to have some sort of a logging mechanism, that writes specific values to a text file, so you can see what variables are written where, and if their values are correct.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

Some of those release mode only optimizations will impact any floating point math that you might be doing. You sometimes get more or less precision in floating point calculations when you switch modes. This happens because release mode will tend to keep floats in registers and debug tends to keep them in memory.

If you are using == (for example) on floats, that could break your code in one mode but not the other. So never use == on floats.

Share this post


Link to post
Share on other sites
Yeah, happened to me all the time. That is why I like Borland and GCC, the onlly difference between debug and release mode is debug information period! You can even turn on optimisations.

Borland also has a nice tool call CodeGuard which let you know about pointer accesses and memory leak. Very neat and much more usefull than VC++ padding.

Share this post


Link to post
Share on other sites
You need to compile release build and test them frequently to find bugs like those. I''ve had memory stompage bugs that went undetected in debug build, and then didn''t run right at all in release builds.

A reboot & a full rebuild can sometimes help.

Magmai Kai Holmlor
- Not For Rent

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!