Velocity capped on lower fps

Discussion and feedback on Construct 2

Post » Wed Apr 10, 2013 4:14 pm

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.



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?
Moderator
B
72
S
13
G
11
Posts: 900
Reputation: 11,783

Post » Wed Apr 10, 2013 6:32 pm

What's your physics stepping mode?
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Wed Apr 10, 2013 6:54 pm

Framerate independent :)
Moderator
B
72
S
13
G
11
Posts: 900
Reputation: 11,783

Post » Wed Apr 10, 2013 7:37 pm

@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: https://www.scirra.com/tutorials/67/delta-time-and-framerate-independence

2nd edit/ Hmmm, after rereading your post, I see you're not going below 10fps, so maybe that's not the cause...
rogueNoodle2013-04-10 19:45:35
B
9
S
3
G
4
Posts: 63
Reputation: 3,083

Post » Wed Apr 10, 2013 7:58 pm

@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.
Moderator
B
72
S
13
G
11
Posts: 900
Reputation: 11,783

Post » Wed Apr 10, 2013 8:01 pm

Have you tried changing the stepping mode to framerate dependent? Or does that bring up problems?
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Wed Apr 10, 2013 8:42 pm

Does this glitch link with this glitch?
http://www.scirra.com/FORUM/frame-rate-affecting-player-jump-arc_topic62067.html?KW=
B
45
S
19
G
10
Posts: 562
Reputation: 9,543

Post » Wed Apr 10, 2013 8:50 pm

@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.
Moderator
B
72
S
13
G
11
Posts: 900
Reputation: 11,783

Post » Wed Apr 10, 2013 8:59 pm

Hmm... I think you're stuck, unless you can come up with a way to lock it at 30fps or something.
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

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

Next

Return to Construct 2 General

Who is online

Users browsing this forum: gamecorpstudio and 17 guests