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

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

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

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

Ответы приветствуются!

11 голосов | спросил DocCoock 6 J0000006Europe/Moscow 2015, 21:59:41

3 ответа


10

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

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

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

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

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

ответил KaareZ 6 J0000006Europe/Moscow 2015, 22:15:08
6

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

Вам не нужно ограничивать ни один

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

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

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

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

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

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

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

ответил glampert 8 J0000006Europe/Moscow 2015, 08:01:07
1

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

Исправить вашу тему времени

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

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

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

ответил Francis Moy 10 J0000006Europe/Moscow 2015, 11:02:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132