# Fixing the iterative damping interpolation in video games

DevFeed: [Fixing the iterative damping interpolation in video games](<https://devfeed.tech/articles/fixing-the-iterative-damping-interpolation-in-video-games-26115.md>)

Original publisher: [Read original article](<http://blog.pkh.me/p/41-fixing-the-iterative-damping-interpolation-in-video-games.html>)

Published: 2024-05-18T12:22:15Z

Content type: article

Language: en

Sources: [The Last Static Blog RSS](<https://devfeed.tech/sources/the-last-static-blog-rss.md>)

Topics: [Game Development](<https://devfeed.tech/topics/game-development.md>), [Godot](<https://devfeed.tech/topics/godot.md>), [callback](<https://devfeed.tech/topics/callback.md>), [function](<https://devfeed.tech/topics/function.md>), [Mathematics](<https://devfeed.tech/topics/mathematics.md>)

Tags: [callback](<https://devfeed.tech/tags/callback.md>), [fps](<https://devfeed.tech/tags/fps.md>), [game](<https://devfeed.tech/tags/game.md>), [game-development](<https://devfeed.tech/tags/game-development.md>), [games](<https://devfeed.tech/tags/games.md>), [math](<https://devfeed.tech/tags/math.md>), [physics](<https://devfeed.tech/tags/physics.md>), [prog](<https://devfeed.tech/tags/prog.md>)

## AI overview

This article explains why repeatedly applying linear interpolation for damping can make game behavior depend on the refresh rate. Using Godot examples, it analyzes the iterative formula and motivates a frame-rate-independent solution.

## Source excerpt

As I'm exploring the fantastic world of indie game development lately, I end up watching a large number of video tutorials on the subject. Even though the quality of the content is pretty variable, I'm very grateful to the creators for it. That being said, I couldn't help noticing this particular bit times and times again: a = lerp(a, B, delta * RATE) Behind this apparent banal call hides a terrible curse, forever perpetrated by innocent souls on the Internet. In this article we will study what it's trying to achieve, how it works, why it's wrong, and then we'll come up with a good solution to the initial problem. The usual warning: I don't have a mathematics or academic background, so the article is addressed at other neanderthals like myself, who managed to understand that pressing keys on a keyboard make pixels turn on and off. What is it? Let's start from the beginning. We're in a game engine main loop callback called at a regular interval (roughly), passing down the time difference from the last call. In Godot engine, it looks like this: func _physics_process(delta: float): ... If the game is configured to refresh at 60 FPS, we can expect this function to be called around 60 times per second with delta = 1/60 = 0.01666.... As a game developer, we want some smooth animations for all kind of transformations. For example, we may want the speed of the player to go down to zero as they release the moving key. We could do that linearly, but to make the stop less brutal and robotic we want to slow down the speed progressively. Linear (top) versus smooth/exponential (bottom) animation Virtually every tutorial will suggest updating some random variable with something like that: velocity = lerp(velocity, 0, delta * RATE) At 60 FPS, a decay RATE defined to 3.5, and an initial velocity of 100, the velocity will go down to 0 following this curve: Example curve of a decaying variable Note velocity is just a variable name example, it can be found in many other contexts If you