Pixel de colisión

[Arcontus]

Buenas chicos,

me surge una duda: está claro que mediante la función "collision" podemos averiguar si un proceso colisiona con otro pero, ¿existe algun modo de saber la posición de dicho pixel?

Pej: estoy desarrollando un juego de naves, y me gustaría que cuando las naves colisionan contra paredes, se produzca unas chispas u otro efecto similar, pero para ello, necesito saber en que punto he de mostrarlas.

Gracias de antemano,

Saludos!

[SplinterGU]

no, no es posible...

[Arcontus]

no, no es posible...

Pues es curioso, por que si para valorar con collision el programa ha de ver si un pixel colisiona con otro, no debería ser demasiado complicado incluir una función que retorne ese punto ¿correcto?.

¿Se os ocurre alguna idea para solucionar este reto?

Saludos!

[Rein (K´)ah Al-Ghul]

suponiendo q las paredes sean procesos, cuando la nave colisiona con las paredes esta podria crear procesos q son chispas...

digamos q la nave explata si se cocha con las paredes, podrias poner un mapa de dureza con dos colores uno que saque chispas y otro q haga q explote...

[Arcontus]

suponiendo q las paredes sean procesos, cuando la nave colisiona con las paredes esta podria crear procesos q son chispas...

digamos q la nave explata si se cocha con las paredes, podrias poner un mapa de dureza con dos colores uno que saque chispas y otro q haga q explote...

Esa es la idea, el problema es saber donde está ese roce.

[Windgate]

Se podría calcular la posición exacta recorriendo ambos mapas con map_get_pixel hasta localizar las zonas que coinciden. De hecho no sería complicado hacer una función que para toda posición de pixel coincidente invocase un proceso chispa en esa posición.

Ojalá tuviese tanto tiempo como antes para programar estas cositas, de verdad, con map_get_pixel sería facilísimo hacer la función que te digo :'(

PD: Y si existiesen los punteros a función/proceso... Apúntalos nuevamente para la 2.0 Splinter :D

[DCelso]

pues yo no lo veo tan fácil, deberías de sacar la posicion absoluta de cada pixel de cada gráfico de los procesos inplicados en el mapa de la pantalla y calcular su pixel de color en su posición relativa del gráfico, osea, sería crearte a manini el collision, es mas, no solo un pixel dará colisión, podría darse el caso de que colisionen mas de un pixel si tus procesos se mueven a mas de un pixel por frame. Osea sería como crearte un collision que devuelva un array de pixeles. :D

[Drumpi]

Bueno, si no se ha alterado el punto de control 0, sería tan fácil como buscar el punto de colisión entre los que forman la línea que los unen, sobre todo porque conoceríamos el tamaño de los mapas de ambos procesos.

Pero claro, estoy suponiendo colisiones entre objetos sencillos (formas cuadradas o redondas). Si uno es el mapa del nivel...
En ese caso: map_get_pixel en todos los puntos de la circunferencia/cuadrado que rodea a la nave y buscar el punto medio entre todos los que choquen.

[SplinterGU]

no, no es posible...

Pues es curioso, por que si para valorar con collision el programa ha de ver si un pixel colisiona con otro, no debería ser demasiado complicado incluir una función que retorne ese punto ¿correcto?.

¿Se os ocurre alguna idea para solucionar este reto?

Saludos!

pues no, no es curioso, hacer una colision del tipo que pensas no seria algo muy optimo, que ya de por si no lo es la funcion de colision, ya el simple hecho de que el primer punto (o juego de puntos, dependiendo de la profundidad de los graficos involucrados) que se detecta la colision ya se dice que colisiona, pero este primer punto no necesaria es el hotspot de la colision.

Se podría calcular la posición exacta recorriendo ambos mapas con map_get_pixel hasta localizar las zonas que coinciden. De hecho no sería complicado hacer una función que para toda posición de pixel coincidente invocase un proceso chispa en esa posición.

Ojalá tuviese tanto tiempo como antes para programar estas cositas, de verdad, con map_get_pixel sería facilísimo hacer la función que te digo :'(

PD: Y si existiesen los punteros a función/proceso... Apúntalos nuevamente para la 2.0 Splinter :D

eso seria terriblemente lento.

pues yo no lo veo tan fácil, deberías de sacar la posicion absoluta de cada pixel de cada gráfico de los procesos inplicados en el mapa de la pantalla y calcular su pixel de color en su posición relativa del gráfico, osea, sería crearte a manini el collision, es mas, no solo un pixel dará colisión, podría darse el caso de que colisionen mas de un pixel si tus procesos se mueven a mas de un pixel por frame. Osea sería como crearte un collision que devuelva un array de pixeles. :D

el color no tiene nada que ver, pero por ahi va la cosa, el problema no es simple como vos decis, porque en la mayoria de los casos (yo diria mas del 90%) no colisiona 1 solo pixel, sino que lo hacen muchos, y el "hotspot" de colision podria estar determinado por muchas cosas, como angulos, direccion del movimiento de cada uno de los objetos que estan colisionando y otras tantas cosas, para esto deberia tenerse en cuenta algun algoritmo de fisica.

no hay que olvidar que calcular posicion pixel a pixel seria una locura de procesamiento, es ilogico, ademas de que el algoritmo no debe limitarse solo a la primera colision, sino que deberia detectar todos los puntos de colision y procesarlo en base a reglas fisicas que variaran segun la aplicacion.

Bueno, si no se ha alterado el punto de control 0, sería tan fácil como buscar el punto de colisión entre los que forman la línea que los unen, sobre todo porque conoceríamos el tamaño de los mapas de ambos procesos.

Pero claro, estoy suponiendo colisiones entre objetos sencillos (formas cuadradas o redondas). Si uno es el mapa del nivel...
En ese caso: map_get_pixel en todos los puntos de la circunferencia/cuadrado que rodea a la nave y buscar el punto medio entre todos los que choquen.

el punto de control 0 no significa que vaya a colisionar con el.

la cosa seria tener muchos puntos de control, y si un objeto colision, verificar cuales puntos de control entre ellos colisionan con el objeto, y en ese caso tomar alguno de ellos como el punto de impacto, con la cantidad de puntos de control adecuadas no importaria mucho la precision del impacto.

[Noivern]

mmm quizás viendolo como un sistema vectorial y un margen de impacto...
y si obtienes el ángulo que hay entre lo que chocas y tu protagonista. Con ese dato, a partir del centro de tu prota le sumas a la X el (coseno del ángulo) * |distancia entre los puntos - margen de impacto| y la Y el (seno del angulo)  * |distancia - margen impacto|. En el punto que obtengase creas las chispas.
El margen de impacto es con lo que choca el prota... no va a ser  pixel preciso, pero yo creo que te serviría para lo que quieres hacer.
A ver si mis mates no me fallan y me dejan en ridículo xD u.u

[Windgate]

Sería lento, pero tampoco tanto, al fin y al cabo consistiría en recorrer 2 mapas pixel a pixel. El problema vendría si se ha alterado el valor de size o de angle xD

[SplinterGU]

cierto, me habia olvidado de eso, igual pensa que no son 2 mapas, pixel a pixel, pueden ser mas, obviamente deberia ser solo de los que colisionan, pero bueno, se podria, haciendo un map_put sobre otro.

[osk]

O no lo entendido bien, o soy un genio (!?), pero con un simple x=father.x ¿no sería suficiente para colocar las chispas donde colisiona la nave?

[TYCO]

O no lo entendido bien, o soy un genio (!?), pero con un simple x=father.x ¿no sería suficiente para colocar las chispas donde colisiona la nave?

Sí, siempre y cuando crees pequeños procesos ocultos que estén por los bordes de la nave y compruebes con collision si tocan la pared.

[SplinterGU]

O no lo entendido bien, o soy un genio (!?), pero con un simple x=father.x ¿no sería suficiente para colocar las chispas donde colisiona la nave?

pues no, un simple father.x no es el punto del impacto, a menos que la "bala" o "misil" o lo que sea, sea lo suficientemente pequeño, pero no siempre son balas lo que colisiona, suponete un juego donde son autos que colisionan entre si, y queres ponerle chispas en el roce, con father.x no lo lograras.