Обнаружение столкновений
 

Вот сделал свой "хитТест". Клипы, которые на сцене рисуются в битмапу. Главный клип имеет определенное наложение (blendMode) вследствие чего можно установить имеется ли пересечение. Плюсы: можно сложные объекты проверять на столкновения - не надо якоря внутрь засовывать; быстродействие.
Имеются методы:
Collision.dinamicChecking (mc:MovieClip, arr:Array) - если объекты, с которыми планируется обнаружение столкновения будут перемещаться.
Collision.staticChecking (mc:MovieClip, arr:Array) - если объекты не будут перемещаться - экономит производительность.
mc - главный клип
arr - массив клипов-препятствий
Для остановки обнаружения столкновений есть метод:
Collision.stopChecking ();

Эх, ожидал увидеть большего :( Слова
Там нет в помине - только начинаю передвигать - фпс падает раза в 4.
К сожалению на зачет не тянет. Подходит только для единичного обнаружения столкновений, да и то - имхо математикой в 90% случаев будет гораздо быстрей.

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

Здесь нет хиттеста - всего лишь две битмапы, в которые рисуются объекты. Поэтому если скажем будет 1 или 100 объектов - это не будет влиять на скорость. А математикой будет быстрее, если объектов немного.
Странно - на моем не самом современно компьютере бегает довольно шустро. Тем более странно, что фпс начинает падать при передвижении - расчет происходит постоянно - стоит ли на месте мувик или движется.

Сделайте пример с кучей объектов, не думаю, что отрисовка будет быстрей математики.

Мой метод позволяет найти пересечение, там где не поможет математика и hitTest (). Например, чтобы найти пересечение вот таких фигур обычным хиттестом, надо в какаю-нибудь одну засунуть множество якорей и для каждого искать столкновения. А если надо будет изменить форму этой фигуры? Про математику я вообще молчу.

Вот результаты работы класса.
Файл "0" - расчет не ведется.
Файл "100" - на сцене 1 клип, который можно перемещать мышью - ведется расчет на обнаружение столкновений со ста объектами.
Файл "1000" - на сцене 1 клип, который можно перемещать мышью - ведется расчет на обнаружение столкновений с тысячью объектами.
Как видно - посередине сцены движется клип - можно по нему отследить падение FPS. Скорость передвижения одинаковая во всех случаях.
На моем скромном компьютере (Athlon XP 2000+ 1,66 МГц) наблюдается небольшое падение производительности в третьем файле (где 1000 объектов).

ппц...по сети гюляет уже давно абсолютно такой же по логике метод(рисование в битмапу с блендом дифференс) только реализованый куда быстрей(ну развечто только для статики там нету метода с копированием уже зарисованой битмапы)

И? По твоей логике зачем вообще выкладывать сайты не проффесионалам, если професиональные фирмы уже давно сделали сайт лучше?
Волгоградец сделал этот скрипт и попросил оценить, указать баги и прочее, он совершенствуется. По твоей логике, зачем вообще жить, если кто то уже давно прожил, а?

To Волгоградец: кхм... 1000 обьектов, кое как открылось, но тормозов замеченно не было. я тут подумал.. чтобы убрать тормоза в твоем примере, попробуй:
1) проверять соприкосновение баундинг боксов - если их нету, смысла проверять тоже нету - 80% времени быстродействие возрастет в сотни раз
2) если и соприкосается, то нужно определить, с какой четвертью пересекается. То есть, если обьект выше и левее чем центр другого обьекта, то он полюбому если и пересекается, то именно с левой верхней четвертью. Если мне не изменяет память, чем меньше битмап, тем быстрее он будет работать.
3) Ну, уже непосредственно ищем пересечения твоим методом.

Лучше сразу четвертовать это изображение и хранить все неизменяемые переменные в памяти.
Preprocessing, (c) N authors