Ошибка в работе hitTest при rotation
 

Накопал ошибку hitTest, дает массу проблем.

Задача - двигать клип до пересечения с крестом (как точкой).

Рисуем квадрат 200х200, конвертируем в мувиклип, даем имя mc, помещаем в координаты x=75 y=0
Рисуем крест, конвертируем в мувиклип, даем имя cross, помещаем в центр экрана

В первый кадр помещаем код
Вот и все. Запускаем, работает. Раскомментируем строку *1 - не работает. Закомментируем строки *2, *3, работает, но "проваливается" на 1 шаг.
Резюме: если объект повернут, flash получает информацию о кривых его потрохов только после обновления экрана (fps). Если объект не повернут, или повернут на +/- 90 +/-180, то все хорошо; если повернут, то используется "старое" положение, т.е. информацию о площади шейпа от предыдущего просчета объектов. updateAfterEvent не помогает.

Идеи?
Рисовать объект drawing-ом не катит, т.к. объект должен быть рисованым ручками.

А как себя ведет BitmapData hitTest?

В финальной версии объект (квадрат в примере) будет _visible = false, кстати...

Нильс, у тебя же, в описании hitTest bitmap написано:
;)

Сначала надо снять с помощью draw скриншот с объекта, указав при этом вторым параметром матрицу с текущими траснформациями клипа, тогда все будет идентично. Вопрос только в производительности.

_visible=false, какой скриншот???
Пойду на flashkit жаловаться...

Знаешь, а поворот тут не причем, чуть сместил крест и без всяких поворотов, объект шустро в цикле проносится мимо. Вернул на старую позицию - опять работает.

BitmapData.draw(mc) не страдает, если mc._visible=false; Нормально все прорисовывает.

Ну так он запрограммирован двигаться под углом 45 через центр экрана, если он промахивается мимо креста, конечно он не остановится. В том и задача - доехать до тайлов, имеющих в себе опорные точки (кресты, условно говоря), и об них удариться, т.е. остановиться. Просто обнаружил, что при повороте объекта (а он разумеется будет повернут), flash ошибается в том шаге, где коллизия реально происходит.
Ты говоришь "чуть"? Укажи точные координаты и размеры, проверю.

bitmapData пользоваться не хочу, т.к. уверен в ее тормознутости. Скажем так, для обнаружения коллизии, я двигаю объект, тестю соударение, если оно есть - ищу ближайшую точку несоударения двоичным поиском, поэтому может быть 4-7 итераций за каждый fps для каждого движущегося объекта, что перебор...

Сделал исходник с примером.
Три объекта, двигаются по одной траектории и два объекта хит пойнта для хитТеста.

mc - проскакивает оба хит пойнта.

mc1 - хит тестится только с одним пойнтом cross и удачно срабатывает, однако, если хиттестить с cross1, то не работает.

mc2 - опять хит тестится с обоими хит пойнтами, но без цикла и останавливается при соприкосновении с cross

PS. Хм, в CS3 работает все как надо... А в standalone 9 опять косяки.

Да.
Все так.
У меня, например, клип нижней стороной проходил сквозь точку, а правой нет.
Бардак, уродство. :( hitTest не работает корректно с динамически измененым положением объекта. Тьфу :(

Хм. Интересная фигня. У меня еще такое вылезло — если заключить ваш код в onMouseDown:
тоже не работает. А без onMouseDown работает.

Вообще, работая с хитТестом лучше менять координаты, которыми тестишь, а не координаты мувика. Я для себя правилом сделал.
Типа так:
Хотя если помучить, можно и эту схему заставить криво работать. Хотя бы если заключить это все в onMouseDown.

Боюсь, придется мне переходить к объектам, "тело" которых строго прямоугольно :(:( Переводить координаты в систему коортинат тестируемого объекта, и проверять банально математически попадание в "тело". Очень паршивое ограничение.
Сейчас проверим, как работает в этом случае localToGlobal->globalToLocal Вроде, здесь я косяков не замечал, хотя уже ни в чем не уверен...

Ну, не обязательно банально математически, т.к. hitTest с shapeFlag-ом false нормально работает.

Тоесть как бы вообще без глюков и динамично. Правда сравнивается тогда boundingBox, которая не поворачивается, а расширяется.
Если нужны повороты, тогда да, математически нужно.

Помните тему Флэш забивает на прорисовку мувиков с координатой > 4005 ?
Третий синтаксис hitTest, по-видимому имеет серьезные ограничения и работает именно на принципе прорисовки мувика битмапой.
Поэтому в цикле внутри одного кадра он и не ловит. Наверное внутри одного кадра (одного перехода головки) надо использовать первый синтаксис hitTest.

crazyone
Ну если уж потеря формы, т.е. shapeFlag=false, то нафиг он такой нужен hitTest, я и сам четыре проверки написать способен. Тем более, что объект повернут, а flash любит брать ортогональные bounding box (bb), знаем мы его штуки. Тогда и клип-тело не придется делать, он тогда совсем не нужен, достаточно чисел bb.
(ну вот, пока я писал, ты сам сообразил насчет поворотов)

chingachgoog
Очень может быть... было бы только об этом где-то написано... Я два дня рабочего убил, прежде чем заподозрил "не мою ошибку"...

Раз уж начал жаловаться - а еще меня убивает тормознутость округления в flash... Я чуть не опух, когда выяснил, что примерно 50% вычислительной мощности в моем проекте уходит на округление чисел. Т.е. когда я закомментил округления, время выполнения главного такта программы уменьшилось вдвое, правда, перестало работать корректно ;)

К слову, x >> 0 работает быстрее, чем Math.floor (x)

Это я знаю, но меня интересует округление с нужной точностью, т.е. Math.round(x*pr)/pr
Кроме того, сдвиг работает не так с отрицательными значениями
trace (-5.6 >> 0) ===> -5
trace (Math.floor(-5.6)) ===> -6

Я не знаю полной картины, но в тесте, что в аттаче, битмап существенно шустрее.
Это обычный хиттест
Потом раскомментируй строчку с hitTestNew для битмпавского хиттеста и сравни загрузку процессора.

Занятно...
Даже не знаю, что сказать... Буду нюхать...