# frame independent movement and slowdowns

This topic is 1756 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.

##### Share on other sites

The thread that listens for inputs from the OS is its own thread.  For Windows, this has to be the main thread—the thread that created the window.  That means keep your game and render thread(s) off it.  You can’t catch inputs accurately if the thread that listens for inputs is busy drawing a monster or colliding objects together.

but don't some parts of directx have to be on the main thread too? i could have sworn i saw something like that somewhere. I haven't had to go mutlithread for speed yet myself, so i'm not sure.

##### Share on other sites

The correct solution is to only consume from the input buffer as many input events as took place during the logical-update period.
That is, since our logical update is 30 milliseconds, you consume only the next 30 millisecond’s worth of events from the buffered input, leaving later inputs in the buffer for the next logical updates to consume.

thereby keeping input and simulation in sync. clever.

the only thing you don't get is the visual feedback between sim steps, like you normally would without long frame times.

now if there was only a way to fix that....

if that last bit could be fixed, you would have the lowest possible overhead simulation, smoothest possible animation, a simulation that didn't get "ahead" of its input, and visual feedback every sim turn, irregardless of frame time. best of all worlds.

the obvious first thing would be to not let the sim run more that one turn between drawing frames when frame times were long.

but your frame times are already long, and now you're drawing a frame after every sim turn. so the number of sim turns queued up waiting to be processed would probably just keep growing, until the frame times dropped back down and it would eventually catch up.

but this is probably ok. for the following reason:

about the only way to get that screen update every sim turn when the frame time is high, is to SLOW DOWN TIME. you slow down everything (well, the sim, but probably not the input checker) to whatever the speed of the slowest component is (the graphics). sort of slipping into "bullet time" as it were. everything moves slow, except the player, who can still react to the slowly changing scene at his/her normal speeds. as the frame time drops back to normal, the simulation speeds back up.

so it may be possible to have the best of all worlds, if you have the game slowdown towards "bullet time" when frame times get long.

suddenly slowing down would probably be ok. the only other option would be to slow down the simulation gradually, which would allow it to get ahead of the graphics feedback to the player. but suddenly speeding up again might be a problem. one could always cap the rate of speed increase to some playable value.

so if slipping into "bullet time" is an acceptable solution for slowdowns, one can have the best of all worlds. having your cake and eating it too, very WITH my religion! <g>.

this means you wouldn't have to limit the game so much based on how many characters you can draw onscreen at once (unless you're developing for a console and they have a problem with the "bullet time" solution). Edited by Norman Barrows

##### Share on other sites

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.

Sure, and this is how many games used to play, but:

1. It's useless for multiplayer, since everybody has to be running the simulation at the same speed
2. Who decides when the sim should start to slow down? I used to enjoy playing Doom at 15fps, and wouldn't have enjoyed it if you'd made it run at half-speed in order to give me the same reaction times as a 30Hz game.

I don't think this really works because acceptable reaction times and latency are subjective.

##### Share on other sites

The thread that listens for inputs from the OS is its own thread.  For Windows, this has to be the main thread—the thread that created the window.  That means keep your game and render thread(s) off it.  You can’t catch inputs accurately if the thread that listens for inputs is busy drawing a monster or colliding objects together.

but don't some parts of directx have to be on the main thread too? i could have sworn i saw something like that somewhere. I haven't had to go mutlithread for speed yet myself, so i'm not sure.

They have to be on the same thread but that need not be the main thread.

##### Share on other sites

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.

Sure, and this is how many games used to play, but:
• It's useless for multiplayer, since everybody has to be running the simulation at the same speed
• Who decides when the sim should start to slow down? I used to enjoy playing Doom at 15fps, and wouldn't have enjoyed it if you'd made it run at half-speed in order to give me the same reaction times as a 30Hz game.
I don't think this really works because acceptable reaction times and latency are subjective.

well, i'm primarily thinking single player here. the problem is protracted enough without adding multiplayer sync and lag to the equation. but you're right, bullet time probably wouldn't work well for multiplayer. in the case of multiplayer, there are likely sufficient temporary inaccuracies from lack of lockstep sync that trying to fix frame independant movement and long frame times is probably overkill.

but for single player, actually, it could be optional. either drop frames or go bullet time, player's choice. and the player could configure the FPS at which it started to slide into bullet time.

thats would allow them to tailor the "low end" behavior to their liking, while retaining all the "high end" performance advantages of decoupling the render, simulate, and getinput stages, IE the 3 basic parts of a game loop: draw, get input, move everything.

so you'd decouple render, getinput, and simulate. if bullet time slowdown was enabled, when render slows down to the user specified speed (FPS), you re-couple them (well, maybe just render and simulate). when render speeds back up, you gradually decouple them again. Edited by Norman Barrows