Кто-нибудь испытывал побочные эффекты (в том числе проблемы с производительностью) при использовании getObjectsUnderPoint?

Question

Прежде чем я сделаю серьезные изменения в своем текущем игровом проекте, я просто хочу услышать от других, если кто-нибудь обнаружил какие-либо проблемы с функцией getObjectsUnderPoint () DisplayObject?

Обновление: Не только проблема с производительностью, но и любые другие ограничения его использования (например, он не обнаруживает определенный тип элементов UI (как в примере))

У меня будет три слоя в приложении (изометрическая игра)

• Фон - это просто фон, который находится внизу, не имеет никакого отношения к игре
• Средний слой - это игровая зона, здесь все мои игровые элементы будут размещены на этом слое
• Верхний слой - это один фиктивный прозрачный слой, покрывающий всю воспроизводимую область, который прерывает все события мыши. Здесь я хочу использовать getObjectsUnderPoint ()

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

На самом деле это не обязательно делать таким образом, потому что я мог бы просто добавить события moues для всех этих элементов, непосредственно размещенных на карте, а потому, что я все равно использовал бы getObjectsUnderPoint (), чтобы проверить, есть ли что-нибудь под элементом.

Если кто-нибудь сможет объяснить, как работает эта функция, мне будет нелегко принять решение.

Answer 1

Была одна досадная проблема. Я не знаю, исправили ли они это или нет. По крайней мере, это было в 10,1 раза.

Если у вас есть контейнер и вы его масштабировали, container.getObjectsUnderPoint вернет неправильный результат. Все время. Поэтому везде, где мне нужно было getObjectsUnderPoint, мне приходилось звонить с stage, чтобы получить правильный результат.

Answer 2

Это неполная функция.Он возвращает графические объекты под мышью, а НЕ все потенциальные цели мыши для событий или взаимодействий.На самом деле требуется сложная логика для проверки массива, возвращенного getObjectsUnderPoint, чтобы определить цель мыши, потому что подходящей цели (одна Flash выберет, если вы действительно нажали эту точку) может не быть в списке.

Сначала выпришлось бы проверять массив объектов в обратном порядке, так как элементы упорядочены задом наперед.Вы должны изучить всю родительскую цепочку каждого объекта, ища родителя с mouseChildren = false, который заставил бы его перехватить событие и стать целью.Независимо от того, найден такой объект или нет, у этого конечного объекта, к которому вы пришли, должно быть установлено свойство true для свойства mouseEnabled, в противном случае вы должны пропустить его и перейти к следующему объекту в массиве, который будет, например, следующим спрайтом.или форма позади той, которую вы изначально проверили.Проходя по списку, вы должны заметить, когда меняется родитель, и в этот момент вы должны предположить, что у всех потомков этого общего родителя свойство mouseEnabled имеет значение false, и в этом случае родитель станет следующим кандидатом.На самом деле это чрезвычайно сложно, потому что вы работаете в обратном направлении снизу вверх с неполным набором объектов, созданным сверху вниз.

Чтобы получить реальные потенциальные цели событий мыши, в соответствии с логикой диспетчеризации по умолчанию ... на самом деле проще начать со сцены сверху вниз и пройти назад по иерархии отображения в глубину-сначалапоиск, проверка mouseChildren, чтобы определить, нужно ли вам вступать в дочерние процессы, и проверка mouseEnabled, если она является целью, в противном случае заходите в дочерние элементы контейнера и повторяйте процесс снова и снова.Это гораздо точнее, полнее и проще.Единственная проблема заключается в том, что вы должны сами ее кодировать.