修正抖動、卡頓與輸入延遲

什麼是抖動、卡頓與輸入延遲？

抖動（jitter）與卡頓（stutter）是畫面物件可見運動的兩種不同異常現象，即使遊戲在滿幀率下運作也可能發生，並影響遊戲體驗。這類效應在世界以固定速度、固定方向運動的遊戲（如跑酷或橫向捲軸平台遊戲）中特別明顯。

輸入延遲 和抖動、卡頓無直接關聯，但經常一起被討論。輸入延遲是指玩家用滑鼠、鍵盤、控制器或觸控螢幕操作時，畫面反應所產生的可見延遲。其原因可能來自遊戲程式碼、引擎核心，或外部硬體。輸入延遲在需要滑鼠瞄準的遊戲（如第一人稱射擊）中最為明顯。雖然輸入延遲無法完全消除，但可以用多種方法減少。

如何區分抖動與卡頓

一款在正常幀率下運作且沒有異常現象的遊戲，畫面會相當流暢：

出現*抖動*的遊戲會有持續微小晃動的現象：

而出現*卡頓*的遊戲則大致上保持流暢，但每隔幾秒就會*停頓*或*倒退一個影格*：

抖動

抖動產生的原因很多，最常見的狀況是在遊戲的*物理更新頻率*（通常為 60 Hz）與螢幕的更新率不同時產生。請確認您的螢幕刷新率是否為 60 Hz。

這通常不是問題，因為多數顯示器都是 60 Hz，而自 Godot 3.1 起，引擎內已加入影格計時器機制，會盡量與螢幕刷新率同步。

有時候只有部分物件（如角色或背景）會發生抖動。這常見於這些物件分別在不同的時序（如某些在物理步驟、某些在閒置步驟）處理。Godot 3.1 針對此狀況進行改良，包含允許動態剛體於一般的 _process() 迴圈中進行動畫化，以及進一步優化影格計時機制。

卡頓

卡頓可能有兩種原因。第一種也是最明顯的，就是遊戲無法維持完整幀率。這屬於遊戲本身效能問題，需要針對遊戲內容進行優化。

第二種原因則較為複雜，通常與引擎或遊戲本身無關，而是與底層作業系統有關。以下介紹各作業系統下常見的卡頓情形。

在支援關閉垂直同步（V-Sync）的平臺上，可以在專案設定中停用垂直同步來降低卡頓感受，但這會導致畫面撕裂，特別是在低刷新率顯示器上。若您的顯示器支援，請考慮同時啟用可變更新率（G-Sync/FreeSync）並保持 V-Sync 開啟，這樣能減輕部分卡頓且不會產生撕裂現象。

強制顯示卡使用最高效能設定檔也能減少卡頓，但會增加 GPU 耗電。

Windows

Windows 系統中，視窗化遊戲容易出現卡頓，這與硬體規格、驅動版本及同時執行的背景程式（如瀏覽器分頁過多）都有關。自 Godot 3.1 起，預設會將遊戲行程優先順序調高為「高於標準」，這大幅改善卡頓但仍無法完全避免。

若要徹底消除這類卡頓，需將遊戲程式權限提升至「time critical」等級，但這並不建議。雖然部分遊戲會這麼做，但建議接受這種現象，畢竟這對 Windows 遊戲而言很常見，而且大多數玩家不會用視窗模式遊玩（例如益智遊戲等本就常用視窗模式的類型則較少遇到此問題）。

在全螢幕模式下，Windows 會給予遊戲特殊優先順序，因此卡頓現象極少見。大多數遊戲都是採用這種方式執行。

若您使用輪詢率 1,000 Hz 以上的滑鼠，建議使用最新版 Windows 11，該系統針對高輪詢率滑鼠引起的高 CPU 使用率有相關修正，這些修正在 Windows 10 及更舊版本中並未實作。

小訣竅

遊戲建議使用 Exclusive Fullscreen**（獨佔全螢幕）視窗模式，而非 **Fullscreen，因為後者設計目的是避免 Windows 將視窗誤判為獨佔全螢幕。

Fullscreen 主要用於需要每像素透明度且不希望被作業系統關閉這功能的 GUI 應用程式。它會在螢幕底部保留 1 像素的線條。而 Exclusive Fullscreen 則會真正以螢幕實際尺寸運作，讓 Windows 能降低全螢幕遊戲的抖動與輸入延遲。

Linux

在 Linux 桌面環境下，也可能出現卡頓，這通常與顯示卡驅動程式或視窗合成器有關。有些合成器（例如 KWin）會惡化此問題，可以考慮切換其他合成器進行排除。部分視窗管理器如 KWin、Xfwm 可手動關閉合成，能提升效能，但可能會導致畫面撕裂。

針對由驅動程式或合成器導致的卡頓，除了向相關開發團隊回報問題，無其它解法。在視窗模式下，即使已關閉合成，卡頓情形通常比全螢幕更明顯。

Feral GameMode 可用來於執行特定程式時自動套用最佳化設定（例如強制 GPU 使用高效能模式）。

macOS

一般來說，macOS 基本上不會發生卡頓。不過，近期有部分全螢幕狀態下的卡頓回報（這屬於 macOS 系統本身的問題）。若您的裝置有此現象，請回報給我們。

Android

Android 裝置通常不會發生卡頓與抖動，因為執行中的應用會獲得最高優先權。但仍有些裝置可能出現問題（如舊款 Kindle Fire）。若您在 Android 平臺遇到類似狀況，歡迎回報。

iOS

iOS 裝置通常不太會有卡頓現象，但舊型裝置若升級到新版系統，仍有可能出現問題，這在多數狀況下無法避免。

輸入延遲

專案設定

在支援停用垂直同步的平臺上，可以在專案設定中關閉 V-Sync 以降低輸入延遲，但這樣會導致畫面撕裂，尤其在低刷新率顯示器上。建議讓 V-Sync 作為選項，讓玩家可自行切換。

當使用 Forward+ 或 Mobile 算繪模式時，若已啟用 V-Sync，還能進一步透過「雙緩衝」取代預設的「三緩衝」來降低視覺延遲。自 Godot 4.3 起，可將 Display > Window > V-Sync > Swapchain Image Count 專案設定調整為 2 即啟用雙緩衝。不過，雙緩衝在無法達到螢幕刷新率時（如 CPU/GPU 效能不足），幀率會變得不穩定。例如 60 Hz 螢幕下，若三緩衝時遊戲幀率約 55 FPS，雙緩衝則會瞬間降到 30 FPS，然後再回升至 60 FPS。因此，僅建議在目標硬體能*穩定*輸出滿幀率時，才使用雙緩衝 V-Sync。

提升每秒物理計算次數同樣能降低物理相關的輸入延遲。這在啟用物理內插（即提升平滑度但增加延遲）時更為明顯。您可以將 Physics > Common > Physics Ticks Per Second 設定為高於預設值 60，或於執行時透過腳本設定 Engine.physics_ticks_per_second。若未啟用物理內插，建議設定為螢幕刷新率的倍數（如 120、180、240），可避免抖動。額外好處是較高的物理幀率能減少穿透和物理不穩定問題。

但增加物理幀率會提升 CPU 使用率，對於物理運算量大的遊戲可能造成效能瓶頸。您可選擇僅在低延遲至關重要時提高物理幀率，或讓玩家依硬體調整。不過，即便您的邏輯程式碼都正確使用 delta，不同的物理幀率還是會導致物理模擬結果出現差異，讓部分玩家產生優勢。因此，競技型多人遊戲不建議讓玩家自行調整物理幀率。

最後，您也可以在腳本中呼叫 Input.set_use_accumulated_input(false)，以停用每個算繪影格的輸入緩衝。這樣 _input() 與 _unhandled_input() 會於每次輸入時立即呼叫，而非累積輸入並等到下一影格才處理。停用輸入累積會增加 CPU 使用率，請謹慎使用。

小訣竅

在任何 Godot 專案中，都可以於啟動時加上 --disable-vsync 指令列參數強制關閉 V-Sync。自 Godot 4.2 起，也可使用 --max-fps <fps> 設定最大幀率（設為 0 則無上限）。這兩個參數可以同時使用。

針對硬體／作業系統的建議

若您的顯示器支援，建議同時啟用可變刷新率（G-Sync/FreeSync）及 V-Sync，並依照這篇文章的建議，將專案設定中的最大幀率限制設為略低於螢幕最大刷新率。例如 144 Hz 螢幕可設為 141。這看似違反直覺，但實際上可確保作業系統無須等待垂直消隱完成，達到與關閉 V-Sync 並限制幀率時*幾乎相同*的輸入延遲（通常僅多出不到 1 毫秒），同時又完全無撕裂。

您可以透過調整 Application > Run > Max FPS 專案設定，或於執行時在腳本設定 Engine.max_fps 來完成。

某些平臺（如 Windows 上的 NVIDIA 控制面板）可以在驅動程式設定中啟用低延遲模式，選擇 Ultra 可以獲得最低延遲（但平均幀率會稍降）。同時強制 GPU 使用最高效能模式，也能進一步減少輸入延遲，但會增加耗電與散熱（風扇噪音）。

最後，請在作業系統顯示設定中，確認您的顯示器已設定為最高刷新率。

同時，請確認您的滑鼠設定為最高輪詢率（遊戲滑鼠通常為 1,000 Hz 或更高）。但輪詢率越高，CPU 負擔也越大，若為低階 CPU，建議設為 500 Hz 較為穩妥。若滑鼠支援多段 DPI ，建議也可將 DPI 調至最高，遊戲內靈敏度調低，以降低滑鼠延遲。

在 Linux 上，若視窗管理器（如 KWin 或 Xfwm）允許，可關閉視窗合成，這能顯著降低輸入延遲。

回報抖動、卡頓或輸入延遲問題

若您回報的抖動或卡頓問題（提出 Issue）並非上述原因，請盡量詳列您的裝置、作業系統、驅動程式版本等資訊，有助於我們進一步協助排除問題。

若您要回報輸入延遲問題，請附上用高速相機（如手機的慢動作錄影）拍攝的影片。影片**必須**同時錄到螢幕與輸入裝置，以便計算從輸入到畫面反應的影格數。請同時註明顯示器刷新率與輸入裝置（特別是滑鼠）的輪詢率。

另外，請根據實際狀況使用正確的名詞（抖動、卡頓、輸入延遲），這有助於我們更快理解您的問題。請附上可重現問題的專案，並盡可能提供螢幕錄影以利說明。