Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

Behebung von Jitter, Stutter und Input-Lag

Was ist Jitter, Stutter und Input-Lag?

Jitter und Stutter 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 Runner oder Plattformer.

Der Input-Lag hat nichts mit Jitter und Stutter zu tun, wird aber manchmal zusammen mit ihnen diskutiert. Input-Lag bezieht sich auf die sichtbare Verzögerung auf dem Bildschirm bei der Ausführung von Aktionen mit der Maus, der Tastatur, dem Controller oder dem Touchscreen. Sie kann mit dem Spielcode, dem Enginecode oder externen Faktoren (wie der Hardware) zusammenhängen. Input-Lag macht sich vor allem in Spielen bemerkbar, bei denen die Maus zum Zielen verwendet wird, z.B. in Ego-Shootern. Input-Lag lässt sich zwar nicht vollständig beseitigen, aber auf verschiedene Weise reduzieren.

Unterscheidung zwischen Jitter und Stutter

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

Ein Spiel, das Jitter aufweist, wackelt ständig auf eine sehr subtile Weise:

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

Jitter

There can be many causes of jitter. The most typical one happens when the game physics frequency (usually 60 Hz) runs at a different resolution than the monitor refresh rate. Check whether your monitor refresh rate is different from 60 Hz.

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).

This cause of jitter can be alleviated by enabling physics interpolation in the Project Settings. Physics interpolation will smooth out physics updates by interpolating the transforms of physics objects between physics frames. This way, the visual representation of physics objects will always look smooth no matter the framerate and physics tick rate.

Enabling physics interpolation has some caveats you should be aware of. For example, care should be taken when teleporting objects so that they don't visibly interpolate between the old position and new position when it's not intended. See the Physics Interpolation documentation for details.

Bemerkung

Enabling physics interpolation will increase input lag for behavior that depends on the physics tick, such as player movement. In most games, this is generally preferable to jitter, but consider this carefully for games that operate on a fixed framerate (like fighting or rhythm games). This increase in input lag can be compensated by increasing the physics tick rate as described in the Input-Lag section.

Stutter

Stutter may happen due to several different reasons. One reason is the game not being able to keep full framerate performance due to a CPU or GPU bottleneck. Solving this is game-specific and will require optimization.

Another common reason for stuttering is shader compilation stutter. This occurs when a shader needs to be compiled when a new material or particle effect is spawned for the first time in a game. This kind of stuttering generally only happens on the first playthrough, or after a graphics driver update when the shader cache is invalidated.

Since Godot 4.4, when using the Forward+ or Mobile renderers, the engine tries to avoid shader compilation stutter using an ubershader approach. For this approach to be most effective, care must be taken when designing scenes and resources so that Godot can gather as much information as possible when the scene/resource is loaded, as opposed as to when it's being drawn for the first time. See Reducing stutter from shader (pipeline) compilations for more information.

However, when using the Compatibility renderer, it is not possible to use this ubershader approach due to technical limitations in OpenGL. Therefore, to avoid shader compilation stutter in the Compatibility renderer, you need to spawn every mesh and visual effect in front of the camera for a single frame when the level is loading. This will ensure the shader is compiled when the level is loaded, as opposed to occurring during gameplay. This can be done behind solid 2D UI (such as a fullscreen ColorRect node) so that it's not visible to the player.

Bemerkung

On platforms that support disabling V-Sync, stuttering 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 allows mitigating some forms of stuttering without introducing tearing. However, it will not help with large stutters, such as the ones caused by shader compilation stutter.

Wenn Sie Ihre Grafikkarte zwingen, das maximale Performance-Profil zu verwenden, kann dies auch dazu beitragen, das Stuttering zu verringern, allerdings auf Kosten eines höheren Energieverbrauchs der GPU.

Additionally, stutter may be induced by the underlying operating system. Here is some information regarding stutter on different OSes:

Windows

Windows is known to cause stutter in windowed games. This mostly depends on the hardware installed, drivers version and processes running in parallel (e.g. having many browser tabs open may cause stutter in a running game). To avoid this, Godot raises the game priority to "Above Normal". This helps considerably, but may not completely eliminate stutter.

Eliminating this completely requires giving your game full privileges to become "Time Critical", which is not advised. Some games may do it, but it is advised to learn to live with this problem, as it is common for Windows games and most users won't play games windowed (games that are played in a window, e.g. puzzle games, will usually not exhibit this problem anyway).

Für den Vollbildmodus gibt Windows dem Spiel besondere Priorität, sodass Stuttering nicht mehr sichtbar und sehr selten ist. Die meisten Spiele werden so gespielt.

When using a mouse with a polling rate of 1,000 Hz or more, consider using a fully up-to-date Windows 11 installation which comes with fixes related to high CPU utilization with high polling rate mice. These fixes are not available in Windows 10 and older versions.

Tipp

Spiele sollten den Fenstermodus Exclusives Vollbild verwenden, im Gegensatz zu Vollbild, der verhindern soll, dass Windows das Fenster automatisch so behandelt, als wäre es ein exklusiver Vollbildmodus.

Vollbild ist für GUI-Anwendungen gedacht, die Transparenz pro Pixel nutzen wollen, ohne Gefahr zu laufen, dass sie vom Betriebssystem deaktiviert wird. Dies wird erreicht, indem eine 1-Pixel-Linie am unteren Rand des Bildschirms belassen wird. Im Gegensatz dazu verwendet Exklusives Vollbild die tatsächliche Bildschirmgröße und ermöglicht es Windows, Jitter und Eingabeverzögerungen bei Spielen im Vollbildmodus zu reduzieren.

Linux

Stuttering kann unter Desktop-Linux sichtbar sein, aber das hängt in der Regel mit verschiedenen Videotreibern und Compositors zusammen. Einige Compositors können dieses Problem ebenfalls auslösen (z. B. KWin), so dass es ratsam ist, einen anderen Compositor zu verwenden, um ihn als Ursache auszuschließen. Bei einigen Fenstermanagern wie KWin und Xfwm können Sie das Compositing manuell deaktivieren, was die Performance verbessern kann (zum Preis von Tearing).

Es gibt keinen Workaround für Stuttering des Treibers oder des Compositors, es sei denn, Sie melden das Problem an die Entwickler des Treibers oder des Compositors. Das Stuttering kann bei der Wiedergabe im Fenstermodus stärker ausgeprägt sein als im Vollbildmodus, auch wenn das Compositing deaktiviert ist.

Feral GameMode kann verwendet werden, um automatisch Optimierungen (wie z.B. das Erzwingen des GPU-Performanceprofils) anzuwenden, wenn bestimmte Prozesse laufen.

macOS

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

Android

Im Allgemeinen ist Android frei von Stuttering und Jittering, da die laufende Aktivität immer 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 Stuttering-frei, ä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

Projektkonfiguration

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. It's suggested to make V-Sync available as an option for players to toggle.

When using the Forward+ or Mobile rendering methods, another way to reduce visual latency when V-Sync is enabled is to use double-buffered V-Sync instead of the default triple-buffered V-Sync. Since Godot 4.3, this can be achieved by reducing the Display > Window > V-Sync > Swapchain Image Count project setting to 2. The downside of using double buffering is that framerate will be less stable if the display refresh rate can't be reached due to a CPU or GPU bottleneck. For instance, on a 60 Hz display, if the framerate would normally drop to 55 FPS during gameplay with triple buffering, it will have to drop down to 30 FPS momentarily with double buffering (and then go back to 60 FPS when possible). As a result, double-buffered V-Sync is only recommended if you can consistently reach the display refresh rate on the target hardware.

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 Ticks Per Second to a value higher than the default 60, or set Engine.physics_ticks_per_second at runtime 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 instability issues less likely to occur.

Der Nachteil einer Erhöhung der Physik-FPS ist, dass die CPU-Auslastung steigt, was in Spielen mit umfangreichem Physiksimulationscode zu Performance-Engpässen führen kann. Dies kann dadurch gemildert werden, dass die Physik-FPS nur in Situationen erhöht wird, in denen eine niedrige Latenzzeit wichtig ist, oder dass die Spieler die Physik-FPS an ihre Hardware anpassen können. Allerdings führen unterschiedliche Physik-FPS zu unterschiedlichen Ergebnissen in der Physiksimulation, selbst wenn Delta konsequent in der Spiellogik verwendet wird. Dies kann bestimmten Spielern einen Vorteil gegenüber anderen verschaffen. Daher sollte es bei kompetitiven Multiplayer-Spielen vermieden werden, dem Spieler die Möglichkeit zu geben, die Physik-FPS selbst zu ändern.

Schließlich können Sie die Pufferung von Eingaben für jedes gerenderte Frame deaktivieren, indem Sie Input.set_use_accumulated_input(false) in einem Skript aufrufen. Dadurch werden die Funktionen _input() und _unhandled_input() in Ihren Skripten bei jeder Eingabe aufgerufen, anstatt Eingaben zu akkumulieren und darauf zu warten, daß ein Frame gerendert wird. Die Deaktivierung der Eingabeakkumulation erhöht die CPU-Auslastung, daher sollte sie mit Vorsicht durchgeführt werden.

Tipp

On any Godot project, you can use the --disable-vsync command line argument to forcibly disable V-Sync. Since Godot 4.2, --max-fps <fps> can also be used to set an FPS limit (0 is unlimited). These arguments can be used at the same time.

Hardware/OS-spezifisch

Wenn Ihr Monitor dies unterstützt, sollten Sie die variable Bildwiederholfrequenz (G-Sync/FreeSync) aktivieren, während Sie V-Sync aktiviert lassen, und dann die Bildwiederholfrequenz in den Projekteinstellungen auf einen Wert begrenzen, der etwas unter der maximalen Bildwiederholfrequenz Ihres Monitors liegt (siehe diese Seite). Bei einem 144-Hz-Monitor können Sie zum Beispiel die Framerate des Projekts auf 141 einstellen. Dies mag auf den ersten Blick kontraintuitiv erscheinen, aber die Begrenzung der FPS unterhalb der maximalen Bildwiederholrate stellt sicher, dass das Betriebssystem nie auf das Ende der vertikalen Austastlücke warten muss. Dies führt zu einem ähnlichen Input-Lag wie bei deaktiviertem V-Sync mit der gleichen Frameraten-Begrenzung (normalerweise weniger als 1 ms länger), aber ohne Tearing.

This can be done by changing the Application > Run > Max FPS project setting or assigning Engine.max_fps at runtime in a script.

Auf einigen Plattformen können Sie in den Optionen des Grafiktreibers (z.B. in der NVIDIA-Systemsteuerung unter Windows) auch einen Modus mit niedriger Latenz wählen. Mit der Einstellung Ultra erhalten Sie die geringstmögliche Latenz, allerdings auf Kosten einer etwas niedrigeren durchschnittlichen Framerate. Wenn Sie den Grafikprozessor zwingen, das maximale Performance-Profil zu verwenden, können Sie den Input-Lag noch weiter reduzieren, allerdings zum Preis eines höheren Stromverbrauchs (und der daraus resultierenden Wärme-/Lüftergeräusche).

Vergewissern Sie sich schließlich, dass Ihr Monitor in den Anzeigeeinstellungen des Betriebssystems mit der höchstmöglichen Bildwiederholfrequenz läuft.

Stellen Sie außerdem sicher, dass Ihre Maus so konfiguriert ist, dass sie die höchste Polling-Rate verwendet (in der Regel 1.000 Hz bei Gaming-Mäusen, manchmal auch mehr). Hohe USB-Polling-Raten können jedoch zu einer hohen CPU-Belastung führen, so dass 500 Hz auf Low-End-CPUs eine sichere Wahl sein kann. Wenn Ihre Maus mehrere DPI-Einstellungen bietet, sollten Sie auch die höchstmögliche Einstellung verwenden und die Empfindlichkeit im Spiel verringern, um die Mauslatenz zu reduzieren.

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

Melden von Problemen mit Jitter, Stutter oder Input-Lag

Wenn Sie Stuttering oder Jittering melden (eine Issue 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.

Wenn Sie Probleme mit Input-Lag melden, fügen Sie bitte eine Aufnahme bei, die mit einer Hochgeschwindigkeitskamera gemacht wurde (z. B. mit dem Zeitlupenmodus Ihres Telefons). Bei der Aufnahme müssen sowohl der Bildschirm als auch das Eingabegerät sichtbar sein, damit die Anzahl der Bilder zwischen einer Eingabe und dem Ergebnis auf dem Bildschirm gezählt werden kann. Vergewissern Sie sich auch, dass Sie die Bildwiederholfrequenz Ihres Bildschirms und die Polling-Rate Ihres Eingabegeräts (insbesondere bei Mäusen) angeben.

Stellen Sie außerdem sicher, dass Sie den richtigen Begriff (Jitter, Stutter, Input-Lag) für das gezeigte Verhalten verwenden. Das hilft, Ihr Problem schneller zu verstehen. Geben Sie ein Projekt an, mit dem das Problem reproduziert werden kann, und fügen Sie, wenn möglich, eine Bildschirmaufnahme bei, die den Bug demonstriert.