Why does stuttering occur in Pong demo?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By confused

Have a look at the chronic stuttering in the Pong Template demo. Anyone know why it occurs?

https://streamable.com/6btrm

Sorry, can’t see/find how to inline the video. It’s very short, a few seconds.

:bust_in_silhouette: Reply From: kubecz3k

My best bet is it’s because of the lack of interpolation between physic thread and rendering thread. More here: Sprites jitter/jump when moving in _fixed_process() · Issue #10388 · godotengine/godot · GitHub

That causes more concerns. Is there no way to get silky smooth, reliable, simple motion in Godot?

confused | 2018-03-12 15:49

If that’s indeed root of your problem then at current moment I suppose you can achieve fluent motion by not using physics at all and move your body inside ‘idle’ (regular) thread… This issue however should be fixed quite soon (in 3.1) in which we are expecting to have physic step interpolation.

kubecz3k | 2018-03-12 15:55

No. Definitely need motion to be done and handled by physics. Unfortunately.

Has anyone at Godot HQ considered using Chipmunk2D for Godot’s 2D physics needs? It could solve all of this, and more, and has a (somewhat) similar API.

confused | 2018-03-12 15:58

Well the interpolation code is quite simple to write (maybe not trivial but for sure it will be quite short piece of code). And it will be more simple task than integrating another physic engine and integrating it in a way that would be transparent for current engine users. Not mentioning the same issue need to be solved for 3D as well.

kubecz3k | 2018-03-12 16:01

I’m not sure I fully understand why this problem occurs. Or how it got to be there. Never seen this sort of stuttering before with delta time adjusted physics motions.

confused | 2018-03-12 16:04

The problem is a result of the fact that there are two distinct threads working simultaneously. And Physics is calculated in different thread than rendering. Many engines are calculating all the logic inside single thread so in a result engine is slower for physic extensive games.
For other more professional engines like Unity/Unreal i believe they are designed in the same way as Godot - but they have that interpolation step implemented
What this interpolation is responsible for you might ask?
It’s basically responsible for smoothing the movement… imagine (just an example) you are calculating physics movement only once per second, so the bodies would move in a really chunky way with huge discrete transitions once per second. But even in such environment you could write a code that would take previous body position and current position and render this movement in a very fluent way (assuming you know that physics is calculated once per second and how much time has passed since last physic calculation, and that this ‘smoothing code’ is working in normal 60fps intervals). This is exactly what physic step interpolation is doing.
For more accurate description and informations please check this source:
Fixed-Time-Step Implementation | L. Spiro Engine
(or alternatively that one: Fix Your Timestep! | Gaffer On Games)

kubecz3k | 2018-03-12 16:16

That… plus I’m wondering how it wasn’t found earlier, and fixed earlier. This is a showstopper for even the most basic of ball based physics games.

confused | 2018-03-12 16:25