Physics improvement

[sirherrbatka]

I don't think that physics call count can go above FPS count in the fixed model...

Anyway! Can someone explain this? Won't take much time and it will please me

[Zini]

I am thinking Aedra was designed for windows only, so some things aren't working properly in linux/mac. I'll have to fix this, not a linux user though, may need some help from you linux guys.

At least some of what I see is not a platform problem. Aedra uses C++11 (or at least a subset of it). We are using C++03. Some of the Aedra code is simply not valid C++03.

[Chris]

Here's the logic:

Fixed 60 FPS physics calls, when the game is running at 1 FPS: for every frame, you have to call physics 60 times.

Variable FPS physics calls, when the game is running at 1 FPS: for every frame, you have to call physics once.

The problem comes in when you consider floating point inaccuracy and rounding errors. If you update the physics once a frame, then you will not get the same simulation with 30FPS as with 60FPS because the values become larger to compensate for the extra time, thus lose precision. This is an even bigger problem with really high frame rates because then the values become very small and may press the limits of the physics calculations and floating-point accuracy.

With a fixed delta, you don't run into that problem because no matter how many FPS you get, you will do the same 60 physics updates per second. A low frame rate will do the exact same physics calls as a high frame rate, thus guaranteeing identical simulations.

[EmbraceUnity]

At least some of what I see is not a platform problem. Aedra uses C++11 (or at least a subset of it). We are using C++03. Some of the Aedra code is simply not valid C++03.

Any reason not to upgrade to C++11?

[Zini]

There isn't a single compiler out there that fully supports C++11 yet. Various compilers support different bits of it. Which means whenever someone uses a C++11 feature chances are good the code will not compile on at least one other developer's system. We had already trouble with that.

[corristo]

My voice for fixed physics update rate.
Is there any way to decouple rendering updates from others? We have another related problem: at low fps input is very laggy, so input should be processed like physics, imo, at fixed fps.

Correct me if I'm wrong.

UPD: cool article about different game loop approaches.

[Chris]

My voice for fixed physics update rate.
Is there any way to decouple rendering updates from others? We have another related problem: at low fps input is very laggy, so input should be processed like physics, imo, at fixed fps.

Correct me if I'm wrong.

Personally I'd say the whole logic routine should run at a fixed rate, and simply skip certain bits when falling behind (like rendering, since a missed frame or two won't affect the next one rendered). Just implement a lower bound, 1/4th the fixed rate for example, so if the frame rate drops too low, the simulation will actually slow down until it picks back up.

And yes, I too get "laggy" input when the frame rate dips. It feels like I'm moving in molasses even though the FPS is acceptable for play.

[Greendogo]

Any reason not to upgrade to C++11?

C++11 is done, but it's not "ready", ya dig?

[Zini]

I am not sure if this whole discussion is useful at this point. If we start improving the main loop, we most likely will have to make a lot of architectural changes (at least if we are doing it properly; the current design is admittedly less than optimal). I think we all remember how the mwrender refactoring hit our progress rate. Not keen on seen a repeat of that.

So is there really a pressing need to change to a different type of main loop right now? If not, I suggest keeping it as it is and review the situation again after OpenMW 1.0. If we really must change it (because physics don't work well enough with the current implementation), we should go with a minimal solution.

[scrawl]

We don't need to change the main loop. We can just divide the physics update into substeps depending on how much rendering time has passed - that way, physícs will update at fixed fps.