Устранение дрожания, заикания и задержки ввода

Что такое дрожание (jitter), заикание (stutter) и задержка ввода (input lag)?

Джиттер и задержка это два разных изменения в визуальном движении объектов по экрану которые могут влиять на игру, даже при запуске на полной скорости. Эти эффекта главным образом видны в играх где мир движется с постоянной скоростью в фиксированном направлении, такие как раннеры или платформеры.

Input lag не связана с дрожанием и зависанием, но иногда обсуждается параллельно. Задержка ввода — это видимая задержка на экране при выполнении действий с помощью мыши, клавиатуры, контроллера или сенсорного экрана. Она может быть связана с кодом игры, кодом движка или внешними факторами (например, аппаратным обеспечением). Задержка ввода наиболее заметна в играх, где для прицеливания используется мышь, например, в играх от первого лица. Задержку ввода невозможно полностью устранить, но её можно уменьшить несколькими способами.

Различение дрожания (jitter) и заикания (stutter)

Игра запущенная с нормальной частотой кадров и без использования эффектов будет проигрываться гладко:

Игра с джиттером будет постоянно дёргаться в непонятной манере:

Наконец, игра с задержкой будет проигрываться плавно, но будет приостанавливаться или откатывать кадр назад каждые пару секунд:

Jitter (дрожание)

Причин дрожания может быть множество. Наиболее распространённая из них — это когда частота физики игры (обычно 60 Гц) работает с разрешением, отличным от частоты обновления монитора. Проверьте, отличается ли частота обновления вашего монитора от 60 Гц.

Иногда дрожание наблюдается только у некоторых объектов (персонажа или фона). Это происходит, когда они обрабатываются в разных временных источниках (один обрабатывается на этапе физики, а другой — на этапе ожидания).

Эту причину дрожания можно устранить, включив physics interpolation в настройках проекта. Интерполяция физики сглаживает обновления физики, интерполируя преобразования физических объектов между физическими кадрами. Таким образом, визуальное представление физических объектов всегда будет выглядеть плавным независимо от частоты кадров и тиков физики.

Включение интерполяции физики имеет некоторые особенности, о которых следует знать. Например, при телепортации объектов следует соблюдать осторожность, чтобы не допустить видимой интерполяции между старым и новым положением, если это не предусмотрено. Подробности см. в документации Интерполяция физики.

Примечание

Включение интерполяции физики увеличит задержку ввода для поведения, зависящего от физического тика, например, движения игрока. В большинстве игр это предпочтительнее, чем дрожание, но будьте внимательны в играх с фиксированной частотой кадров (например, файтингах или ритм-играх). Увеличение задержки ввода можно компенсировать увеличением частоты физического тика, как описано в разделе Input lag (Задержка ввода).

Задержка

Задержки могут возникать по нескольким причинам. Одна из них — игра не может поддерживать полную частоту кадров из-за узких мест в процессоре или видеокарте. Решение этой проблемы зависит от конкретной игры и потребует optimization.

Другая распространённая причина подтормаживаний — подтормаживания при компиляции шейдеров. Это происходит, когда шейдер необходимо скомпилировать при первом появлении нового материала или эффекта частиц в игре. Такие подтормаживания обычно возникают только при первом прохождении игры или после обновления графического драйвера, когда кэш шейдеров становится недействительным.

Начиная с версии Godot 4.4, при использовании рендереров Forward+ или Mobile движок старается избежать задержек компиляции шейдеров, используя подход на основе убершейдеров. Для максимальной эффективности этого подхода необходимо тщательно продумать проектирование сцен и ресурсов, чтобы Godot мог собирать как можно больше информации при загрузке сцены/ресурса, а не при их первой отрисовке. Подробнее см. в разделе Уменьшение задержек при компиляции шейдеров (конвейеров).

Однако при использовании Compatibility Renderer применение этого подхода с использованием убершейдеров невозможно из-за технических ограничений OpenGL. Поэтому, чтобы избежать задержек компиляции шейдеров в Compatibility Renderer, необходимо создавать каждую сетку и визуальный эффект перед камерой в одном кадре во время загрузки уровня. Это гарантирует компиляцию шейдера при загрузке уровня, а не во время игры. Это можно реализовать за сплошным 2D-интерфейсом (например, полноэкранным узлом ColorRect), чтобы игрок не видел этого.

Примечание

На платформах, поддерживающих отключение вертикальной синхронизации (V-Sync), подтормаживание можно сделать менее заметным, отключив вертикальную синхронизацию в настройках проекта. Однако это может привести к появлению разрывов, особенно на мониторах с низкой частотой обновления. Если ваш монитор поддерживает переменную частоту обновления (G-Sync/FreeSync), оставив вертикальную синхронизацию включённой. Это позволяет смягчить некоторые виды подтормаживаний, не вызывая их. Однако это не поможет при значительных подтормаживаниях, например, вызванных подтормаживанием при компиляции шейдеров.

Заставив графическую карту использовать профиль максимальной производительности, можно также уменьшить подтормаживания, но за счет увеличения энергопотребления графического процессора.

Кроме того, подтормаживания могут быть вызваны операционной системой. Вот некоторая информация о подтормаживаниях в различных ОС:

Windows

Известно, что Windows вызывает подтормаживания в оконных играх. Это в основном зависит от установленного оборудования, версии драйверов и параллельно работающих процессов (например, большое количество открытых вкладок браузера может привести к подтормаживанию в запущенной игре). Чтобы избежать этого, Godot повышает приоритет игры до "Выше нормы". Это значительно помогает, но не может полностью устранить подтормаживания.

Чтобы полностью устранить эту проблему, необходимо предоставить игре полные права, чтобы она стала "критической по времени", что не рекомендуется. В некоторых играх это может происходить, но рекомендуется научиться жить с этой проблемой, поскольку она распространена в играх для Windows, и большинство пользователей не играют в оконном режиме (в играх, запускаемых в окне, например, в головоломках, эта проблема обычно не возникает).

Для полноэкранного режима, Windows даёт игре специальный приоритет, так что игровые задержки не будут видны и станут очень редкими. Так работает большинство игр.

При использовании мыши с частотой опроса 1000 Гц или более рекомендуется использовать полностью обновлённую версию Windows 11, содержащую исправления, связанные с высокой загрузкой процессора при использовании мышей с высокой частотой опроса. Эти исправления недоступны в Windows 10 и более ранних версиях.

Совет

Игры должны использовать режим окна Exclusive Fullscreen, а не Fullscreen, который предназначен для того, чтобы Окно не могло автоматически обрабатывать окно как эксклюзивный полноэкранный режим.

Режим Fullscreen предназначен для графических приложений, которым требуется попиксельная прозрачность без риска её отключения операционной системой. Это достигается за счёт однопиксельной линии внизу экрана. В отличие от этого, режим Exclusive Fullscreen использует фактический размер экрана и позволяет Windows уменьшить дрожание и задержку ввода в полноэкранных играх.

Linux

В настольных Linux-системах могут наблюдаться подтормаживания, но обычно это связано с другими видеодрайверами и редакторами изображений. Некоторые редакторы изображений (например, KWin) также могут вызывать эту проблему, поэтому рекомендуется попробовать другой, чтобы исключить её. Некоторые оконные менеджеры, такие как KWin и Xfwm, позволяют вручную отключать композитинг, что может повысить производительность (за счёт разрывов).

Обходного пути решения проблемы подтормаживаний драйвера или компоновщика не существует, кроме как сообщить о проблеме разработчикам драйвера или компоновщика. Подтормаживание может быть более выраженным при игре в оконном режиме, чем в полноэкранном, даже при отключенном компоновочном режиме.

Feral GameMode можно использовать для автоматического применения оптимизаций (например, принудительного применения профиля производительности графического процессора) при запуске определенных процессов.

macOS

В целом, macOS свободна от задержек, хотя недавно были найдены некоторые ошибки при запуске в полноэкранном режиме. Если вы владеете устройством демонстрирующим данное поведение, пожалуйста сообщите нам.

Android

Android в целом лишён джиттеров и задержек поскольку запущенный процесс получает полный приоритет. Однако, на некоторых устройствах могут возникать проблемы (старые Kindle Fire известны этим). Если вы увидели проблему на вашем Android устройстве, пожалуйста сообщите нам.

iOS

Устройства iOS в целом работают без задержек, но на старых устройствах запущенных на новых версиях операционной системы могут проявляться ошибки. Это в целом нельзя избежать.

Input lag (Задержка ввода)

Конфигурация проекта

На платформах, поддерживающих отключение Вертикальной Синхронизации (V-Sync), задержку ввода можно сделать менее заметной, отключив Вертикальную Синхронизацию в настройках проекта. Однако это может привести к появлению разрывов, особенно на мониторах с низкой частотой обновления. Рекомендуется сделать Вертикальную Синхронизацию доступной для включения и выключения.

При использовании методов рендеринга Forward+ или Mobile, еще один способ уменьшить визуальную задержку при включенной Вертикальной Синхронизации — использовать Вертикальную Синхронизацию с двойной буферизацией вместо стандартной тройной. Начиная с Godot 4.3, этого можно добиться, уменьшив значение параметра проекта Display > Window > V-Sync > Swapchain Image Count до 2. Недостатком использования двойной буферизации является то, что частота кадров будет менее стабильной, если частота обновления дисплея не может быть достигнута из-за узкого места в процессоре или видеокарте. Например, на дисплее с частотой 60 Гц, если частота кадров обычно падает до 55 кадров в секунду во время игры с тройной буферизацией, ей придется кратковременно упасть до 30 кадров в секунду с двойной буферизацией (а затем вернуться к 60 кадрам в секунду, когда это возможно). В результате вертикальная синхронизация с двойной буферизацией рекомендуется только в том случае, если вы можете постоянно достигать частоты обновления дисплея на целевом оборудовании.

Увеличение количества итераций физики в секунду также может снизить задержку ввода, вызванную физикой. Это особенно заметно при использовании интерполяции физики (которая улучшает плавность, но увеличивает задержку). Для этого установите значение Physics > Common > Physics Ticks Per Second выше значения по умолчанию 60 или задайте Engine.physics_ticks_per_second во время выполнения скрипта. Значения, кратные частоте обновления монитора (обычно 60), лучше всего работают при отключенной интерполяции физики, поскольку они позволяют избежать дрожания. Это означает, что такие значения, как 120, 180 и 240, являются хорошими отправными точками. Кроме того, более высокая частота кадров в секунду снижает вероятность возникновения проблем с туннелированием и нестабильностью физики.

Недостатком повышения частоты кадров в режиме физического моделирования является увеличение нагрузки на процессор, что может привести к снижению производительности в играх с обширным кодом моделирования физики. Эту проблему можно решить, увеличивая частоту кадров в режиме физического моделирования только в ситуациях, когда критически важна низкая задержка, или позволяя игрокам регулировать частоту кадров в режиме физического моделирования в соответствии со своим оборудованием. Однако разная частота кадров в режиме физического моделирования будет приводить к разным результатам в режиме физического моделирования, даже если в игровой логике постоянно используется параметр delta. Это может дать одним игрокам преимущество перед другими. Поэтому в многопользовательских играх следует избегать возможности игрокам самостоятельно изменять частоту кадров в режиме физического моделирования.

Наконец, вы можете отключить буферизацию ввода для каждого отрисовываемого кадра, вызвав Input.set_use_accumulated_input(false) в скрипте. Это позволит функциям _input() и _unhandled_input() в ваших скриптах вызываться для каждого отрисовываемого кадра, а не накапливать данные и ждать отрисовки кадра. Отключение накопления ввода увеличит нагрузку на процессор, поэтому следует соблюдать осторожность.

Совет

В любом проекте Godot вы можете использовать аргумент командной строки --disable-vsync command line argument для принудительного отключения вертикальной синхронизации. Начиная с Godot 4.2, --max-fps <fps> также можно использовать для установки ограничения FPS (0 означает неограниченное количество кадров в секунду). Эти аргументы можно использовать одновременно.

Аппаратное/ОС-специфическое

Если ваш монитор поддерживает переменную частоту обновления (G-Sync/FreeSync), оставьте вертикальную синхронизацию включённой, а затем ограничьте частоту кадров в настройках проекта до значения, немного меньшего, чем максимальная частота обновления вашего монитора, как указано на этой странице. Например, на мониторе с частотой 144 Гц можно установить ограничение частоты кадров проекта до 141. Поначалу это может показаться нелогичным, но ограничение FPS ниже диапазона максимальной частоты обновления гарантирует, что ОС никогда не придётся ждать окончания вертикального гашения. Это приводит к аналогичной задержке ввода, как при отключенной вертикальной синхронизации с тем же ограничением частоты кадров (обычно меньше чем на 1 мс больше), но без разрывов.

Это можно сделать, изменив настройки проекта Application > Run > Max FPS или назначив Engine.max_fps во время выполнения в скрипте.

На некоторых платформах можно также включить режим низкой задержки в настройках графического драйвера (например, в NVIDIA Control в Windows). Настройка Ultra обеспечит минимально возможную задержку за счёт небольшого снижения средней частоты кадров. Принудительный переход графического процессора на профиль максимальной производительности также может дополнительно снизить задержку ввода, но за счёт повышения энергопотребления (и, как следствие, нагрева/шума вентилятора).

Наконец, убедитесь, что в настройках отображения ОС монитора установлена максимально возможная частота обновления.

Также убедитесь, что ваша мышь настроена на максимальную частоту опроса (обычно 1000 Гц для игровых мышей, иногда даже выше). Однако высокая частота опроса USB может привести к высокой загрузке процессора, поэтому для процессоров начального уровня безопаснее использовать 500 Гц. Если ваша мышь поддерживает несколько настроек DPI, попробуйте также использовать максимально возможное значение и снизить чувствительность в игре, чтобы уменьшить задержку мыши.

В Linux при использовании X11 отключение композиции в оконных менеджерах, которые ее поддерживают (например, KWin или Xfwm), может значительно сократить задержку ввода.

Сообщение о проблемах с дрожанием, заиканием или задержкой ввода

Если вы докладываете о задержке или джиттере (открывая проблему) не вызванную ни какой из вышеперечисленных проблем, пожалуйста точно опишите информацию об устройстве, операционной системе, версии драйверов, итд. Это может помочь для лучшего решения.

Если вы сообщаете о проблемах с задержкой ввода, пожалуйста, приложите снимок экрана, сделанный высокоскоростной камерой (например, в режиме замедленной съёмки на вашем телефоне). На снимке должны быть видны как экран, так и устройство ввода, чтобы можно было подсчитать количество кадров между вводом и результатом на экране. Также обязательно укажите частоту обновления вашего монитора и частоту опроса устройства ввода (особенно для мышей).

Также обязательно используйте правильный термин (дрожание (jitter), заикание (stutter), задержка ввода (input lag)), соответствующий наблюдаемому поведению. Это поможет гораздо быстрее понять проблему. Предоставьте проект, который можно использовать для воспроизведения проблемы, и, по возможности, приложите снимок экрана, демонстрирующий ошибку.