Jump to content
  • Advertisement
Sign in to follow this  
Lewa

Locked Update, unlocked Framerate - interpolation latency

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I realise that this is one of those questions that gets asked multiple times a day, but after extensive research i wasn't able to answer one specific question (which i will get to.)

(And yes, i've also read the "Fix Your Timestep" article.)

So what i wanted to implement was a fixed update tickrate (like 60FPS) with the ability to unlock the rendering framerate to render the game as fast (and as smooth as possible.)

The "easiest" approach would be to use a variable timestep (delta time) but i don't want to do that. Mainly due to consistency of the game physics/behaviour across multiple playthroughs.

 

So from what i was able to gather, there are two ways in implementing a gameloop with a fixed tickrate and an unlocked (variable) framerate:

> Interpolation and Extrapolation.

Extrapolation is basically a "prediction" of the gamestate in the next frame (which wasn't calculated yet on the CPU side.) So you do something like position + velocity * interpolationvalue during rendering. This may work, the issue is that the extrapolation can have wrong results (objects passing through geometry for a short timespan) before the position is corrected. Also movement which is non-linear like rotation, acceleration, etc... would also have wrong results.

 

The other things is interpolation. I like the idea of the approach. We take the last frame and the current frame and interpolate between them while the next game update is being processed resulting in smooth motion and it allows us to render the game at a higher framerate.

Now the caveat here is latency. Because you interpolate between the last frame and the current frame, your game state is (visually) always 1 frame behind.

This essentially increases the latency/responsiveness of the game. (At 30 fps its 33.33ms, at 60 FPS its 16.66ms)

In my opinion this depends entirely on the gametype if this latency is acceptable or not. RPGs might get away with it, but fast paced games with emphasis on fast/reactive gameplay can suffer. And given that i'm working on a game which emphasizes fast/reaction based gameplay, this is an issue which i want to circumvent. (Currently i update at a fixed rate of 60 FPS.)

 

So my question is:

How do games with the requirement of consistent physics/behaviour implement their gameloop while retaining the ability to render at an unlocked framerate?

Competetive games come to my mind. But especially the Trackmania Series.

AFAIK Trackmania has consistent physics (Otherwise all those "press forward and let the car magically drive through the whole track" maps wouldn't be possible) . But it's also able to render at an unlocked framerate. 

Here is a video where someone did a benchmark and was able to run the game at 200-400 FPS:

[media]https:

[/media]

My question is: How is that possible? Trackmania is a fast paced racer which needs low-latency input (I can't imagine that they are sacrificing substantial latency for framerate independence). Are they using interpolation at all? How is their gameloop implemented?

 

The only solution i'm able to come up with with regards to interpolation is making the game update at a very high (fixed) rate (like 200 ticks per second.) in order to reduce the latency as much as possible.

Edited by Lewa

Share this post


Link to post
Share on other sites
Advertisement

A good 3D game engine separates physics and rendering into different threads. You will run physics at fixed steps, but you will interpolate graphics between steps.

Share this post


Link to post
Share on other sites

It doesn't particularly need to be a separate thread, but certainly they are independent of each other.

 

On a non-threaded engine you can call any number of updates needed to catch up (usually with an extra guard to not update longer than a specific amount of time for being stopped in debuggers and prevent the slow spiral of death), then render when all the updates are run.

 

The rest is correct, many systems are best run at specific regular intervals even if it doesn't match the wall clock time. Nothing inherently wrong with telling your physics system to update in 5ms intervals or whatever works for you, while rendering takes place every graphics frame or about 16ms.

Share this post


Link to post
Share on other sites

The other things is interpolation. I like the idea of the approach. We take the last frame and the current frame and interpolate between them while the next game update is being processed resulting in smooth motion and it allows us to render the game at a higher framerate.
Now the caveat here is latency. Because you interpolate between the last frame and the current frame, your game state is (visually) always 1 frame behind.
This essentially increases the latency/responsiveness of the game. (At 30 fps its 33.33ms, at 60 FPS its 16.66ms)
In my opinion this depends entirely on the gametype if this latency is acceptable or not. RPGs might get away with it, but fast paced games with emphasis on fast/reactive gameplay can suffer. And given that i'm working on a game which emphasizes fast/reaction based gameplay, this is an issue which i want to circumvent. (Currently i update at a fixed rate of 60 FPS.)


You're correct on all accounts, however you forget the physics is still updated very fast with no lag.
To put it in another way, play a game blindfolded, with only sound cues or playing by memory; and you'll still be able to react and the physics engine will process your input immediately.
Because the visuals are only 1 frame behind at 60fps, it's not that big of a deal (it is, but it's not the end of the world. Now if the framerate is lower...).

Another issue you're forgetting is that the distance between physics & graphics may not be an exact frame (because it depends on graphics' framerate). The visual may be up to 1 frame behind. But they may be less (i.e. 0.5 frame behind, 0.2, 0.1).

If both graphics & physics are updating at exact multiples then you may end up being 1 frame behind.

You can also try to disable triple buffer to compensate.

Share this post


Link to post
Share on other sites

The rest is correct, many systems are best run at specific regular intervals even if it doesn't match the wall clock time. Nothing inherently wrong with telling your physics system to update in 5ms intervals or whatever works for you, while rendering takes place every graphics frame or about 16ms.

So is this a common thing in todays games?

Running the simulation at 100+ ticks on the CPU and interpolating between the old- and current gamestate for smooth unlocked rendering?

What about the introduced latency? (by being always one frame behind?)

 

Trackmanias implementation interested me as they have the same requirements as i do (consistency in the physics) but they manage to unlock the rendering framerate as well. (I suppose without introducing latency?)

I wasn't able to find anything about their implementation on the internet though.

 

I have the same requirements. > Consistency in the physics but i would also like to have an unlocked framerate (without introducing additional latency due to the interpolation technique.)

Share this post


Link to post
Share on other sites
This may come as a shock, but most modern games have even more input latency than you think, often around 100 ms (i.e. roughly 6 frames at 60 fps) owing to several factors including interpolation delay and swap chain length. Even fighting games, which generally have very precise, sometimes frame-specific timing mechanics, typically have at least 70 ms of latency.

Share this post


Link to post
Share on other sites

Thr visual latency added is one fixed frame, so 17ms for 60Hz physics. You can always just increase your physics rate :D I'm currently running my racing physics at 600Hz, so <2ms of added interpolation latency.

FWIW though, an extra 17ms latency is pretty common in games. The best input -> photon latency you'll see is around 50ms and sometimes it's as high as 100ms.

You can always provide the user with options to reduce their input latency if that's their preference:

  • Extrapolation of gamestate can produce glitchy renderings from time to time, but is low latency, while interpolation (when done correctly) produces silky smooth visuals, but adds one simulation frame's worth of latency.
  • Polling inputs in a background thread and timestamping them allows for more accurate capture of input rhythm (relative delay between different inputs), but polling inputs directly inside your fixed update loop provides the lowest input latency at the expense of preserving rhythm.
  • Or, enabling triple buffering soaks up inconsistencies in GPU frame times for a smoother frame rate, but adds a lot of latency, while single-buffering completely destroys GPU throughput (almost halving framerates!) but provides the absolute lowest latency (and double-buffering is a middle ground - giving good performance, slightly less ability to smooth out framerates, and only one extra visual frame of latency).

Share this post


Link to post
Share on other sites

The other things is interpolation. I like the idea of the approach. We take the last frame and the current frame and interpolate between them while the next game update is being processed resulting in smooth motion and it allows us to render the game at a higher framerate.
Now the caveat here is latency. Because you interpolate between the last frame and the current frame, your game state is (visually) always 1 frame behind.

 
Well, no, if you're interpolating you're somewhere between 0 and 1 'simulation' or 'physics' frame behind. And if your simulation frames are frequent that will be a tiny amount. Given that human reaction times are typically well over a hundred milliseconds, if not two hundred, this extra difference is mostly meaningless in terms of its effect on input.

Share this post


Link to post
Share on other sites

The other things is interpolation. I like the idea of the approach. We take the last frame and the current frame and interpolate between. Your game state is (visually) always 1 frame behind.

Well, no, if you're interpolating you're somewhere between 0 and 1 'simulation' or 'physics' frame behind.
Both are true depending on where you're measuring from.
It's a blend of the latest and previous sim results using a (0,1] fraction... But it's always exactly 1 sim timestep behind the real world clock, because the real world clock is always [0,1) time-steps ahead of the simulation.
You only get a blend of 99% current / 1% previous when the real world clock has advanced 99% of the way to the next timestep occuring, meaning that the "current" sim results are 99% out of date.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!