Fixing jitter, stutter and input lag

What is jitter, stutter and input lag?

Zittern und Stottern sind zwei verschiedene Änderungen der sichtbaren Bewegung von Objekten auf dem Bildschirm, die sich auf ein Spiel auswirken können, selbst wenn sie mit voller Geschwindigkeit laufen. Diese Effekte sind vor allem in Spielen sichtbar, in denen sich die Welt mit konstanter Geschwindigkeit in eine feste Richtung bewegt, wie Laufspiele oder Plattformer.

Input lag is unrelated to jitter and stutter, but is sometimes discussed alongside. Input lag refers to visible on-screen delay when performing actions with the mouse, keyboard, controller or touchscreen. It can be related to game code, engine code or external factors (such as hardware). Input lag is most noticeable in games that use the mouse to aim, such as first-person games. Input lag can't be completely eliminated, but it can be reduced in several ways.

Distinguishing between jitter and stutter

Ein Spiel, das mit einer normalen Framerate läuft, ohne einen Effekt zu zeigen, erscheint flüssig:

../../_images/motion_normal.gif

Ein Spiel mit zittern wird sich ständig auf sehr subtile Weise minimal bewegen:

../../_images/motion_jitter.gif

Schließlich erscheint ein Spiel mit stottern flüssig, scheint jedoch alle paar Sekunden anzuhalten oder einen Frame zurückzusetzen:

../../_images/motion_stutter.gif

Zittern

Es kann viele Ursachen für zittern geben. Die typischste tritt auf, wenn die Physikfrequenz des Spiels (normalerweise 60 Hz) mit einer anderen Auflösung als die Monitor-Aktualisierungsrate läuft. Überprüfen Sie, ob die Aktualisierungsrate Ihres Monitors eine andere als 60 Hz ist.

Das ist normalerweise kein Problem, da die meisten Monitore 60Hz unterstützen und Godot ab Version 3.1 einen Timer besitzt, der so gut es geht einen Refresh zu synchronisieren versucht .

Sometimes only some objects appear to jitter (character or background). This happens when they are processed in different time sources (one is processed in the physics step while another is processed in the idle step). Godot 3.1 does some improvements to this, from allowing kinematic bodies to be animated in the regular _process() loop, to further fixes in the frame timer.

Bemerkung

In 3D, you can use physics interpolation to mitigate physics-related jittering.

For 2D, see lawnjelly's smoothing-addon for an add-on that can be dropped into any project to enable physics interpolation.

Stottern

Stottern kann aus zwei verschiedenen Gründen auftreten. Das erste und offensichtlichste ist, dass das Spiel nicht in der Lage ist, die volle Framerate-Leistung aufrechtzuerhalten. Die Lösung hierfür ist abhängig vom Spiel und erfordert eine Optimierung.

Die zweite ist komplizierter, da sie häufig nicht der Engine oder dem Spiel, sondern dem zugrunde liegenden Betriebssystem zugeordnet ist. Hier finden Sie einige Informationen zum Stottern auf verschiedenen Betriebssystemen.

On platforms that support disabling V-Sync, suttering can be made less noticeable by disabling V-Sync in the project settings. This will however cause tearing to appear, especially on monitors with low refresh rates. If your monitor supports it, consider enabling variable refresh rate (G-Sync/FreeSync) while leaving V-Sync enabled. This avoids mitigating some forms of stuttering without introducing tearing.

Forcing your graphics card to use the maximum performance profile can also help reduce stuttering, at the cost of increased GPU power draw.

Windows

Es ist bekannt, dass Windows beim spielen im Fenstermodus Stottern verursacht. Dies hängt hauptsächlich von der installierten Hardware, der Treiberversion und den parallel ausgeführten Prozessen ab (z.B. kann das Öffnen vieler Browser-Registerkarten in einem laufenden Spiel zu Ruckeln führen). Um dies zu vermeiden erhöht Godot ab 3.1 die Spielpriorität auf "Über Normal". Dies hilft erheblich, kann jedoch das Stottern nicht vollständig beseitigen.

Um dies vollständig zu beseitigen, müssen Sie Ihrem Spiel die vollen Berechtigungen geben, um "zeitkritisch" zu werden, was nicht empfohlen wird. Einige Spiele können dies tun, es wird jedoch empfohlen mit diesem Problem zu leben, da dies bei Windows-Spielen üblich ist und die meisten Benutzer keine Spiele im Fenstermodus spielen (Spiele, die in einem Fenster gespielt werden, z.B. Puzzlespiele, zeigen normalerweise nicht dieses Problem).

Für den Vollbildmodus legt Windows besonderen Wert auf das Spiel, sodass Stottern nicht mehr sichtbar und sehr selten ist. So werden die meisten Spiele gespielt.

Linux

Stutter may be visible on desktop Linux, but this is usually associated with different video drivers and compositors. Some compositors may also trigger this problem (e.g. KWin), so it is advised to try using a different one to rule it out as the cause. Some window managers such as KWin and Xfwm allow you to manually disable compositing, which can improve performance (at the cost of tearing).

There is no workaround for driver or compositor stuttering, other than reporting it as an issue to the driver or compositor developers.

Feral GameMode can be used to automatically apply optimizations (such as forcing the GPU performance profile) when running specific processes.

macOS

Im Allgemeinen ist MacOS ruckelfrei, obwohl kürzlich einige Fehler beim Ausführen im Vollbildmodus gemeldet wurden (dies ist ein MacOS-Fehler). Wenn Sie eine Maschine haben die dieses Verhalten zeigt, teilen Sie uns dies bitte mit.

Android

Im Allgemeinen ist Android frei von stottern und zittern, da die laufende Aktivität Vorrang hat. Es kann jedoch problematische Geräte geben (z.B. ältere Kindle Fire). Wenn Sie dieses Problem auf Android sehen, lassen Sie es uns bitte wissen.

iOS

iOS-Geräte sind im Allgemeinen ruckelfrei, ältere Geräte auf denen neuere Versionen des Betriebssystems ausgeführt werden, können jedoch Probleme aufweisen. Dies ist in der Regel unvermeidlich.

Input lag

Project configuration

On platforms that support disabling V-Sync, input lag can be made less noticeable by disabling V-Sync in the project settings. This will however cause tearing to appear, especially on monitors with low refresh rates.

Increasing the number of physics iterations per second can also reduce physics-induced input latency. This is especially noticeable when using physics interpolation (which improves smoothness but increases latency). To do so, set Physics > Common > Physics FPS to a value higher than the default 60, or set Engine.physics_fps at run-time in a script. Values that are a multiple of the monitor refresh rate (typically 60) work best when physics interpolation is disabled, as they will avoid jitter. This means values such as 120, 180 and 240 are good starting points. As a bonus, higher physics FPSes make tunneling and physics unstability issues less likely to occur.

The downside of increasing physics FPS is that CPU usage will increase, which can lead to performance bottlenecks in games that have heavy physics simulation code. This can be alleviated by increasing physics FPS only in situations where low latency is critical, or by letting players adjust physics FPS to match their hardware. However, different physics FPS will lead to different outcomes in physics simulation, even when delta is consistently used in your game logic. This can give certain players an advantage over others. Therefore, allowing the player to change the physics FPS themselves should be avoided for competitive multiplayer games.

Lastly, you can disable input buffering on a per-rendered frame basis by calling Input.set_use_accumulated_input(false) in a script. This will make it so the _input() and _unhandled_input() functions in your scripts are called on every input, rather than accumulating inputs and waiting for a frame to be rendered. Disabling input accumulation will increase CPU usage, so it should be done with caution.

Hardware/OS-specific

If your monitor supports it, consider enabling variable refresh rate (G-Sync/FreeSync) while leaving V-Sync enabled, then cap the framerate in the project settings to a slightly lower value than your monitor's maximum refresh rate as per this page. For example, on a 144 Hz monitor, you can set the project's framerate cap to 141. This may be counterintuitive at first, but capping the FPS below the maximum refresh rate range ensures that the OS never has to wait for vertical blanking to finish. This leads to similar input lag as V-Sync disabled with the same framerate cap (usually less than 1 ms greater), but without any tearing.

This can be done by changing the Debug > Settings > FPS > Force FPS project setting or assigning Engine.target_fps at run-time in a script.

On some platforms, you can also opt into a low-latency mode in the graphics driver options (such as the NVIDIA Control Panel on Windows). The Ultra setting will give you the lowest possible latency, at the cost of slightly lower average framerates. Forcing the GPU to use the maximum performance profile can also further reduce input lag, at the cost of higher power consumption (and resulting heat/fan noise).

Finally, make sure your monitor is running at its highest possible refresh rate in the OS' display settings.

Also, ensure that your mouse is configured to use its highest polling rate (typically 1,000 Hz for gaming mice, sometimes more). High USB polling rates can however result in high CPU usage, so 500 Hz may be a safer bet on low-end CPUs. If your mouse offers multiple DPI settings, consider also using the highest possible setting and reducing in-game sensitivity to reduce mouse latency.

On Linux, disabling compositing in window managers that allow it (such as KWin or Xfwm) can reduce input lag significantly.

Reporting jitter, stutter or input lag problems

Wenn Sie ein Stottern oder Zittern melden (ein Problem eröffnen), das nicht aus einem der oben genannten Gründe verursacht wurde, geben Sie bitte alle möglichen Informationen zu Gerät, Betriebssystem, Treiberversionen usw. sehr detailliert an. Dies kann zur besseren Fehlerbehebung beitragen.

If you are reporting input lag problems, please include a capture made with a high speed camera (such as your phone's slow motion video mode). The capture must have both the screen and the input device visible so that the number of frames between an input and the on-screen result can can be counted. Also, make sure to mention your monitor's refresh rate and your input device's polling rate (especially for mice).

Also, make sure to use the correct term (jitter, stutter, input lag) based on the exhibited behavior. This will help understand your issue much faster. Provide a project that can be used to reproduce the issue, and if possible, include a screen capture demonstrating the bug.