• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Norman Barrows

frame independent movement and slowdowns

14 posts in this topic

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?

 

 

 

 

0

Share this post


Link to post
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

0

Share this post


Link to post
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. 

0

Share this post


Link to post
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

0

Share this post


Link to post
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.

0

Share this post


Link to post
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

0

Share this post


Link to post
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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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
0

Share this post


Link to post
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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0