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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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