Prevent physics non-determinism

My game that has no random elements, behaves differently every time I run it. I use the Box2D stuff so I wonder if that's the source and if anyone knows the fix?

fps and with that dt will be different (even if differences are very minimal), so the physics calculations will be carried out at different positions in time and space (I believe)

Unfortunately it so far seems that C2 doesn't use an improved fixed timestep. C2 uses a simple version so I'm sure it's going to be impossible for solid deterministic physics using C2 current implementation of Box2D :(

you stars. I found a stepping mode in physics which does it!

scirra.com/manual/98/physics

EDIT: hmmm that doesn't quite cut it due to my other timers going off every XXX seconds and interacting with the physics.

I once implemented a time accumulator for a physics engine to properly decouple these things (gafferongames.com/game-physics/fix-your-timestep/)

I wonder if its possible to get that kind of approach into construct 2

EDIT 2:

yeah running my behaviours off of "every tick" with physics stepping on fixed made it deterministic. However my frame rate suffers. I believe, that if you were able to switch physics on and off rapidly and not process interactive behaviours every tick, you could play catchup with the frame rate like a time accumulator. There is no global on and off for physics though so I don't think it is feasible at this point.

You can't have it both ways. Either it's framerate independent and non-deterministic, or framerate dependent and deterministic. I would recommend framerate independent, and design your game with wide enough tolerances that the random variations are not significant to the gameplay.

That's not true. Havok and suchlike decouple their physics from the frame rate and still achieve determinism via a time accumulator (which I linked, but here it is again gafferongames.com/game-physics/fix-your-timestep/).

Basically you only step the physics a fixed amount k, after after dt > k wallclock time has passed. You keep track of the remainder k-dt and use it in future calculations to decide whether to perform a physics step or not.

In summery, you decouple the physics stepping from the rendering thread entirely.

This means several frame renders may occur in series before actually updating positions. To stop jerkiness, you integrate the time remainder with the velocity and last updated positions. i.e. you linearise the motion model and project into the future when demanded by the rendering thread.

This decoupling physics from framerate is a common pattern in game development. But its not obvious unless you have seen it before, see also gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step

In construct 2 a event tick is tied to frame rate. So to decouple physics we have to decide whether to step or not. So we would need functionality to globally enable or disable physics evaluated every tick. Or choose to manually tick the physics ourselves in the event sheet.