Velocity capped on lower fps

Discussion and feedback on Construct 2

Post » Wed Apr 10, 2013 10:48 pm

The only way to solve this is to use framerate dependent physics. It's one of the few cases where you should avoid dt.

The Box2D manual explains this issue a bit:

[quote]Box2D uses a computational algorithm called an integrator. Integrators simulate the physics equations at discrete points of time. This goes along with the traditional game loop where we essentially have a flip book of movement on the screen. So we need to pick a time step for Box2D. Generally physics engines for games like a time step at least as fast as 60Hz or 1/60 seconds. You can get away with larger time steps, but you will have to be more careful about setting up the definitions for your world. ... generally you should use a time step no larger than 1/30 seconds[/quote]

Basically physics engines become unstable with large time steps. I guess the error compared to the "true" result gets really big. If you use dt as the time step, then the FPS gets really low, dt becomes big and the physics will become unrealistic. The only solution is to use a fixed timestep and let the game go in to slow-motion. (Increasing the iterations to improve the simulation quality will reduce the FPS even more!) 10 FPS is usually unplayable anyway, are users really getting that bad results?

The Box2D manual actually recommends against a variable time step for stability reasons (and dt can have quite a lot of variation). That's part of the reason physics defaults to a fixed timestep. It's still nice to have framerate independence, but I guess Physics is unique in that it can cause problems, and it might be less bad to use fixed stepping.

Edit: I guess we could add a maximum time step for Physics, to be 1/30. So it's framerate independent down to 30 FPS, then slows down the motion beneath that.Ashley2013-04-10 22:49:34
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,630

Post » Wed Apr 10, 2013 11:11 pm

That seems like a good fix!
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Thu Apr 11, 2013 1:30 pm

Thanks @Ashley for the detailed reply.

10fps is an extreme example to illustrate the problem. A more realistic scenario is when framerate drops to about 20 with a complex level on ARM-based Windows 8 devices.

What's strange is that it's not erratic physics behaviour, but more a cap on the maximum velocity. I can never get objects to 'teleport' on a low frame-rate because they can never go fast enough. At 10fps the maximum VelocityX I can get is 1000, even if I apply a million.

Here's a video that should explain better. Each replay is a lower frame-rate (the first is 60, last is 10).

[TUBE]http://youtu.be/dkP24bdIbJs[/TUBE]

"I guess we could add a maximum time step for Physics, to be 1/30. So it's framerate independent down to 30 FPS, then slows down the motion beneath that."

Can I edit the generated source to take a peek at how this affects things?
Moderator
B
72
S
13
G
11
Posts: 900
Reputation: 11,783

Post » Thu Apr 11, 2013 5:16 pm

@thehen - feel free to hack the physics behavior to try it out.

Box2D uses a different collision engine to C2, which is continuous, so you should never get teleporting with the physics behavior. If the time step becomes too large and the physics engine becomes unstable, I guess anything could happen - including arbitrary velocity limits.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,630

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: gamecorpstudio and 17 guests