Differences in debug/release problem.

[Kim]

OS: Win7
SFML: 2.1
Language: C++
IDE: VS2013

I am working on a physics simulation, and when I felt it was quite complete I decided to build a release build but the physics is all messed up. Could it be my FPS that is messing things up? On a slower machine I have a lot lower FPS, that is ranging from 80fps with tracers on in debug to 350 in release with tracers on.

I have this in my code:

window.setFramerateLimit(40);

So I guess my FPS counter is a bit misplaced as well.

Code snippet for FPS.

(click to show/hide)

times = clock.getElapsedTime();
                window.clear(bg);
                mss.Update();
                if (displayInstruction)
                        DrawInstructions(window);
                DrawFPS(window,  times, mss.GetBodyCount());
                window.display();
                clock.restart().asSeconds();

Here below is on image with the "wrong" physics and one image with the correct physics.
Release (wrong), Debug (correct)

The formula I use are the same in both builds it is the gravity law formula. If it matters both builds also uses floats for masses, velocity and such. There is so much code in this so I do not know were to start showing it if it is necessary but since the code works as intended in debug I hope it is a some what easy way to fix this problem. So do anyone have any clue on why this could happen?

Feel free to ask questions if more information is needed since I really do not know what to provide.

[Ixrec]

This probably means your physics engine is sensitive to the size of the timestep.  This is a common problem with almost all non-trivial physics engines, and it's the main reason why techniques like the fixed timestep exist.  Most likely, you want to implement a fixed physics timestep.

Some helpful reading to get you started:
http://gameprogrammingpatterns.com/game-loop.html
http://gafferongames.com/game-physics/fix-your-timestep/

Though before you spend too much time on this, quickly try setFramerateLimit() on a bunch of random values from 60 to 10000 just to make absolutely sure that your simulation results really do depend on the framerate.

[Kim]

Thanks! I'll take a look

[Kim]

I have tried these Frame rate limits in Release:

window.setFramerateLimit(60);
window.setFramerateLimit(100);
window.setFramerateLimit(1000);
window.setFramerateLimit(10000);
window.setFramerateLimit(100000);

They behave the same was in all limits with the wrong physics.
I tried the same in debug, and they also work the same in all limits but with the correct physics in all of them.

[Ixrec]

Weird.  That would imply some part of your code (or less likely, SFML) is relying on undefined behavior that's affected by the build mode.  Not sure what to do other than painstaking debugging until you can pin down what specific piece of code is behaving differently.

[Kim]

I just tried to see if it could be optimization that was doing something and if I use /Ox (Full optimization) in
Debug-mode I get the same problem as in release. And if I disable optimization in Release it works as in Debug-
mode if that could be any hint to what could be wrong.

I do not know how it optimize my code but the same problem occur with /O1, /O2 and /Ox