# frame independent movement and slowdowns

This topic is 2022 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

what happens with frame independent movement when the frame rate drops drastically?

from my understanding, the visual feedback (frame rate) will slow down, while the simulation continues to run at full speed.

and even putting an upper limit on the time step (say 250ms) still will cause problems if the frame time is say 300 ms, correct?

is it a fair statement to say that frame independent movement does not degrade gracefully when the frame rate drops drastically?

##### Share on other sites

well if the frame rate drops drastically then there will be more movement per frame to make up for that frame rate drop.

say you have dt which is the time elapsed from the last frame and say you have something that you want to move 20 units per second - regardless of frame rate..

well every frame you would say "this frame the object will move 20 * dt" and update it with that much movement

So for example if the first frame dt = 0.010 seconds then the movement for the first frame would be 20 * .010 = 0.2 units..

Say the next frame dt = 0.3 seconds (300 ms) then the movement for that frame would be 20 * 0.3 = 6 units

In effect you will always move at 20 units per second regardless of frame rate - However lower frame rate will cause the movement to look more choppy (6 unit jump in a frame rather than 0.2 unit jump ) but at 3 frames per second (300 ms per frame) everything will look choppy most likely

##### Share on other sites

In effect you will always move at 20 units per second regardless of frame rate - However lower frame rate will cause the movement to look more choppy (6 unit jump in a frame rather than 0.2 unit jump ) but at 3 frames per second (300 ms per frame) everything will look choppy most likely

my concern is that slowdowns usually occur in heavy combat with lots of stuff on the screen. so just when things get busy, the display slows down. but the simulation keeps right on running at full speed. since the player can only "play" (respond) as fast as he gets visual feedback, even with a frame independent input loop, the result is that the simulation "speeds up" relative to the video, and the player's "playing" speed. so instead of player and video at 60 fps and movement at 20 fps, you have player and video at 3 fps and movement still at 20 fps (so to speak).

another concern is interpolating or extrapolating the unit's position for drawing, and the loss of lockstep sync accuracy of the rendering loop.

i've been considering frame independent movement, but the problem with slowdowns has caused me to use a single loop for render, input, and simulation and to use a frame rate limiter. the fame rate limited single loop degrades gracefully, even under the heaviest fire.

##### Share on other sites

my concern is that slowdowns usually occur in heavy combat with lots of stuff on the screen. so just when things get busy, the display slows down. but the simulation keeps right on running at full speed.

The display doesn't slow down relative to the simulation - if the frame rate drops the display shows "choppy" movement not movement in slow motion...

another concern is interpolating or extrapolating the unit's position for drawing, and the loss of lockstep sync accuracy of the rendering loop.

im not sure im following your concern here.. you update everything and then draw everything once per frame... if the unit is moving at a speed per second you multiply that speed by the time elapsed for that frame and the result is the unit will move an amount per frame that keeps the units speed what you want..

if your objects are "slowing down" when the frame rate drops it probably means you are not using the elapsed time per frame to determine how much your objects should move

##### Share on other sites

The display doesn't slow down relative to the simulation - if the frame rate drops the display shows "choppy" movement not movement in slow motion...

that's what i mean by "slow down". the presentation rate slows down, resulting in a choppy / stop motion effect.

i recall Aces of the Deep had this problem. You'd be 400 meters off the starboard side of a destroyer, ready to do a shoot and dive under maneuver, then the shells and depth charges would start going off, and the explosion and water splash graphics would cut the framerate to something like 2fps for about 3 seconds. In that time, your sub would have  already passed the minimum firing distance, and the minumum diving distance, resulting in a collision and death every time. all because they didn't slow down the simulation to keep pace with the input/feedback system (IE the graphics is the feedback system, and how fast the player can react to what they see is the input

im not sure im following your concern here

).

RE: INTERPOLATING

some implementations use an accumulator for fractions of dt, and then use that fraction of dt to interpolate between the last and current positions when drawing. or extrapolate between the current and anticipated next positions. interpolation  or extrapolation means the screen no longer reflects the current state of the simulation, but some previous state, or anticipated state, IE what was happening up to one game turn ago, or might/would happen with no user input up to one game turn from now. while one frame of lag is probably ok under normal circumstances, if you get that heavy combat spike and drop to 2 fps, you add on top one frame of lag at 2 fps, or an extra half second of delay in feedback. in a hard core flight sim, a half second delay can mean life or death when toggling the pickle.

##### Share on other sites

some implementations use an accumulator for fractions of dt, and then use that fraction of dt to interpolate between the last and current positions when drawing. or extrapolate between the current and anticipated next positions. interpolation or extrapolation means the screen no longer reflects the current state of the simulation, but some previous state, or anticipated state, IE what was happening up to one game one turn ago

ahh okay so your talking about being able to correctly extract user input during times of lag so that the choppy part doesn't include the plane crashing (which could have been avoided if the user gave some type of input ) or whatever game event that may occur during the large timestep of a dt that is too large that might have been changed with some kind of user input - I understand you now.

Sorry I think I just misunderstood the question - I would have to agree that the ability to get input from the user and apply it to the scene correctly does degrade ungracefully as the frame rate drops. It's true that the user can only respond to what they see and so if all they can see is the enemy there one second and then in another spot the next it really deminishes their ability to hit the enemy with anything

##### Share on other sites

ahh okay so your talking about being able to correctly extract user input during times of lag so that the choppy part doesn't include the plane crashing (which could have been avoided if the user gave some type of input ) or whatever game event that may occur during the large timestep of a dt that is too large that might have been changed with some kind of user input - I understand you now.

sort of, but a bit more than that. even if the input loop is still running fast, the user can't put in input fast, because the user must react to the feedback the screen gives him, which is slower than the simulation and the input loop.

as the display slows down, the rate at which the user can react slows down, but the game keeps running fast. from the player's point of view, who is playing at 3fps (the speed of the graphics during slowdown), the game's speed relative to the players speed has increased. technically the graphics and player reactions slow down, but from the player viewpoint, the simulation behind the graphics "speeds up". but thats not really the point. the point is that the simulation no longer runs at the desired speed compared to the graphics and the player's reactions.

Sorry I think I just misunderstood the question - I would have to agree that the ability to get input from the user and apply it to the scene correctly does degrade ungracefully as the frame rate drops. It's true that the user can only respond to what they see and so if all they can see is the enemy there one second and then in another spot the next it really deminishes their ability to hit the enemy with anything

like so many gamedev questions it can often take two or three askings to get on the same page.

yes, you've hit it "spot on" as they say.

i think for that reason, i will not be using it in any heavyweight title where that could be an issue. since the problem is caused by a sudden increase in drawing time for a single frame, that would rule out any title where things can get really busy and slowdown at just the wrong moment. while "momentary player paralysis" or momentary player "time stop", or momentary player "super slomo" might be acceptable for a shooter where it only costs you a few bullets, for something like a sub sim, where you spend up to half an hour of realtime (at 4096x speed) just getting to the target, then another hour of realtime stalking it to setup the perfect encounter, then 15 minutes on the final apprach (never at more than 2-4x speed), just to have the simulation and render loops come unglued as your about to shoot and crash dive? even with a work of art like aces of the deep, it would sometimes be a day or two before i'd play it again.

##### Share on other sites

Ok, so you're not really complaining about frame independent movement, you're complaining about slow input and output speeds, ie. the latency between the player seeing something and being able to act on it. The movement itself degrades perfectly well at low frame rates - it's the player's ability to respond to it that fails to degrade well.

Removing the independence and making movement framerate dependent will not solve this. Faster frame rates will mean movement can occur too fast for a player to respond. Imagine watching a movie played back at 2x or 3x the speed and you know you won't be able to follow all of it. And slower frame rates will give an advantage to players who will have extra thinking time in which to react.

The only real solution to this issue is to ensure that the frame rate stays relatively high. This is why console manufacturers often dictate that they will not ship your game unless you can guarantee 30 frames per second at all times. That way there is a constant upper bound on the latency that the player has to deal with. In practice this is difficult but not at all impossible to achieve, and is the only real alternative given that linking rendering speed to simulation speed brings its own problems which are worse.

##### Share on other sites

Ok, so you're not really complaining about frame independent movement, you're complaining about slow input and output speeds, ie. the latency between the player seeing something and being able to act on it. The movement itself degrades perfectly well at low frame rates - it's the player's ability to respond to it that fails to degrade well.

exactly. there's nothing inherently wrong with frame independent movement. in fact is probably a better way to organize things. that way the simulation can run at the minimum speed necessary, thereby using the fewest possible clock cycles. and the graphics can run at the maximum speed possible, thereby providing the smoothest possible animation.  best of both worlds. smoothest possible animation, and lowest possible simulation overhead.  the only problem is long frame times when things get hot and heavy. i realize that proper graphics settings for resolution, clip range, scene complexity, etc can avoid this. but the user may not have things dialed down low enough for worst case scenarios. and it also may force them to run at lower graphics quality all the time just to avoid the occasional long frame time.

in my current main project right now, i track frame times and have "automatic clip ranges on/off". this automatically adjusts the clip range as the frame time changes. so it draws stuff out as far as possible while maintaining a given fps.   something like this might help, but unfortunately, its reactive, not proactive, so it would still let one long frame time slip through before adjusting.

The only real solution to this issue is to ensure that the frame rate stays relatively high. This is why console manufacturers often dictate that they will not ship your game unless you can guarantee 30 frames per second at all times. That way there is a constant upper bound on the latency that the player has to deal with. In practice this is difficult but not at all impossible to achieve, and is the only real alternative given that linking rendering speed to simulation speed brings its own problems which are worse.

yes, i see no way to avoid the two loops coming "unglued" as i call it, unless one can guarantee no long frame times.  about the only other solution would be to slow the simulation down.  like a governor driven by frame time. max speed sim can run at is a function of frame time. that would fix it, i think. if frame time went large, sim steps automatically get smaller, so the speed at which the sim runs and the speed at which the player can respond (due to slow graphics), doesn't get totally out of whack. when frame times were small (the normal case) the simulation would run at normal speed.

1. 1
2. 2
3. 3
Rutin
22
4. 4
5. 5

• 13
• 19
• 14
• 9
• 9
• ### Forum Statistics

• Total Topics
632935
• Total Posts
3009304
• ### Who's Online (See full list)

There are no registered users currently online

×