Aprenda & desarrollo de Juego de Maestro Cocos2D

Esto sigue y concluye el correo anterior del Descubrimiento de Colisión perfecto por el Pixel Rápido para Cocos2D con el Ejemplo de código (1/2) artículo.

Las pruebas para un punto individual son simples, probando de un rectángulo, como el cuadro delimitador de otro nodo requiere más trabajo. No sólo para escribir el código, sino también dirigirlo. Y es limitado con nodos que son ni hechos girar, ni escalados. And it is limited to nodes which are neither rotated nor scaled.

Lamentablemente, las pruebas de colisiones con rectángulos hechos girar (cuadros delimitadores orientados) no son triviales hasta sin considerar colisiones pixelMask. Aquí está un C ++ OBB y un C # OBB realización para el descubrimiento de colisión OBB. Y esto es sólo para los cuadros delimitadores, probando cada pixel en una máscara de pixel orientada sería probablemente prohibitivamente caro. And that’s just for the bounding boxes, testing each pixel in an oriented pixel mask would likely be prohibitively expensive.

Usted definitivamente quiere evitar un método de fuerza bruta que itera sobre la serie de pixelMask entera. En cambio, esta realización primero crea el rectángulo que se cruza del nodo pixelMask y el otro nodo, entonces sólo itera sobre la intersección para reducir bastante el número de iteraciones:

Hay que notar que sólo tenemos que encontrar que un pixelMask mordía lo que es puesto. Esto significa que este método podría ser optimizado adelante en una variedad de caminos que aseguran que un pixel con mayor probabilidad será encontrado antes.

Por ejemplo puede sostenerse que más cerca al centro del pixelMask la probabilidad de un pixelMask mordía aumentos pondrás. Esto significa según la posición del intersectionRect la iteración sobre el pixelMask podría ser pellizcada para comenzar más cerca al centro del pixelMask y trabajo su camino hacia fuera. Pero esta optimización depende pesadamente de las imágenes usadas y a unos se extienden como los objetos se mueven. But this optimization depends heavily on the images being used and to some extend how the objects move.

El peor de los casos es que no hay ningún juego de brocas en el pixelMask para intersectRect dado. Sabiendo que, uno podría considerar la iteración sobre el pixelMask no BOOL por BOOL, pero buscando NSUInteger de 32 bites lleno (4 BOOL inmediatamente) del pixelMask. Si aquel valor de 32 bites es 0, entonces ninguno de los 4 trozos de colisión puede ser posiblemente puesto, reduciendo el número de pruebas e iteraciones de 4 a 1. Sólo si el valor es mayor que 0 usted tendría que comprobar que cada pixelMask individual mordía. Usando BitArray usted podría probar hasta 32 trozos inmediatamente de una moda similar. 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.

Un vistazo en el método intersectRectInPixels revela que crea el rectángulo que se cruza de los cuadros delimitadores de los dos nodos que chocan. Importante para notar aquí está que el origen del rectángulo que se cruza debe ser convertido a nodeSpace del primer nodo y luego convertido a pixeles para asegurarse que esto trabaja con imágenes HD.

Ser capaz de pasar dos nodos a este método permite que el rectángulo cruzar sea calculado para ambos nodos que chocan. Esto es necesario después, cuando determinamos la colisión de dos KKPixelMaskSprite que se cruzan posiblemente.

Es sólo un relativamente pequeño paso que va de pixelMask con la intersección de rectángulo a pruebas de dos pixelMasks para la intersección (el traslapo puede estar una mejor palabra aquí). Otra vez, usted no tiene que usar la fuerza bruta – es suficiente comprobar el traslapo (cruce) el rectángulo de los dos elfos. Otra vez esta prueba no trabaja con rectángulos hechos girar o escalados pero es un inconveniente que beneficia la realización de la prueba. Again this test doesn’t work with rotated or scaled rectangles but it’s a drawback that benefits the performance of the test.

Comparado con la prueba de rectángulo anterior, el rectángulo que se cruza de otro KKPixelMaskSprite que choca fue añadido y una referencia a otherPixelMask junto con otros valores escondidos en líneas 4-9. La idea esencial de la función todavía realiza la misma prueba hasta la línea 22. En vez de devolver el primer trozo que es puesto en el pixelMask, tenemos que asegurarnos que este trozo también es puesto en el 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.

Ya que el índice en el otherPixelMask puede ser fácilmente calculado compensándolo con el origen del rectángulo intersectOther, sólo tenemos que generar un nuevo índice para mismo x, y coordenadas, pero con relación al sistema coordenado de otro KKPixelMaskSprite. Las líneas 26 y 27 realizan aquella operación usando originOffset predeliberado de líneas 6 y 7. En la esencia esto compensa el x, y coordenadas a la misma posición dentro del rectángulo de intersección del otro elfo. Lo que permanece convierte las coordenadas al índice y prueba si el trozo de otherPixelMask en aquel índice también es puesto. De ser así, tenemos una colisión. 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.

Hay un método que excluí hasta ahora. Es el método de interfaz público que los usuarios de KKPixelMaskSprite llamarán. Esto funciona varios tempranos prueban y también escogen la prueba correcta para funcionar basado en la clase del otro nodo. It performs several early out tests and also picks the right test to perform based on the class of the other node.

Mencioné antes que las pruebas de intersección no trabajan con nodos hechos girar o escalados. En este caso el método inmediatamente no vuelve y registra esto para evitar a alguien que se hace frustrado porque las pruebas “no siempre trabajan”. También ahorrarme muchas tales preguntas. Also to spare me many such questions.

Por supuesto la intersección sólo prueba tienen sentido si los cuadros delimitadores se cruzan. El método intersectsNode es una función de conveniencia que usted encontrará en Kobold2D, y en la clase de CCNodeExtensions añadido al proyecto.

El pixelMask contra la prueba de pixelMask sólo es realizado si el otro nodo también es KKPixelMaskSprite, en todos otros casos el rectángulo que se cruza pixelMask prueba es realizado en cambio. La variable de PixelMaskSpriteClass es una variable estática inicializada en el método init como [mí clase] simplemente porque el envío del mensaje de clase cada vez es un poco pródigo comparado con 4 bytes de la memoria adicional para la variable de PixelMaskSpriteClass.

Las pruebas de la intersección de dos elfos, o KKPixelMaskSprite o no, son tan simples como la escritura:

Ahora a una pregunta interesante: ¿si BitArray es capaz de reducir el uso de memoria al 1/8vo (el 12.5 %), es también más rápido? Déjeme revelar esto ya que un diseño obtenido realizando el pixelMask contra pixelMask comprueba varios cientos de miles de tiempos repetidamente, y midiendo la duración total: 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:

En otras palabras: es una compensación entre uso de memoria y rendimiento de tiempo de ejecución. Las pruebas de intersección de máscara de pixel son 27 % más lentas en un iPod 4, y 18 % más despacio en un I-Phone 3G usando BitArray. Y por si acaso usted se pregunta: si usted debiera usar un UInt16 o hasta serie de UInt32 en vez de la serie de BOOL usted verá una disminución muy menor en el rendimiento (menos del 5 %), pero doblará respectivamente cuatro veces el uso de memoria. 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.

Escribiendo la clase de KKPixelMaskSprite descubrí mucho cuarto para la mejora. No quiero ahorrarle la lista porque también revela algunos defectos de la clase que creo que usted debería ser consciente de. Si usted realmente pone en práctica una de estas mejoras por favor compártalos, y de ser posible compártalos según una licencia permisiva, como el MIT. If you do implement one of these improvements please share them, and if possible share them under a permissive license such as MIT.

• el escondite pixelMasks, por ejemplo en una cosa única de CCPixelMaskCache, o los añade a CCTexture2D
• permita la creación de máscara de pixel de nombres de spriteframe o spriteframes
• permita pruebas de colisión si el elfo es hecho girar a exactamente 90, 180 o 270 grados
• permita el uso del no poder de dos imágenes para pixelMasks en 1ros/2dos dispositivos de generación
• permita colisiones entre Dakota del Sur y elfos de imagen HD

• reduzca la talla pixelMask combinándose 2×2, 3×3, 4×4, etc. pixeles en un trozo solo
• O: sólo use imágenes de Dakota del Sur para pixelMask, forzando colisiones en dispositivos de Retina señalar límites
• optimize iteraciones probando UInt32 (4x BOOL) o Trozos múltiples inmediatamente para el valor> 0
• optimize iteraciones comenzando a iterar de la esquina el más cercana al centro

En particular la optimización para reducir la talla pixelMask combinando pixeles múltiples debería resultar ser muy eficiente, y es relativamente fácil a poner en práctica. La mayoría de las colisiones perfectas por el pixel realmente no tienen que ser perfectas por el pixel, una aproximación bastante cercana es más que bastante para la mayor parte de aplicaciones. En particular en dispositivos de Retina ningún jugador será capaz de distinguir si el no tan el pixel las colisiones perfectas sólo son exactas dentro de dos, tres, o posiblemente hasta más pixeles. El enfoque más simple debería considerar sólo sólo las imágenes de Dakota del Sur para máscaras de pixel, hasta en dispositivos de Retina. La ventaja añadida que es que pixelMask más pequeño iguala menos iteraciones y así pruebas de colisión más rápidas. 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.

¡Descargue el proyecto de demostración de KKPixelMaskSprite!

Este proyecto también está disponible en mi depósito github donde recibo todo el código fuente iDevBlogADay.

Esto es mi último puesto de iDevBlogADay antes de Xmas. Es extra grande, extra crujiente, cubierto en chocolate, olores como la canela, gustos como manzanas y nueces y salsa y galletas y pavo, y es prohibido en los EE. UU porque esto contiene pixeles no comestibles y es un riesgo sofocante para cada uno que tiene la intención de leerlo en uno va.

¡En aquel sentido, Merry Xmas cada uno!