Учитесь & развитие Игры Владельца Кокос2д

Это продолжает и завершает предыдущую почту Быстрого Прекрасного пикселом Обнаружения столкновений для Cocos2D с Примером кода (1/2) статья.

Тестирование на отдельный пункт просто, проверяя на прямоугольник, такой как ограничивающий прямоугольник другого узла требует большего количества работы. Не только, чтобы написать кодекс, но также и управлять этим. И это ограничено узлами, которые ни не вращаются, ни измерены. And it is limited to nodes which are neither rotated nor scaled.

К сожалению, тестирование столкновений с вращаемыми прямоугольниками (ориентируемый на ограничивающие прямоугольники) не тривиально даже, не рассматривая pixelMask столкновения. Вот C ++ OBB и C # OBB выполнение для обнаружения столкновений OBB. И это только для ограничивающих прямоугольников, проверяя каждый пиксел в ориентируемой маске пиксела, вероятно, был бы предельно дорог. And that’s just for the bounding boxes, testing each pixel in an oriented pixel mask would likely be prohibitively expensive.

Вы определенно хотите избежать метода грубой силы, который повторяет по всему множеству pixelMask. Вместо этого это выполнение сначала создает пересекающийся прямоугольник pixelMask узла и другого узла, тогда только повторяет по пересечению, чтобы значительно сократить количество повторений:

Нужно отметить, что мы только должны найти, что один pixelMask укусил, который установлен. Это означает, что этот метод мог быть далее оптимизирован во множестве путей, которые гарантируют, что пиксел, более вероятно, будет найден ранее.

Например можно утверждать, что ближе в центр pixelMask вероятность pixelMask укусила установленные увеличения. Это означает в зависимости от местоположения intersectionRect, который повторение по pixelMask можно было щипнуть, чтобы начать ближе в центр pixelMask и проложить себе путь за пределы. Но эта оптимизация зависит в большой степени от используемых изображений, и некоторым простираются, как объекты перемещаются. But this optimization depends heavily on the images being used and to some extend how the objects move.

Худший вариант развития событий - то, что нет никакого набора сверл в pixelMask для данного intersectRect. Зная, что, можно было бы считать повторение по pixelMask не BOOL BOOL, но поиском полный 32-битовый NSUInteger (4 BOOL сразу) от pixelMask. Если та 32-битовая ценность 0, то ни один из 4 битов столкновения не может возможно быть установлен, сокращая количество тестов и повторений от 4 до 1. Только если ценность больше чем 0, Вы должны были бы проверить, что каждый отдельный pixelMask укусил. Используя BitArray Вы могли проверить до 32 битов сразу подобным способом. If that 32-Bit value is 0, then none of the 4 collision bits can possibly be set, reducing the number of tests and iterations from 4 to 1. Only if the value is greater than 0 you would have to check each individual pixelMask bit. Using a BitArray you could test up to 32 bits at once in a similar fashion.

Беглый взгляд на intersectRectInPixels метод показывает, что это создает пересекающийся прямоугольник ограничивающих прямоугольников двух сталкивающихся узлов. Важный, чтобы отметить вот то, что происхождение пересекающегося прямоугольника должно быть преобразовано в nodeSpace первого узла и затем преобразовано в пикселы, чтобы удостовериться, что это работает с изображениями HD.

Возможность передать два узла к этому методу позволяет пересечь прямоугольнику быть вычисленным для обоих сталкивающихся узлов. Это необходимо затем, когда мы определяем столкновение двух возможно пересекающихся KKPixelMaskSprite.

Это - только относительно маленький шаг, идущий от pixelMask с пересечением прямоугольника к тестированию двух pixelMasks для пересечения (наложение может быть лучшим словом здесь). Снова, Вы не должны использовать грубую силу – достаточно проверить перекрывание (пересечение) прямоугольник этих двух эльфов. Снова этот тест не работает с вращаемыми или чешуйчатыми прямоугольниками, но это - недостаток, который приносит пользу исполнению теста. Again this test doesn’t work with rotated or scaled rectangles but it’s a drawback that benefits the performance of the test.

По сравнению с предыдущим тестом прямоугольника пересекающийся прямоугольник другого сталкивающегося KKPixelMaskSprite был добавлен и ссылка на otherPixelMask наряду с другими припрятавшими про запас ценностями в линиях 4-9. Суть функции все еще выполняет тот же самый тест вплоть до линии 22. Вместо того, чтобы возвратить первый бит, который установлен в pixelMask, мы должны удостовериться, что этот бит также установлен в otherPixelMask. Instead of returning the first bit that is set in the pixelMask, we have to make sure that this bit is also set in the otherPixelMask.

Так как индекс в otherPixelMask может быть легко вычислен, возмещая это с происхождением intersectOther прямоугольника, мы только должны произвести новый индекс для того же самого x, y координаты, но относительно системы координат другого KKPixelMaskSprite. Линии 26 и 27 выполняют ту операцию, используя предрасчетный originOffset от линий 6 и 7. В основном это возмещает x, y координаты к тому же самому местоположению в пределах прямоугольника пересечения другого эльфа. То, что остается, преобразовывает координаты в индекс и проверяет, если бит otherPixelMask в том индексе также установлен. Если так, у нас есть столкновение. In essence this offsets the x,y coordinates to the same location within the other sprite’s intersection rectangle. What remains is converting the coordinates to the index and testing if the otherPixelMask bit at that index is also set. If so, we have a collision.

Есть один метод, который я до сих пор не учитывал. Это - общественный метод интерфейса, который назовут пользователи KKPixelMaskSprite. Это выступает, несколько ранние проверяют и также выбирают правильный тест, чтобы выступить основанный на классе другого узла. It performs several early out tests and also picks the right test to perform based on the class of the other node.

Я упоминал прежде, который тесты пересечения не работают с вращаемыми или чешуйчатыми узлами. В этом случае метод немедленно возвращается НЕ и регистрирует это, чтобы избежать кого-то расстраивание, потому что тесты “не всегда работают”. Также сэкономить меня много таких вопросов. Also to spare me many such questions.

Конечно, пересечение проверяет, только имеют смысл, если ограничивающие прямоугольники пересекаются. intersectsNode метод - функция удобства, которую Вы найдете в Kobold2D, и в классе CCNodeExtensions добавленный к проекту.

pixelMask против теста pixelMask только выполнен, если другой узел - также KKPixelMaskSprite во всех других случаях, прямоугольник, пересекающийся pixelMask тест, выполнен вместо этого. Переменная PixelMaskSpriteClass - статическая переменная, калибровавшая в init методе как [сам класс] просто, потому что, посылая сообщение класса каждый раз немного расточителен по сравнению с 4 байтами дополнительной памяти для переменной PixelMaskSpriteClass.

Тестирование пересечения двух эльфов, или KKPixelMaskSprite или нет, столь же просто как письмо:

Теперь к интересному вопросу: если BitArray в состоянии уменьшить использование памяти до 1/8-ого (12.5 %), это также быстрее? Позвольте мне показывать это, поскольку графика, полученная, выполняя pixelMask против pixelMask, проверяет несколько сотен тысяч раз неоднократно, и измеряя полную продолжительность: Let me reveal this as a graphic obtained by performing the pixelMask vs pixelMask check several hundred thousand times repeatedly, and measuring the total running time:

Другими словами: это - обмен между использованием памяти и работой во время выполнения. Тесты пересечения маски пиксела на 27 % медленнее на iPod 4, и на 18 % медленнее на iPhone 3 г, используя BitArray. И на всякий случай Вы задаетесь вопросом: если Вы должны были использовать UInt16 или даже множество UInt32 вместо множества BOOL, Вы будете видеть очень незначительное уменьшение в работе (меньше чем 5 %), но удваивать соответственно четыре раза использование памяти. Pixel mask intersection tests are 27% slower on an iPod 4, and 18% slower on an iPhone 3G when using the BitArray. And just in case you’re wondering: if you were to use a UInt16 or even UInt32 array instead of the BOOL array you’ll see a very minor decrease in performance (less than 5%) but double respectively four times the memory usage.

Сочиняя класс KKPixelMaskSprite я обнаружил много комнаты для усовершенствования. Я не хочу экономить Вас список, потому что он также показывает некоторые недостатки класса, что я думаю, что Вы должны знать. Если Вы действительно осуществляете одно из этих усовершенствований, пожалуйста, разделите их, и если возможный разделите их в соответствии с разрешающей лицензией, такой как Массачусетский технологический институт. If you do implement one of these improvements please share them, and if possible share them under a permissive license such as MIT.

• тайник pixelMasks, например в единичном предмете CCPixelMaskCache, или добавляет их к CCTexture2D
• позвольте создание маски пиксела с имен spriteframe или spriteframes
• позвольте тесты столкновения, если эльф вращается точно к 90, 180 или 270 степеней
• позвольте использование невласти двух изображений для pixelMasks на 1-ых/2-ых устройствах поколения
• позвольте столкновения между SD и эльфами изображения HD

• уменьшите pixelMask размер, объединяясь 2×2, 3×3, 4×4, и т.д. пикселы в единственный бит
• ИЛИ: только используйте изображения SD для pixelMask, вызывая столкновения на устройствах Сетчатки указать границы
• оптимизируйте повторения, проверяя UInt32 (4x BOOL) или многократные Биты сразу для ценности> 0
• оптимизируйте повторения, начиная повторять от угла, самого близкого к центру

В особенности оптимизация, чтобы уменьшить pixelMask размер, комбинируя многократные пикселы, должно оказаться, очень эффективна, и относительно легка осуществить. Большинство прекрасных пикселом столкновений не должно действительно быть прекрасным пикселом, достаточно близкое приближение более чем достаточно для большинства заявлений. В особенности на устройствах Сетчатки никакой игрок не будет в состоянии разобрать, точны ли не так пиксел прекрасные столкновения только в пределах два, три, или возможно даже больше пикселов. Самый простой подход должен был бы только рассмотреть только изображения SD для масок пиксела, даже на устройствах Сетчатки. Добавленное преимущество, являющееся, что меньший pixelMask равняется меньшему количеству повторений и таким образом более быстрых тестов столкновения. In particular on Retina devices no player will be able to make out if the not-so-pixel-perfect collisions are accurate only within two, three, or possibly even more pixels. The simplest approach would be to just consider only the SD images for pixel masks, even on Retina devices. The added advantage being that a smaller pixelMask equals fewer iterations and thus quicker collision tests.

Загрузите проект демонстрационного примера KKPixelMaskSprite!

Этот проект также доступен на моем github складе, где я принимаю весь iDevBlogADay исходный код.

Это - моя последняя должность iDevBlogADay перед Рождеством. Это является очень большим, дополнительное хрустящий, покрытый шоколадом, запахами как корица, вкусами как яблоки и грецкие орехи и соус и печенье и индейка, и запрещено в США, потому что это содержит несъедобные пикселы и является задыхающейся опасностью для всех, кто намеревается прочитать это сразу.

В этом смысле, Веселое Рождество все!