Пиксель идеальное обнаружение коллизий в холсте HTML5
Я хочу проверить коллизию между двумя Спрайтами в холсте HTML5. Таким образом ради обсуждения, давайте предположим, что оба спрайта являются объектами IMG, и коллизия означает, что альфа-канал не 0. Теперь оба из этих спрайтов могут иметь вращение вокруг центра объекта, но никакое другое преобразование в случае, если это делает это немного легче.
Теперь очевидное решение, которое я предложил, будет этим:
- вычислите матрицу преобразования для обоих
- выясните грубую оценку области, где код должен протестировать (как смещение обоих + вычисленное дополнительное пространство для вращения)
- для всех пикселей в пересекающемся прямоугольнике преобразуйте координату и протестируйте изображение в расчетном положении (округленный ближайшему соседу) для альфа-канала. Затем аварийное прекращение работы на первом хите.
Проблема, которую я вижу с этим, состоит в том, что a) там не являются никакими матричными классами в JavaScript, что означает, что я должен сделать это в JavaScript, который мог быть довольно медленным, я должен протестировать на коллизии каждый кадр, который делает это довольно дорогим. Кроме того, я должен копировать что-то, что я уже должен сделать при рисовании (или что холст делает для меня, настраивая матрицы).
Интересно, пропускаю ли я что-нибудь здесь и если существует более легкое решение для обнаружения коллизий.
2 ответа
Мне нужно воспроизвести то, что я уже должен сделать при рисовании
Ну, вы могли бы создать новый контекст визуализации, нанести на него одну повернутую маску белого фона, установить операцию компоновки на светлее и нанесите другую повернутую маску сверху с заданным смещением.
Теперь, если остался небелый пиксель, значит попадание. Вам все равно придется getImageData и просеять пиксели, чтобы выяснить это. Возможно, вам удастся немного уменьшить эту рабочую нагрузку, уменьшив масштаб результирующего изображения вниз (полагаясь на сглаживание, чтобы некоторые пиксели оставались небелыми), но я думаю, что это, вероятно, все равно будет довольно медленным.
Мне приходится проверять на предмет столкновений каждый кадр, что делает это довольно дорого.
Да, я думаю, что реально вы собираетесь использовать предварительно рассчитанные таблицы столкновений. Если у вас есть место для этого, вы можете сохранить один бит попадания / отсутствия попадания для каждой комбинации спрайта a, спрайта b, относительного вращения, относительного x-нормализованного к вращению и относительного y-нормализованного к вращению. . В зависимости от того, сколько у вас спрайтов и сколько шагов вращения или движения, это может стать довольно большим.
Компромиссом было бы хранение предварительно повернутых масок каждого спрайта в массиве JavaScript (Number, что дает вам 32 бита / пикселя легко && -данных, либо в виде символа в Sring, что дает вам 16 бит) и && каждую строку пересекающихся масок спрайтов вместе.
Или откажитесь от пикселей и начните смотреть, например. пути.
Я не javascript-ковер, но я бы предположил, что те же трюки оптимизации работают так же хорошо для Javascript, как и для C++.
Просто поверните углы спрайта вместо каждого пикселя. Фактически вы будете делать что-то вроде программного отображения текстур. Вы можете выработать положение x,y данного пикселя, используя различную информацию о градиенте. Для получения дополнительной информации найдите программное сопоставление текстур.
Если бы вы разложили спрайт на области «попадания» и «не-хита», то вы могли бы эффективно проверить, является ли данное разложение четырехъядерного дерева «не-хитом», «всем хитом» или «возможным ударом» (т.е. содержит хиты и пиксели без хита). Первые 2 тривиальны для прохождения. В последнем случае вы переходите на следующий уровень разложения и повторяете тест. Таким образом, вы проверяете только те пиксели, которые вам нужны, и для больших областей «не-хита» и «хита» вам не нужно делать такой сложный набор проверок.
Во всяком случае, это всего лишь пара мыслей.