修复抖动、卡顿和输入延迟

什么是抖动、卡顿和输入延迟？

抖动（Jitter）和卡顿（stutter）是即使游戏在全速运行时，也可能出现在屏幕上物体可见运动中的两种不同变化，可能会影响游戏体验。这些问题在世界以恒定速度朝着固定方向运动的游戏中影响最明显, 比如跑酷或平台类游戏.

输入延迟与抖动和卡顿无关，但也是经常为人讨论的话题。输入延迟指在鼠标、键盘、控制器与触屏在与游戏进行互动时，在屏幕上所呈现的视觉延迟，产生的原因与游戏代码、引擎代码及外部因素（如硬件因素）等方面有关。尤其是在第一人称游戏当中，输入延迟尤为明显。输入延迟无法消除，但可以通过某些手段来减少输入延迟。

抖动和卡顿的区分

一款在正常帧下运行, 而不显示任何效果的游戏将显得平滑:

游戏展示了抖动将以非常细微的方式持续抖动：

最后，存在“卡顿”的游戏看上去是流畅的，但似乎每隔几秒钟就会停顿或回滚一帧：

抖动

产生抖动的原因有很多，最典型的情况发生在运行游戏时的物理频率（通常为 60 Hz）以与显示器刷新率不同。检查你的显示器刷新率是否为 60 Hz。

这通常不是一个问题, 因为大多数显示器都是60赫兹, 而且从Godot 3.1开始, 引入了一个帧定时器, 尽量与刷新同步.

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.

卡顿

产生卡顿有两个不同原因。第一个，也是最明显的一个，就是游戏无法保持完整的帧率性能。解决方法是因游戏而异的，需要进行优化。

第二个原因更复杂，因为它通常与引擎或游戏无关，而与底层操作系统有关。下面是不同操作系统上，关于卡顿的一些信息。

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

众所周知，Windows 操作系统在窗口化游戏时会产生卡顿。这主要取决于你所安装的硬件，驱动程序版本和并行运行的进程（例如，打开多个浏览器标签页可能导致游戏在运行时出现卡顿）。为了避免这种情况，从 3.1 版本开始，Godot 将游戏的优先级提升到了“高于标准”。这样能够相当程度缓解问题，但可能无法完全消除卡顿现象。

完全消除这种情况需要给你的游戏以充分的权限, 使之成为 “time critical” , 这是不建议的. 有些游戏可能会这样做, 但建议学会忍受这个问题, 因为这对Windows游戏来说很常见, 而且大多数用户不会在窗口中玩游戏(反正在窗口中玩的游戏, 如益智游戏, 通常不会出现这个问题).

对于全屏来说，Windows 系统对游戏给予了特殊的优先级，所以卡顿现象不再可见，也非常罕见。大多数游戏都是这样玩的。

小技巧

Games should use the Exclusive Fullscreen window mode, as opposed to Fullscreen which is designed to prevent Windows from automatically treating the window as if it was exclusive fullscreen.

Fullscreen is meant to be used by GUI applications that want to use per-pixel transparency without a risk of having it disabled by the OS. It achieves this by leaving a 1-pixel line at the bottom of the screen. By contrast, Exclusive Fullscreen uses the actual screen size and allows Windows to reduce jitter and input lag for fullscreen games.

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. Stutter may be more present when playing in windowed mode as opposed to fullscreen, even with compositing disabled.

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

macOS

通常情况下，macOS 不会出现卡顿现象，尽管最近在全屏运行时报告了一些 bug（这是 macOS 的 bug）。如果你的机器表现出这种行为，请将这问题提交给我们。

Android

通常情况下，Android 平台不会出现卡顿和抖动现象，因为运行活动拥有所有的优先级。也就是说，可能会出现问题的设备（较旧的 Kindle Fire 就是其中之一）。如果你在 Android 平台上看到这些问题，请将问题提交给我们。

iOS

iOS设备通常没有卡顿现象，但运行新版操作系统的旧式设备可能会出现问题。这通常是不可避免的。

输入延迟

项目配置

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

针对硬件/操作系统

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 Application > Run > Max FPS project setting or assigning Engine.max_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.

报告卡顿、抖动或输入延迟问题

如果你报告的卡顿或抖动问题（提交 Issue）不是由上述原因引起的，请尽可能详细说明关于你的设备配置、操作系统、驱动程序版本等信息。这有助于我们更好地排除故障。

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