Add PhysicsTimescale resource for slow-motion or fast-forward simulation

[dasisdormax]

I can't think of much to say about this change right now.

If something is unclear, please ask. Thanks for your work and your time!

[Jondolf]

Thanks, looks good overall, and I appreciate the docs with a code example.

The only thing I'm not sure of is if it should actually change the number of physics runs as well. With the current implementation, large time scales will cause jittery behaviour and some missed collisions, because it's running the same number of steps as before, but just advances the time more.

It might make sense to run physics more times with larger timescales by just removing the multiplication of raw_dt by the timescale. This would give consistent behaviour accross time scales for fixed and variable timesteps, although it will also impact performance, and it wouldn't work with PhysicsTimestep::FixedOnce because it only runs once per frame.

I guess this could also be done by the user by dividing DeltaTime by the time scale, but in that case it should maybe be mentioned in the docs. I'm not sure how other engines handle time scale though, so not sure what the best approach is

[Jondolf]

Actually no, I think the way it is now might be better for now. If we ran physics a different number of times based on the time scale, slow motion would be very choppy, as the positions would be updated way less. (without interpolation)

We can maybe keep it as it currently is, but we should mention in the docs that large timescales can decrease the accuracy of the simulation and introduce jitter, and that the behaviour can be made consistent by dividing the delta time by the timescale.

Does that sound fine? Also, sorry for the back and forth :P

[dasisdormax]

No problem, I was myself unsure about the best way to do this.

I'll update the doc and try to make these points and possible issues clearer.

[Jondolf]

Thanks, looks great now!