Анимация загружает ЦП. Какие предложения?
 

Есть 500 Sprit'ов. Из них 105 падают вниз со скоростью 60px/0,020sec.
При этом:
-если разрешение 640х480, загрузка ЦП 35-40%
-если режим StageDisplayState.FULL_SCREEN, загрузка ЦП 80-95% (анимация тормозит)

Это всё на компьютерах:
-Intel Celeron 1.80 GHz, 512 RAM, Radeon X1600
-Intel Celeron 2.20 GHz, 1Gb RAM, Radeon X1600
-Intel Celeron 2.40 GHz, 1Gb RAM, Radeon X1600

Как уменьшить загрузку ЦП на этих компьютерах?
Есть ли разница каким образом делать анимацию (EnterFrame или Timer)?
Где лучше собирать анимацию во Flash CS 5 или Flash Builder 4?

важно, что внутри спрайтов

может все 105 падающих на битмару нарисовать и битмапу ронять?

Убрать фильтры.

Битмаб как вариант идет, а если их склеивать в один битмап? можно это програмно?

Можно. Читайте про методы класса BitmapData.

А есть ли вообще разница, перемещать один битмап или один спрайт с несколькими битмапами?

Есть. А также, есть разница при сложных векторных фигурах, есть разница при наличии фильтров на объектах, есть разница при mouseChildren = mouseEnabled = true, если пользователь проведет мышкой и т.д.

Правда? Запомнил, не думал, что даже это влияет. Хотя верно, диспатчит ведь кучу событий.

На счет того каким образом делать анимацию EnterFrame или Timer, что меньше нагружет?

Что реже вызывается, то и меньше грузит. Это не очевидно?

Визуальную анимацию ВСЕГДА лучше делать на EnterFrame. Этот ивент, в общем-то, для этого и предназначается. Таймер же в этом случае - лишний объект с лишними диспатчами ненужных ивентов.
В твоем случае лучше сделать один глобальный обработчик EnterFrame для stage, например, и в нем в цикле двигать все объекты. Если тормозит, можно попробовать снизить фреймрейт, но лучше удостовериться, что все объекты совершенно примитивны, то есть на них нет своих анимаций, не навешаны никакие листенеры, не прописаны никакие скрипты, не изменяется альфа и что все они cacheAsBitmap.

EnterFrame желательно использовать 1 на всех, а не каждому 1

Неправда, как вы сделаете, если нужно что-то двигать толчками или наоборот - очень быстро, быстрее, чем fps? А как вы сделаете анимацию по времени?

Циклом.

КорДум А зачем делать анимацию быстрее фреймрейта? Отрисуется же всё равно по фреймам.

Aquahawk
Скорее всего он имел ввиду смещение маленькими шагами на большие растояния. Не для анимация, а для определённых проверок. Например не пролетела ли пуля тоненькую стену.

Честно говоря, не понимаю пристрастия к таймеру для реализации анимации.
Таймер:
а. сможет послать событие только в общем потоке. Т.е. опять же после ENTER_FRAME.
б. вследствие этого не точен.

Единственный сомнительный смысл в нем, если он сможет выполниться несколько раз за фрейм. Но тут опять же:
а. придется вызывать updateAfterEvent, что форсирует и без того самую затратную операцию — рендеринг.

По мне у таймера есть единственное применение (причем прямо ему присущее): через n-е время послать событие, а уже по этому событию запускать анимацию и т.д.

Как-то так:
Если же надо проверять коллизии, то очевидно надо проверять не только текущее положение объекта, но и его траекторию между кадрами.

Что мешает заранее просчитать не пролетит ли пуля через тоненькую стенку. Без таймеров, реального смещения и всяческих хиттестов.

Угу, то, что отрисует по фреймам - это понятно. Но замедлить анимацию все же иногда нужно, например, по кадру в секунду для моргания какого-то светодиода.

Добавлено через 1 минуту
alatar, это как вариант имелся в виду ;)

Ну это уже не анимация, а смена состояния по событию.

Ладно, сдаюсь, не стреляйте :)

Пришёл злой дядя загрузил студентов :)
имхо Делать моргание светодиота всёже проще простой анимацией, если моргание не от чего не зависит.

Всем спасибо. Позновательная получилась тема. :)

Оно будет зависеть как минимум от EnterFrame, если будет проигрываеться как MovieClip. Если менять кадры по таймеру, например каждую секунду, то это по-сути смена состояния и разницы тут нет как у вас реализуется менеджмент состояний — кадрами в клипе или навороченным менеджером состояний. В любом случае. Если вам надо два кадра (лампочка горит / лампочка не горит) зачем делать еще 100500 одинаковых кадров и тратить ресурсы на их переключение?

alatar
Да вы правы, я об этом не думал. Тогда нужно поэксперементировать и выяснить, насколько проигрывание 500-тыщ мувиклипных светодиодов затратнее тех-же 500-тыщ но при помощи смены цвета скриптом из одного enterFrame например.

разве последний плеер не поддерживает аппаратное ускорение?

«Это фантастика, сынок.» ©

etc
Слуште а просветите плз, что такое апаратное ускорение ?

Тормозить будут оба варианта. Более эффективно, в подобных ситуациях, сделать два светодиода вкл/выкл и отрисовывать их в битмапу.

графику можно рисовать с помощью ЦПУ, а можно видеокартой. Последнее называют аппаратным 2д/3д ускорением

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

стабильная версия не поддерживает, я просто забыл что до беты обновлялся пару месяцев назад