Dt and physics and fixed time... need some calrification...

Hey everyone,

I keep seeing that you really shouldn't use dt with physics due to small changes causing potentially large changes in how physics operate each time you play a game. It is my understanding that we are talking about very, very small changes (that certainly can cascade) but that shouldn't have an effect on, say, a racing game? or anything that's not angry birds or similar. Sure dt will change and in a puzzle game or anything where physics needs to behave very consistently this could be bad, but anything else seems like it doesn't matter.

but what does matter in most games is framerate independence... So, shouldn't the default be to use dt with physics unless your project fits certain criteria?

On another topic, I have noticed that some other game engines actually incorporate multiple time steps. Unity, for example typically is scripted to have physics run in a fixed update loop (like 40 times a second) while the main game loops is running 60 times a second. I have been using physics for a while and it doesn't seem like dt does anything bad to it in an action game where nothing relies on a tower of blocks falling the same way each time.

Can anyone elaborate on any of this?

And... also, could one use every (1/40) seconds to create a fixed timestep in construct? Are those timesteps called independently of when the main game event loop is running (in other words is a fixed timestep called on time, evertime, regardless of what is going on) ***EDIT*** This won't work because physics is updated once a tick in the behavior- does anyone know if there is an update method for behaviors that uses a fixed timestep?

It is weird, because not using dt with physics cause the game to speed up and slow down... would a fixed timestep solve this and the issue of not using dt?

it is possible to enable framerate independancy in the physics of C2 (I do not have C2 right now, but I think it is called stzppkng mode, you have to use an action to change it, if you are above 30 fps, the framerate independency will exist, but under 30 fps it will slow down)

every 1/40 seconds could be used but I would rather have a way to not go in accordance to the V sync itself and specify a framerate(funfact, if your refrzsh rate is 120 hz, the game will try to go at 120 fps), as it can look very bad if some objects just lags in some frames when others are fluid (but I understand what you mean).

Aphrodite - I knew about the stepping mode... I always make very project framerate independent and it seems to work just fine an many circumstances... I just don't understand why there is so much about physics needing a fixed time step.

I did just realize though that you can't use every x seconds to make a true fixed timestep. this is because physics box2d world is going to be updated in tick(). Everything box2d does, is done once every game frame regardless of dt... I wonder if there is a fixed update call for plugins and behaviors. I know there is pretick and post tick stuff but I have now clue about fixed update.

" I just don't understand why there is so much about physics needing a fixed time step."

it seems to be consistency, the same physics interactions by default should return the exact same result, and framerate dependacy makes every frame act the same way normally as there are no compensation to a varying framerate to be done.

I'd like to see an event like "Update behavior" rather than the engine doing it only by itself, I guess it is not what is planned though.

There are lots of simple physics-related simulations that are unstable at low- or variable-frequency (spring compression, rotational fields with correcting factors to compensate for discrete integrations, etc.). Using the semi-fixed time-step also helps with the underlying implementation, as we know the simulation will not need to try to cope with certain degenerate cases, which helps with collision detections, computing swept surfaces and volumes, etc.

That might have little impact on small games that don't actually need any of these features, but it's usually good practice to prioritise stability of the simulation under reasonable assumptions when implementing a physics engine. Therefore there's no real reason not to do it, even if you don't need it. It might feel a bit over-cautious, but it ensures some form of consistency.

Also, it is NOT realistic to expect a physics simulation (or any mathematical computation, for that matter) to be deterministic across multiple platforms. While a physics simulation can be made deterministic on a given platform, it relies on the low-level math hardware for that platform. While a recent desktop CPU will provide fast vectorised maths with high precision, a mobile chip will certainly offer much less precision. This difference will cause inconsistencies. When using native code, even a compiler switch (fast math, etc.) can modify the behaviour of math/physics computations.

When it comes to math/physics and computers, determinism is a very tricky requirement and should be considered a major technical risk for any application. If a game relies on deterministic physics, you're likely to need specific libraries for every category of platform, as a recent i7 and an old iPad2 have little in common in terms of electronics. Obviously, this gets easier if you target a limited set of platforms only ; which is quite hard to do if you have "mobiles" in mind.