Які переваги обмеження кадрів в секунду? (Якщо якийсь)

Я працюю над простою грою в OpenGL, використовую SDL для ініціалізації дисплея та введення, і це з'являється з точки зору часу, у мене є два варіанти. Номер один, який просто спить для оптимальногоTimePerFrame - theTimeTakenToRender, коли оптимальнийTimePerFrame за секунди = 1 / theFramerateCap. (Я не зовсім впевнений, чи потрібно це, оскільки це еквівалентно використанню vsync, що може бути більш точним. Якщо моє припущення правильне, то, будь ласка, скажіть мені, чи не, SDL + OpenGL має vsync за замовчуванням, а якщо ні, як щоб увімкнути це.) Інше полягає в вимірюванні часу з моменту надання останнього кадру і просто відповідно регулюйте рух. (Чим коротший час для візуалізації кадру, тим менше далекі об'єкти рухаються в цьому кадрі). Що стосується продуктивності та зменшення мерехтіння тощо, які переваги та недоліки мають ці два методи?

Якщо час кадру непередбачувано (винна ви чи ні; ОС може періодично використовувати ресурси тощо), обмеження передбачуваної частоти кадрів, яка дещо нижча, ніж ваш досяжний кадр, зробить багато для передбачуваної затримки , яка може змусити гру відчути себе набагато краще.

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

Дивіться презентацію Microsoft GameFest: Що знаходиться в кадрі: Сльоза, затримка та частота кадрів для ознайомлення тут. Carmack також має ряд корисних публікацій у блозі .

Також пам’ятайте, що деяка математика може вийти з ладу, коли ви запускаєте кадри, використовуючи низькі deltaTзначення - або навіть коли ви взагалі використовуєте змінну deltaT(все може стати важче або навіть нерозв'язним зробити "стабільним" і передбачуваним чином, що важливо для речей наприклад, повтори та деякі форми мережевої синхронізації). Див. « Виправлення свого часового кроку» для ознайомлення тут.

У кінцевому підсумку ви будете використовувати набагато менше CPU (багато завдань дякують вам), і люди на мобільних пристроях також оцінять це.

Ви ніколи не повинні ніколи, ніколи, ніколи ніколи не використовувати режим сну для управління частотою кадрів .

Про це вже було сказано раніше, і я надішлю вас на інше питання для обговорення причин. Одне, що не згадується там, - це те, що при типовій сучасній частоті оновлення 60 Гц, і при типовій 1-мілісекундній зернистості дзвінків у режимі сну, насправді неможливо спати протягом правильної кількості часу між кадрами.

Я не кажу, що приновити процесор, якщо вам нічого не робити, це погано; далеко від цього. Але це не те саме, що контролювати частоту кадрів, і режим сну - це рішення, яке підходить для першого, але не для останнього.

Натомість перевірте час, що минув, і якщо настав час запустити кадр, тоді зробіть це, інакше - і якщо ви хочете отримати трохи процесора - сплять за мінімальний час - 1 мілісекунда. Також слідкуйте за тим, щоб ваш таймер сну був встановлений належним чином для вашої платформи, щоб забезпечити вам хорошу роздільну здатність; тобто, коли ви видаєте цей дзвінок "Сон (1)", ви насправді маєте шанс насправді спати протягом 1 мілісекунди, а не щось на зразок 15, 20 або 30 (що було б інакше). Я вірю, що SDL зробить це автоматично для вас.

Ви також можете створити деяку слабкість в ньому, так що якщо вже наближається час запускати кадр, ви припиняєте сплячий режим і починаєте згладжуватися до тих пір, поки кадр не запуститься, що допоможе точніше вразити потрібний інтервал кадру.

Як виглядає це, - це ціла купа дзвінків зі сну (1), змішаних із випадковими кадрами, і все в порядку. Ви все ще віддаєте процесор, коли він вам не потрібен, але ваші кадри все одно зможуть працювати вчасно.

Мабуть, найважливіша перевага обмеження частоти кадрів полягає в тому, що це може допомогти запобігти буквальному фізичному пошкодженню машини. Вони забули зробити це на Starcraft II, що виявилося дуже проблематичним (і дорогим) для деяких користувачів, поки вони не виправили це.

Як було сказано раніше, це знижує використання процесора. З іншого боку, це стає все більш важливим, що також вичерпує час автономної роботи. Як хороший приклад, FTL працює на майже 100% ЦП на моїй MBA. Як результат, він заряджає акумулятор за> 2 години і працює дуже гаряче. (Що стосується більш прямого результату, я видалив його і більше не відтворюю його ...). Капельна рамка завадила б цьому.

Ще одна не згадана перевага - якщо його багатокористувацька гра, ви також вирівнюєте ігрове поле, надаючи всім однаковий досвід.