[nightowl_games]

Game dev here. Hardly any serious game developer uses lerp like that. I prefer a quadratic friction when I write custom friction, ie: a constant force away from velocity, and simply ensure it doesn't go past the zero point. More controllable. Box2Ds friction uses something like v = v * 1/(1+damping*delta_time), which is a good method as well.

Keep in mind it's best practice to run your game logic at a constant update rate and render an interpolated state between the current and previous game logic frame, meaning that if your game logic is frame rate dependent, you can still run it smoothly on any monitor.

[stephc_int13]

Constant update rate is a must, and can even be tweaked to minimize input latency if you are using a custom engine.

Using two frames to interpolate at render time is adding one frame of latency.

It is possible to do it on a single frame, extrapolating instead of interpolating, but you have to use a simple but uncommon trick to make it robust.

The latency gain is not a full frame but some sizeable fraction of a frame, I think it is worth it for some games.

[bschwindHN]

What is the simple but uncommon trick?

[bavell]

Some sort of Kalman-esque algo?

https://en.wikipedia.org/wiki/Kalman_filter

[nightowl_games]

> I think it is worth it for some games.

What types of games are you thinking?

Extrapolation isnt worth the chance of misprediction if it's a player movement based game.

The 'input latency' introduced by interpolating between frames is far different than typical 'input latency'. It's less than a single frame, and the game still renders movement at the same frame, just less movement. Most 'input latency' tests only test for _any_ movement, so those kinds of tests would detect 0 difference between 'interpolation', 'extrapolation' and 'render the exact game state'.

I'm a fast paced gamer, and I make fast paced games, I've never once 'felt' the input latency from interpolating the players position between simulation frames.

[05]

> run your game logic at a constant update rate and render an interpolated state between the current and previous game logic frame

But if graphics frame rate is higher you won’t be able to interpolate until the next logic frame is ready, - wouldn’t that increase latency?

[nightowl_games]

Technically, 'yes', but with huge caveats. You will still show player movement at the same 'latency', just _less than a full simulation frames worth_.

The benefits _far_ outweigh the costs of the other options. Games look _horrible_ if you render the physics at a different frame rate than the rest of the game. Like, horridly bad.

[marcosdumay]

It will keep latency constant, at right the amount you tested the game with.