frame independent movement and slowdowns

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

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.

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

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.

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

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.

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.

I plan to post an article on the handling of input in a stable manner for fixed-frame-rate games even in high-latency situations soon.

While, of course, the player can never react to something he or she cannot see, if you handle input in such a way that, even if there is a sudden spike in the frame-rate, if the player hits buttons during the lag the end result would be the same as if it had been perfectly smooth the whole time.

This basically facilitates the player’s mental simulation during the laggy period and it is absolutely necessary for smooth “responsive” input, not even just during times of lag but throughout the game. If your input handler is able to allow the player to hit buttons through the lag and end up with the correct result as if the lag had never been there, the player at least has a chance of not dying etc. based on his or her mentally queued commands (we all think ahead and time our jumps, dodges, etc.—small bouts of lag interfere with this by surprising us, but we can still time our jumps etc. for a short while even if we can’t see what is happening).

My article will explain this in detail and it will state close to the start that inputs are not events.
A naïve implementation simply takes the input events from the OS and immediately applies some action to the game or player. The popular misconception that inputs are events stems from application programming, which is indeed event-based and the most common event is input.

The article will go into detail on this but I will explain the overall system briefly here.

Firstly, you do need to catch inputs as they are given to you by the OS, which means by listening to events. That is as far as events go in an input structure.
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.

The caught input is time-stamped and put into a buffer to be processed by the logical loop (remember, in a fixed time-step the logic is not updated every frame, as apposed to the rendering, and although they happen in the same game loop, we call them the logical loop and render loop—don’t be confused in thinking that they are 2 separate loops running). The time-stamp was synchronized with your logical loop’s timer at the beginning of the game.

For each logical update, request from the input buffer only the amount of input up to the current logical game time.
If you lag for 300 milliseconds and update logic only every 30 milliseconds, when you stop lagging you will basically do 10 logical updates before continuing with the next render.
There are 2 naïve implementations you could accidentally do here:
#1: Pure event-based input. As you get events, you immediately modify the player’s state, sometimes overwriting previous states from previous keystrokes. In this case, after 300 milliseconds, the first logical update (out of 10) will just react based off the last state it sees, ignoring any keypresses that came before and got overwritten. This is obviously wrong.
#2: Buffered input, but consuming the whole buffer on each logical update. The result is exactly the same as #1 in the end.

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.


As each logical update consumes and processes only the inputs that actually took place at that time during the game simulation, the simulation itself remains stable and faithful to what the player had intended.

The player sees a barrel coming and mentally times his or her jump. Suddenly 1 second of lag.
The player is surprised but had already figured out to hit the button after 0.5 seconds.
0.5 seconds into the lag the player sticks to the plan and waits another 0.5 seconds to see the result.
And, success! The player is impressed with your input mechanism and goes to your site to donate $10,000. If only you had added a “Donate” button.


L. Spiro

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.

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.

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! .

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).

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.

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.

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.