Мой опыт (и я не одинок в этом), что это вообще плохая идея:
- тестирование/выявление ошибок является много сложнее:
- Вы будет забыть фактор в кадре времени на определенные вещи, и если ваша игра обычно работает с довольно ровной частотой кадров, которая иногда падает/пики, вам потребуется много времени, чтобы выявить эти проблемы. Однако они будут действительно очевидны для людей с устройствами, которые значительно быстрее/медленнее, чем ваше тестовое устройство (устройства).
- Вы открываете для себя всевозможные труднодоступные ошибки, связанные с ошибками с плавающей запятой/etc. Ошибки могут по-прежнему появляться в контуре фиксированной FPS, но они будут выполняться каждый кадр, а не только на кадрах, которые занимают ровно 3124 наносекунды.
- Физическое моделирование в реальном времени очень сложно для нефиксированных интервалов обновления. Поверь мне в этом! Вы можете обойти это, используя фиксированные временные шаги для обновлений физики, но это связано с собственными рисками.
- Вы должны вычислить вещи, которые в противном случае могли бы быть константами. Очень мала на индивидуальной основе, но может складываться. (Это будет зависеть от характера вашей игры).
- Если вы всегда используете процессор на 100%, он будет быстрее переваривать аккумулятор пользователя.
Мой совет заключается в том, чтобы запустить вашу логику с приемлемой фиксированной частотой кадров и визуализировать как можно чаще, хотя чаще всего нет смысла рендеринга логики. Если есть «запасное» время, то просто спите. Батарея пользователя будет вам благодарна, и пользователь не будет удивляться, почему их телефон становится настолько горячим, когда они играют в вашу игру!
Ключом к тому, чтобы заставить его чувствовать себя гладко, является то, что ваша фиксированная частота кадров для обновлений логики достаточно высока. Дело в том, что выше определенной частоты кадров пользователи не заметят разницы. Насколько высока достаточно высокая, будет зависеть от точной природы вашей игры, но 30 фсп довольно распространены для экшн-игр. Чем быстрее пользователи смогут видеть перемещение/изменение, тем быстрее требуется фиксированная частота кадров - например,шутеры от первого лица всегда хотят иметь более высокую частоту кадров, чем стратегические игры.
Другой вариант, который вы можете сделать, - создать логические «снимки» и интерполировать между ними при рендеринге. Это обычная техника, используемая для сглаживания многопользовательских игр, как описано here. Это также делает его допустимым вариантом для рендеринга чаще, чем вы обновляете логику!
РЕДАКТИРОВАТЬ: Надеюсь, уточните некоторые вещи.
Спасибо за ваш ответ. Это дало мне более полное представление о том, с чем я имею дело. Тем не менее, ваше предложение по обновлению с фиксированной частотой кадров и рендеринга как можно чаще может привести к увеличению рендеринга, чем к обновлению, что не имеет никакого смысла. Однако обновление с фиксированной частотой кадров не было бы круто, если бы мы могли сгладить всю графику на более быстрых телефонах. :( –
Обновлен мой ответ. Вы на самом деле пытались работать на разных кадрах на быстром телефоне, чтобы увидеть, можно ли увидеть разницу в гладкости? – vaughandroid
Я пытался увеличить fps на одном телефоне. это было связано с тем, что обновление было быстрее, но гладкость приемлема при 30 кадрах в секунду и должна работать на устройствах G1 и G2. Поэтому я считаю, что я буду придерживаться этого. –