Как использовать несколько поставщиков тиков (каркасных и фиксированных) с платформой сущностей Ash?

Question

Обычной практикой является выполнение расчетов рендеринга при обновлении фрейма и физических вычислений с фиксированным интервалом времени. Я не понимаю, как это сделать в Эш. Все примеры игровых объектов, которые я видел, используют только один ITickProvider (может быть FixedTickProvider или FrameTickProvider), который вызывает engine.update() на каждом тике. Что, если, например, я хочу обновить свои системы рендеринга со скоростью 60 кадров в секунду, но обновить игровую логику с фиксированным интервалом времени, в случае задержки?

tickProvider = new FrameTickProvider( container );
tickProvider.add( engine.update );
tickProvider.start();

Некоторые идеи...

• Могу ли я обновить группы систем отдельно?
• Должен ли я использовать 2 двигателя?

Answer 1

Не вдаваясь в конкретные соображения по поводу инфраструктуры Ash, существует много способов обработки обновления физического и графического движка, которые не обязательно зависят от используемой платформы. Прежде всего, если вы не создаете мобильное приложение AIR, предназначенное только для устройств с достаточными требованиями к оборудованию, вы не можете предполагать постоянную частоту кадров 60 кадров в секунду (или любую твердую частоту кадров). Это оставляет вам несколько вариантов:

• обновите физический движок с фиксированной дельтой t, в этом случае любой пропущенный кадр замедлит физику игры. Не хорошо

• измерьте фактическую дельту t между последними кадрами и обновите физический механизм соответствующим образом, чтобы компенсировать задержку предыдущего кадра. Этого должно быть достаточно в большинстве случаев

• если по какой-то причине ваш физический движок требует фиксированных приращений (например, updatePhysic(1/30);дает слишком отличный результат от updatePhysic(1/60); updatePhysic(1/60);или если вам нужна полностью воспроизводимая физика, не зависящая от частоты кадров, например, компьютерные повторы или синхронизация физических данных сетевых клиентов), замените updatePhysic(dT); от for(var i:int = 0; i< dT * 60; ++i) updatePhysic(1/60);(если дельта t не всегда кратна 1/60 реализации, вам следует накопить остаток от деления для следующего обновления)

• Если вам нужна оптимальная производительность и наилучшее использование многоядерных процессоров, вы можете подумать об обновлении физического движка в отдельном работнике, но поддержка флэш-плеера, инструменты отладки и обмен данными между работниками все еще являются экспериментальными!

В любом случае, я не вижу смысла в

Я хочу обновить мои системы рендеринга со скоростью 60 кадров в секунду, но обновлять игровую логику с фиксированным интервалом времени, если есть задержка?

поскольку, если есть "задержка", это означает, что отображение не будет обновляться при 60 кадрах в секунду, и даже если бы это было (в случае, если вы выполняете физику в отдельном работнике), оно будет отображать тот же кадр снова.

Подводя итог, вам может потребоваться запустить физический движок "быстрее", чем графический движок, но никогда не наоборот.

Кроме того, в Actionscript вы не можете запустить тик быстрее, чем фактическая частота кадров: любой вызов Timer, setTimeout, setInterval... будет максимально синхронизирован с дисплеем, но никогда не быстрее, поэтому вам нужно вызывать физический движок несколько раз вручную внутри основного цикла, вместо того, чтобы просто установить галочку на 60 кадров в секунду, например