fast_collision

[Windgate]

Los que hemos trabajado en proyectos 2D con gran cantidad de procesos activos sabemos que collision (type xxx) supone un consumo de memoria excesivo, ya que collision tiene en cuenta la geometría de todo proceso de tipo xxx, incluyendo transparencias, p.ej. un donut no detecta colisiones en su centro.

He estado trabajando con las "collision" en 3D y en ellas se asigna una geometría básica a cada elemento para que la detección de colisiones sea aproximada y se consuman muuuchos menos recursos.

Mi sugerencia es un mecanismo de detección de colisiones en 2D que no atienda a transparencias, sino simplemente a la anchura y altura de los gráficos implicados.

Por ejemplo, para una bala consumiría mucho menos ignorar la información de transparencias, incluso sería deseable poder interpretar colisión rápida en el detector, en el objetivo o en ambos a la vez.

¿Qué opináis? El código de collision no debería ser muy difícil de modificar ya que se trataría de eliminar código más que añadirlo :P

[DjSonyk]

Humm a priori y sin mirar el codigo ,pienso que le metodo es el de siempre el mascaras, sin ser el mas rapido es el mas preciso, pero otra forma es la utilizada bastante el los juegos 2JME rectangulizar el grafico en rectangulos pequeños y comprobar sin chocan ignorando los colores que chocan,(transparentes,simi,ect),pero vamos que ese metodo para los moviles esta bien pero para ...... me parece una chapuza....

[l1nk3rn3l]

me parece una buena sugerencia para un nuevo modulo..

[panreyes]

He visto el código fuente, y creo que se podría mirar de mejorar la colisión que tenemos.
Por ejemplo, no comprobar procesos que, por el tamaño del gráfico, size, size_x, size_y y la posición de estos, es seguro que no colisionan. Eso mejorará el rendimiento en muchos casos, creo.

[DjSonyk]

Para ello se deveria comprobar la distancia/posicion entre ellos,lo cual lo que se gana por un lado se pierde por otro...

[Windgate]

La ineficiencia de collision es absoluta, pero si se quieren detectar colisiones bien detectadas no queda otra...

Para juegos con masificación de procesos se hace necesario tener una matriz a modo de tablero y comprobar en las celdas adyacentes, collision es inviable.

La collision ( ) actual está bien como está, yo propongo "otra" fast_collision que únicamente atienda a anchura y altura de los gráficos. Gracias por mirarlo PiXeL, he tenido tiempo para pensar pero no para echar un vistazo... Lo haré

[Drumpi]

Hombre, si no tenemos en cuenta "angle", con una simple resta de las coordenadas entre los procesos que interactúan basta, es más, en muchos casos bastará con hacer una única resta, porque al no tener una misma coordenada vertical ¿para qué mirar la horizontal?

De todas formas, ya se habló de las "collision_box", no recuerdo en qué se quedó, si era algo pendiente de añadir en el módulo correspondiente, si ya estaba implementado en el código...

[SplinterGU]

He visto el código fuente, y creo que se podría mirar de mejorar la colisión que tenemos.
Por ejemplo, no comprobar procesos que, por el tamaño del gráfico, size, size_x, size_y y la posición de estos, es seguro que no colisionan. Eso mejorará el rendimiento en muchos casos, creo.

Pix, esos tipos de chequeos ya estan incorporados... y se evita hacer el calculo si los graficos no chocan por coordendas...

vamos a ver... el colision actual, es preciso, por pixels... esta en plan desde hace tiempo otros tipos de colisiones... circulares, rectangulares, etc...

[SplinterGU]

Hombre, si no tenemos en cuenta "angle", con una simple resta de las coordenadas entre los procesos que interactúan basta, es más, en muchos casos bastará con hacer una única resta, porque al no tener una misma coordenada vertical ¿para qué mirar la horizontal?

De todas formas, ya se habló de las "collision_box", no recuerdo en qué se quedó, si era algo pendiente de añadir en el módulo correspondiente, si ya estaba implementado en el código...

Claro, ya lo habiamos hablado, pero aun esta pendiente... seran cosas de la version 2.0 o >1.0

[Windgate]

Después de muchos meses amenazando, me voy a descargar TODO Bennu y vamos a intentar compilar a semejante cabronazo peludo y obeso a ver qué se puede hacer 8)

[Mr Matsusaka]

En mi opinion las colisiones por pixel que vienen dadas desde la epoca del Div2 son peores que unas mas sencillas hechas por cajas. Al menos a mi, no me gusta que una bala que colisione en la capa de mi protagonista me mate... Tampoco me gusta que los combos de un juego de lucha salgan o dejen de salir dependiendo del enemigo y de si este es mas flaco o tiene melena... o que un golpe no colisione porque pilla justo en medio de las piernas del enemigo...

Si a esto ademas le sumamos el consumo de recursos pues la eleccion creo que esta clara. Al menos en un juego de lucha que tengo en proyecto lo hago con colisiones de cajas y ha quedado perfecto y ahora estoy seguro de que un determinado combo que sale contra un determinado personaje, va a salir contra ese y contra cualquier otro.

Lo que mucha gente cree que son unas colisiones chapuzeras, son en realidad las que se han venido haciendo en los juegos profesionales desde tiempos inmemoriables. U acaso os creeis que en la practica se nota mucho si la colision esta hecha por pixel o por cajas de colision? Podeis decirme algun juego 2D que se note que sus colisiones estan hechas por pixel?

[Windgate]

Lo ideal sería disponer de ambos métodos, o de alguna manera tener un proceso fantasma con el gráfico en recuadro que sea sobre el que realmente se compruebe la colisión... Sería una opción que se podría probar...

Lo que dices de las colisiones con la capa del personaje, ojo. Para evitar eso es posible trabajar los personajes "por partes". Por ejemplo, en un juego de combate 1 vs 1 lo ideal es tener separado un proceso con el puño o el pie del personaje que se superponga sobre el personaje completo (Usando puntos de control por ejemplo).

De esa forma las colisiones se comprueban sobre esos procesos pie, puño, etc. que sólo aparecen cuando el personaje está golpeando. Con eso evitas lo que tú dices, si lo haces de otra manera es tedioso tener que comprobar si ha habido colisión del pie del personaje A con la cara del personaje B o al revés...

[Mr Matsusaka]

Lo ideal sería disponer de ambos métodos

No se me malinterprete, no estoy a favor de la eliminacion de la colision por pixeles. Simplemente quiero expresar que para mi, en los videojuegos, una colision mas austera por cajas, resulta a la larga mejor. Luego que cada uno use el metodo que mejor le parezca.

Lo que dices de las colisiones con la capa del personaje, ojo. Para evitar eso es posible trabajar los personajes "por partes". Por ejemplo, en un juego de combate 1 vs 1 lo ideal es tener separado un proceso con el puño...

De esa forma las colisiones se comprueban sobre esos procesos pie, puño, etc. que sólo aparecen cuando el personaje está golpeando. Con eso evitas lo que tú dices, si lo haces de otra manera es tedioso tener que comprobar si ha habido colisión del pie del personaje A con la cara del personaje B o al revés...

La explicacion que das es tan valida para la colision por cajas como la colision por pixeles. Tambien la colision por cajas necesita de un X e Y originales como referencia, y a partir de ahi calcular si las cajas se superponen o no.

El problema no radica en la colision del que golpea, sino de quien recibe. Pues en ese caso el que colisiona es el enemigo con todo su cuerpo. El personaje de la capa no esta golpeando, sino recibiendo un disparo (por ejemplo) y este, al tocarle en la capa lo mata. Imaginate un cuadro de animacion en el que la capa se mueve por el viento haciendo nuestro personaje mas vulnerable. No se como lo ves, pero en mi opinion una cuestion estetica como esa no deberia afectar a la jugabilidad...

Tendria una solucion, y seria separando el personaje y la capa haciendolos procesos distintos. En un juego arcade o plataformas no habria problemas.

Sin enbargo en un juego de lucha la cosa aun seria problematica. Tal como he dicho, determinados combos dejarian de salir dependiendo del rival. Aparte de que descubrir todas estas incongruencias entre todos los combos y enemigos posibles seria una tarea titanica, partir los frames problematicos en varios procesos no hace otra cosa mas que complicar la historia.

El tercer problema, que un golpe bajo se ponga entre las piernas del enemigo y no haga colision, no tiene un remedio limpio con la colision por pixeles. Yo he llegado a ver un "hadoken" que va por el suelo tipo Power Wave que de vez en cuando atravesaba a cierto enemigo. Este enemgo tenia las piernas muy flacas y alargadas. Si a esto le unimos que el "hadoken" va muy rapido, podia darse el caso de que pasase al rival sin colisionarlo. Con las cajas de colision este problema quedo solucionado.

[Drumpi]

He visto el código fuente, y creo que se podría mirar de mejorar la colisión que tenemos.
Por ejemplo, no comprobar procesos que, por el tamaño del gráfico, size, size_x, size_y y la posición de estos, es seguro que no colisionan. Eso mejorará el rendimiento en muchos casos, creo.

Pix, esos tipos de chequeos ya estan incorporados... y se evita hacer el calculo si los graficos no chocan por coordendas...

(..)

Pues no se hasta qué punto eso es verdad, o hasta dónde se ha hecho eficiente. En el primer boss del segundo nivel de "Echo" comprobaba los choques de los disparos con las naves por el clásico método de collision, y en cuanto metía 5 disparos, la negrita me escupía en la cara.
Cambiando el método a detectarlo por proximidad (resta de coordenadas), el juego va casi fluido al máximo. No se si es que primero tiene que hacer los cálculos de dónde están los pixels por angle, size y demás, pero collision sigue siendo una función lenta (más rápida que antes, igual de útil, pero a evitar en sistemas con pocos recursos ;D).

[Windgate]

La ineficiencia del uso de collision es bastante grave si no tenemos una CPU decente, p.ej. en la Wiz veo que has sentido el placer de ver lo que consume :D

En cuanto al juego de luchas, con capas, espadas largas, etc... A ver si alguien se anima a hacer un ejemplo, yo ando a full con el 2D y me da "pereza", pero sería curioso, entiendo que muchas partes de las que hablas (p.ej. la espada y la capa) deberían manejarse como procesos independientes que detectar o no colisión con otros procesos:

La capa ignora la espada enemiga
La espada ignora el puñetazo enemigo
El puñetazo ignora la capa enemiga...

Curioso, si alguien se anima a programarlo adelante ;D