UPS и FPS - что я должен ограничивать и почему?

В настоящее время я пишу игру на C ++ и SDL2, и меня интересует одна вещь: имеет ли смысл ограничивать количество кадров в секунду (FPS) и / или количество обновлений в секунду (UPS)?

Я понял, что если вы ограничите ИБП, вы по сути контролируете скорость игры - если игрок перемещается на 1 пиксель за обновление, а вы всегда обновляете его 30 раз в секунду, он будет двигаться со скоростью 30 пикселей / с, и вы Вероятно, также освободит процессор, так как количество вычислений в секунду уменьшается. Если вы ограничите FPS, количество вызовов в секунду уменьшается, поэтому вы освобождаете свой графический процессор. Надеюсь, я все понял правильно, если нет, не стесняйтесь поправлять меня.

Мой вопрос - что я должен ограничивать в своей игре? FPS? UPS? И то и другое? Ни? Есть ли другой, лучший подход к этому? Как это делается в большинстве игр и почему?

Ответы с благодарностью!

Да, это имеет смысл.

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

Однако .... Ваша игровая логика НЕ ​​должна зависеть от обновлений в секунду. Поэтому я рекомендую вам взглянуть на deltatime, что сделает вашу игру независимой от обновлений в секунду.

Я рекомендую вам взглянуть на этот вопрос. Это довольно хорошо объясняет, как рассчитать и использовать его. Как получить и использовать дельта время

Надеюсь, это помогло!

Лучший ответ: это зависит .

Вы не должны ограничивать ни один

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

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

Вы можете ограничить оба

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

Рендеринг : число кадров в секунду должно быть установлено на верхний предел, чтобы избежать вышеупомянутой проблемы с разрывом, однако ваше приложение не должно пытаться делать это вручную с некоторой блокировкой процессора. Вместо этого включите v-sync и позвольте нижележащему оборудованию синхронизироваться с частотой обновления монитора. Благодаря этому ваша игра будет совместима с будущими мониторами, которые могут работать на гораздо более высокой частоте, чем обычные в настоящее время 60 Гц. Стоит также отметить, что многие геймеры, особенно те, кто занимается тестированием производительности, по-прежнему предпочитают работать без v-sync, чтобы обеспечить максимально возможную частоту кадров. Поэтому имеет смысл разрешить включение или отключение функции во время выполнения.

То, что вы не должны ограничивать

Если ваша игра использует основанный на опросе подход к пользовательскому вводу, например: вызывает своего getInput()рода вызовы, чтобы обновить состояния контроллера на этапе обновления, тогда это лучше, если не ограничено. Или, если ограничено, тогда установите очень высокую верхнюю границу. Чем чаще вы запрашиваете пользовательский ввод и воздействуете на него, тем более отзывчивым и плавным будет «чувствовать» игра. Так называемые игры с частотой 60 Гц, о которых мы сейчас слышим, не обновляют ИИ и все мировые государства с такой скоростью, некоторые даже не рендерится так быстро, но они запрашивают данные контроллера по крайней мере 60 раз в секунду и соответственно обновляют аватар игрока. Конечно, это актуально только для динамичных игр.

Есть два сообщения, на которые вы можете взглянуть:

Исправьте ваш временной шаг

Интерполированный физический рендеринг

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

Надеюсь, поможет.