|
|
|||||
Banned
[+1 05.11.11]
[+1 09.08.11] Регистрация: Jan 2010
Адрес: РФ. Кемеровская область
Сообщений: 3,243
|
Можно вообще извратиться, и сделать нечто подобное отслеживанию движения через веб камеру, с помощью BlendMode.DIFFERENCE определять изменившийся регион )
|
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Если бы это было "оно", Вам бы уже давно сказали. Событие RENDER диспатчится, когда флэш-плеер собирается перерисовать картинку (стейдж). Не более того. Он просто предупреждает (тех кто подписался) - "сейчас буду перерисовывать, кто не спрятался – я не виноват!". Его используют для инвалидации. Например, у вас есть какой-то объект кастомного класса, у которого есть несколько сеттеров для параметров (возьмем здесь – параметров внешнего вида). Применение любого из этих сеттеров требует значительного пересчета и перераспределения внутренних объектов, и их перерисовки. Теперь представьте, что вы задаете подряд несколько изменений - новые width, height, и еще какие-то кастомные свойства, меняющие вложенные объекты. На каждый вызов сеттера происходит изменение и перерисовка. Сначала для width, потом для height, потом еще что-то. Все это требует уймы лишних действий. При инвалидации вы сохраняете полученные сеттерами значения в их storage-переменные, но НЕ производите пересчет, пока не плеер не скажет - "RENDER". Только получив это событие, вы обрабатываете все новые данные скопом. Например, рисуете прямоугольник фона СРАЗУ с новым width, новым height, alpha и color. А не перерисовываете его при изменении КАЖДОГО из этих свойств по-отдельности. В этом смысл получения стандартного события RENDER.
__________________
Reality.getBounds(this); |
|
|||||
Небольшой стеб по теме.
И так, решение задачи. Каждый кадр записываем в битмапу содержимое stage-а, при наступлении следующего кадра - сверяем новую битмапу с предыдущей попиксельно. При отсутствии отличий - удаляем новую битмапу и ждем следующий кадр. При наличии отличий - определяем координаты, где были внесены изменения, по ним вычисляем все возможные объекты. У них сверяем координаты и размеры. Если все осталось на своих местах - поступаем аналогично как для stage. При наличии несоответствий - диспатчим событие. При таком раскладе ФП наверное и секунды не протянет ))))
__________________
Ну все, теперь Забава м-о-я. Гы-гы, а корабль мой! |
|
|||||
TanaTiX
Как быть если песочница не позволяет делать снимки с объекта? Отображается или нет можно проверить через переменную .stage объекта.
__________________
RTFM |
|
|||||
.
|
Только математика. Перерисовка не происходит. Случай с graphics тоже считаю математикой. С остальным согласен. Если математика сложная, то каждый вызов будет приводить к напрасным тратам ресурсов вплоть до снижения FPS.
|
|
|||||
Banned
[+1 05.11.11]
[+1 09.08.11] Регистрация: Jan 2010
Адрес: РФ. Кемеровская область
Сообщений: 3,243
|
TanaTiX, почти тот же стеб, что предложил я с бленд модом )
|
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Цитата:
То есть вот вызывается сеттер width и в нем вызываются методы графикс, например drawRect, с этим новым width. Затем так же вызывается сеттер height и снова перерисовка в графиксе. Я вот не уверен, что в результате отрисовка изображения при смене "кадра" будет выполнена только один раз. Я думаю, будут выполнены все команды отрисовки в стеке. А ведь рисование это далеко не всегда один квадратик))) В сумме с возможно очень даже немалыми расчетами (в случае например тригонометрии - секторов, полярных координат и тп) такие лишние отрисовки дают немалую задержку.
__________________
Reality.getBounds(this); |
Часовой пояс GMT +4, время: 12:35. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|