Velocity capped on lower fps

Hi all,

This is an issue I've had since the beginning of Mortar Melon dev that I've tried to work around.

The below image shows the resulting VelocityX after applying a VelocityX of 1900 in a trigger. This works as expected on a higher framerate, but on the lower framerate it caps at just over 1000. This also occurs when applying an impulse or force on a trigger.

<img src="http://i.imgur.com/NGjTOwZ.jpg" border="0" />

If I then go and increase 1900 to a much larger number, the cap on velocity stays the same when running at a lower framerate, whilst the higher framerate behaves as expected.

I previously attributed slight variations in physics forces to being framerate independent and the waverings of delta time. However with a capped velocity I can't see a way to work around this.

Any thoughts would be much appreciated. Ashley?

What's your physics stepping mode?

Framerate independent :)

thehen - In the tutorial for Delta-time and Framerate Independence, there is the following note under Advanced Considerations - seems related:

"At very low framerates, dt can become very large. For example, at 5 FPS, dt is 0.2. An object moving at 500 pixels per second is therefore moving 100 pixels per tick. This can cause it to "teleport" through walls or miss collisions with other objects.

Games are usually unplayable at such low framerates, but it is even worse if they become unstable like that. To help the game stay reliable even at very low framerates, Construct 2 does not let dt get larger than 0.1. In other words, below 10 FPS, dt stays at 0.1. This does also mean below 10 FPS the game starts going in to a slow-motion effect (described earlier as one of the issues of framerate dependent games), however this is usually a better result than the "teleporting objects" problem."

I'm guessing the slow-down is due to the minimum dt (to prevent the collisions from failing).

edit/ Argh, can't post links yet - here's the tutorial: construct.net/en

2nd edit/ Hmmm, after rereading your post, I see you're not going below 10fps, so maybe that's not the cause...

rogueNoodle I thought this was the cause too, but the effect is the same at around 15fps. I also removed the 0.1 dt cap from the generated source to no avail. I also don't see a 'slow-mo' effect, but a decreased force effect instead.

Have you tried changing the stepping mode to framerate dependent? Or does that bring up problems?

Does this glitch link with this glitch?

construct.net/en

sqiddster framerate dependent works fine, but with a target fps of 30 on mobile devices I don't want everything to be in slow-mo ;)

Jase00 Interesting, that looks like it could be related.

Hmm... I think you're stuck, unless you can come up with a way to lock it at 30fps or something.

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:

ox2D 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

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.

That seems like a good fix!

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?

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.