Напівфіксований або Повністю фіксований графік часу?

Я роблю iphone shmup і намагаюся вирішити, який тип ігрового циклу використовувати. Я хочу використовувати або напівфіксований часовий крок, або повністю фіксований часовий крок.

З напівфіксованим часовим кроком я буду робити нульові або більше оновлення (FIXED_INTERVAL) дзвінків з подальшим одним викликом оновлення (dt), де dt <= FIXED_INTERVAL за цикл гри. Як я розумію, недоліки цього методу полягають у тому, що моя логіка оновлення фізики (dt) буде важче запрограмована, тому що я, як правило, повинен приймати змінну dt для кожного оновлення. А потім я також чув, що кожен запуск моєї гри буде дещо іншим, оскільки значення плаваючої крапки не будуть однаковими кожен раз.

Тоді з повністю фіксованим часовим кроком я здійснюю нульове або більше оновлення (FIXED_INTERVAL) дзвінків з подальшим одним інтерполяційним (dt / FIXED_INTERVAL) викликом, де dt <FIXED_INTERVAL за цикл гри.

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

Тепер із того, що я прочитав, більшість людей говорять про використання повністю фіксованих даних та інтерполяцію. Але коли я думаю про реалізацію інтерполяції, то здається, що я був би набагато складнішим, ніж оновлення (dt) зі змінною dt. Це тому, що якщо я використовую інтерполяцію, я повинен пам'ятати і попередній стан, і поточний стан. Отже, якщо я хочу використовувати інтерполяцію, я повинен створити додатковий шар непрямості, який абстрагує всі стани гри. Тоді як із напівфіксованим часовим кроком, де мені не потрібно використовувати інтерполяцію, мені не потрібно придумувати абстракцію ігрового стану, тому що завжди є лише один ігровий стан, і це просто "глобальні масиви", які представляють моїх ворогів та ворога кулі тощо.

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

Повністю виправлено

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

Ноель Лопіс чудово написав про те, як він реалізував фіксований крок часу у своїй грі Casey's Contraptions . Як бонус для вас, він розробник iphone, хоча його техніка не є особливою для iphone.

Деякі основні моменти зі статті

• Використовуйте акумулятор часу.
• Використовуйте частоту фізики 120 Гц для частоти кадрів 60 Гц.
• Моделюйте один фіксований крок у майбутнє та використовуйте накопичення, що залишилось у часі, для лерпування коду малювання між поточним станом фізики та майбутнім станом фізики.
• різні готчі

Те, що ви називаєте "напівфіксованим" та "повністю зафіксованим" часовим кроком, на мій погляд, обидва фіксованого часового кроку - dt, який ви передаєте на ваш updateдзвінок, не змінюється між кадрами.

Отже, ваше запитання насправді "я хочу впровадити інтерполяцію для цілей надання?" Відповідь: напевно, ні .

Інтерполяція - це те, що ви хотіли б зробити, лише якщо ваш встановлений updateчасовий крок помітно відрізняється від цільового renderчасового кроку. Не рідкість у іграх, які мають напружену updateфазу, дзвонити лише updateна, скажімо, 10 ГГц, але візуалізувати в повному кадрі.

Оскільки ви пишете shmup для iPhone, ні ваша, updateні ваша renderпотреба не будуть особливо інтенсивними процесорами; ви можете легко заблокувати частоту кадрів до 30 Гц або 60 ГГц, не переймаючись реалізацією, та все ж мати граючу вигляд.