ДБЖ та FPS - Що слід обмежувати і чому?

В даний час я пишу гру за допомогою C ++ і SDL2, і мені цікаво одне - чи є сенс обмежувати мої кадри на секунду (FPS) та / або мої оновлення на секунду (UPS)?

Мені здається, що якщо обмежити ДБЖ, ти по суті керуєш швидкістю гри - якщо гравець рухається 1 піксель за оновлення, а ти завжди оновлюєш його 30 разів на секунду, він рухатиметься зі швидкістю 30 пікселів на секунду, і ти Ви, мабуть, також полегшать процесор, оскільки кількість обчислень за секунду зменшується. Якщо ви обмежите FPS, кількість зворотних дзвінків за секунду зменшується, тому ви знімаєте свій GPU. Я сподіваюся, що я все це зрозумів правильно, якщо ні, не соромтеся виправити мене.

Моє запитання - що я повинен обмежувати у своїй грі? FPS? ДБЖ? Обидва? Ні? Чи є ще один, кращий підхід до цього? Як це робиться в більшості ігор і чому?

Відповіді високо оцінені!

Так, це має сенс.

Як ви сказали, це призведе до меншого навантаження на систему, що добре для терміків та інших програм.

Однак .... Ваша логіка ігор НЕ повинна залежати від оновлень за секунду. Тому рекомендую поглянути на deltatime, що зробить вашу гру незалежною від оновлень за секунду.

Рекомендую поглянути на це питання. Це досить добре пояснює, як його обчислити та використовувати. Як отримати та використовувати дельта-час

Сподіваюся, це допомогло!

Найкраща відповідь: Це залежить .

Вам не потрібно обмежувати жодного

Оновлення : Якщо ваші оновлення не прив’язані до верхньої межі, то логіка гри повинна залежати від часу дельти , щоб уникнути запуску гри швидше чи повільніше, залежно від машини, де вона працює. Це дуже поширений підхід, який використовується багатьма іграми, але він не єдиний.

Візуалізація : Якщо візуалізація не прив’язана до верхньої межі, рамбуфер може бути представлений у неповному або помилковому стані, викликаючи розрив артефактів . Ось чому багато ігор використовують вертикальну синхронізацію (v-sync)

Ви можете обмежити обидва

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

Візуалізація : кадрів за секунду слід встановити на верхню межу, щоб уникнути вищезгаданої проблеми зі сльозами, однак ваша програма не повинна намагатися робити це вручну з деяким блокуванням процесора. Натомість увімкніть v-sync та дозвольте нижньому апаратному пристрою синхронізуватися зі швидкістю оновлення монітора. Роблячи це, ваша гра буде вперед сумісною з майбутніми моніторами, які можуть працювати на набагато більшій частоті, ніж звичайні 60 ГГц. Варто також зазначити, що багато геймерів, зокрема ті, хто займається тестуванням, все ж віддають перевагу працювати без v-синхронізації, щоб забезпечити максимально можливу частоту кадрів. Тому доцільно дозволити вмикати або вимикати функцію під час виконання.

Що ви не повинні обмежувати

Якщо ваша гра використовує підхід на основі опитування до введення користувачем, наприклад: викликає getInput()різновиди для оновлення станів контролера під час кроку оновлення, тоді це краще, якщо не обмежуватись. Або якщо обмежений, то встановіть дуже високу верхню межу. Чим частіше ви запитуєте користувальницьку інформацію та дієте на неї, тим більш чуйною та плавною буде гра «відчувати». Так звані ігри з частотою 60 Гц, про які ми чуємо в наш час, не оновлюють AI і всі світові стани з такою швидкістю, деякі навіть не показують це швидко, але запитують контролер на введення щонайменше 60 разів на секунду і відповідно оновлюють аватар гравця. Зрозуміло, що це дійсно актуально лише для ігор, що швидко розвиваються.

Ви можете поглянути два повідомлення:

Виправте свій графік роботи

Інтерпольована фізична візуалізація

Я вважаю, що обговорення в дописах є справді безцінними, але, на мою думку, це має найбільше сенс, коли в грі є важлива кількість фізичного моделювання. Підводячи підсумок, ідея полягає в тому, що моделювання має мати фіксований часовий крок (інакше фізика може вибухнути в певний момент, коли дельта занадто велика), тоді як для надання потрібно дати свободу працювати з максимально можливою швидкістю. Для синхронізації обох (моделювання та візуалізація) стан візуалізації інтерполюється фактором, який залежить від того, наскільки симуляція знаходиться від наступного оновлення (пам’ятайте, що моделювання виправлено).

Сподіваюся, це допомагає.