Sign in to follow this  
Lewa

Locked Update, unlocked Framerate - interpolation latency

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://www.youtube.com/watch?v=Jk_N09Z4YXE[/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

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

Glad to hear that this solution isn't that uncommon. :)

I'm currently running my racing physics at 600Hz, so <2ms of added interpolation latency.

 

That's a lot. o.O

I'm curios now: what are the "common" tickrates used for games? (I know that this will depend heavily on the genre and gametype and has to be determined individually for each game.)

Given that the this approach requires the CPU to be fast enough in order to process X amount of ticks per second (otherwise we would have a CPU bottleneck and the game would slow down) you need to make sure that every operation (physics, collission detection, AI, etc...) can be crammed into 1/600 of a second in order to run properly (at the desired speed), am i right? (Such a high tickrate wouldn't cope well with open world games which have way to much random variables influencing the load on the CPU?)

Edited by Lewa

Share this post


Link to post
Share on other sites
Yeah, tickrates that high are not common.
I would guess that 30 or 60 would be common just because they're going to be close to the render rate...
I've seen RTS games go extremely low, such as 10, and simulations go as high as 1000. I've also seen FPS go as low as 20, but also sort player actions by timestamp to achieve better than the 50ms temporal resolution that it should give you.
You can also use multiple tickrates for each system. In another iteration of my racing game, I ticked physics at 60Hz, but the tyre/road interactions at 720Hz (which is an integer multiple, so no need to interpolate between the two systems), as they're one part that really needs accurate integration.

Share this post


Link to post
Share on other sites

If your tickrate is 60fps then you don't even need interpolation on most monitors. Just present the latest state of your simulation on each vsync, bingo. You can use interpolation to support higher refresh rates, and then being one frame behind at 120hz and up really isn't a big deal.

Share this post


Link to post
Share on other sites

It's worth remembering that a 600Hz update doesn't necessarily have to be "for each object, update everything about it, and repeat 600 times in a second". It can be something more like, "put all your physics stuff in vectors, then perform 600 vectorised operations that each simulate 1/600th of a second". You might not be able to do that for the entirety of your updates, but perhaps for more of it than you think.

And obviously if one game can easily handle 100 actors at 60Hz, it makes sense that some other game can handle 10 actors at 600Hz. In fact the latter case is probably faster because there are fewer potential interactions to consider (and because the smaller amounts of data make it more cache friendly).

Share this post


Link to post
Share on other sites

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.

That is typical of racing games or any type of twitch input game with low logical-update overhead such as in fighting games.

As mentioned by Kylotan, LOD updates may be applied to nearby objects (skeletons on actors are typically updated less frequently as they get farther away, etc.)
What overall method you use depends on how you work several systems together based on the demands of the game.
The speed at which you set your update is a tradeoff between how much work an update needs to do, how twitch-responsive your game needs to be, and how much slight graphical artifacts bother you/your audience.


L. Spiro

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