Pregunta sobre durezas "moviles"

[jean la montard]

Estoy haciendo una especie de pseudo codigo para mi remake del Joust y quiero saber , sobre todo a la hora de hacer graficos , una cuestion que no me deja dormir, el juego consiste en derribar unos jinetes de una especie de avestruces y en el original el recurso que se empleaba era el de dibujarlos por separado y si toca el "sprite" del jinete pues fuera, la puñeta es que yo tengo pensado recurrir a durezas para no tener que segmentar los sprites del jinete y de la montura y poder hacer animaciones "algo" mas complejas que en el original (donde ni habia) , se que los escenarios se utilizan durezas para que el personaje no se los "coma" pero con esto no se si es posible hacerlo

¿es posible hacer durezas moviles o sale mas a cuenta dibujar los sprites por "separado"?

Es decir seria posible (y sencillo) poner una "sombra" invisible que siga al personaje y que sirva para detectar colisiones y activar las animaciones de caidas y porrazos que tengo en mente :D

[juanvvc]

En realidad para detectar colisiones se suele definir un rectángulo alrededor de los jinetes y otro alrededor de quien sea que los empuje, y si ambos rectángulos se superponen tienes colisión.

En tu caso puedes dibujar los sprites de avestruz y jinete juntos, y definir el rectángulo encima del jinete y un poco menor que su tamaño. Así minimizas el error pero no siempre tendrás un poco: si le empujas en los pelos de la cabeza no detectará colisión pero en el espacio vacío un poco encima del hombro sí... Pero en realidad colisiones perfectas es algo que se valora muy poco en el juego comparado con velocidad de ejecución. Y los rectángulos son mucho, mucho, pero mucho más rápidos que las colisiones duras entre sprites. Y por eso prácticamente todos los juegos comerciales o no utilizan rectángulos para colisiones entre sprites.

Pero si te empeñas en durezas móviles perfectamente ajustadas al personaje, la solución de la sombra invisible es perfectamente válida.

[Drumpi]

Totalmente de acuerdo con juanvvc: el uso de collision es lento, pero muy preciso, ya se hagan con el sprite o con imagenes invisibles, por eso, lo normal es recurrir a las distancias entre sprites, y aqui puedes elegir entre buscar la distancia absoluta (en fenix existe get_dist, pero usa una raiz en el cálculo, que es más lento que el siguiente método) o la distancia respecto a cada eje, y si tu jinete tiene su centro desplazado respecto al de la imagen, siempre puedes establecer un "punto de control" sobre el que hacer los cálculos.
Es que usar un mapa de durezas no te sirve, porque tendrías que actualizarlo continuamente y eso es aun mas lento que usar colisiones. Podrías tambien crear un array que indique en qué posiciones se mueve cada jinete, y si dos están próximos hacer el cálculo de colisión, creo que así ahorrarías cálculos.

[jean la montard]

Respecto del rendimiento , de momento no es algo que me preocupe , ya que si conoceis el arcade original , no es mas que un fondo negro(que tal vez cambie por un fondo con unos planos de scroll o algo asi) , unos pocos de tiles haciendo de "plataformas" y unos 8 sprites (que en mi "version" seran de 32X32 pixeles), asi que (espero) no tener problemas , aunque nunca esta demas saber por mano de expertos , como optimizar o como se deberia de hacer

Lo de definir rectangulos lo conocia en mugen , donde se que se emplean para las partes que hieren al rival , pero hay se hacen (si no me falla la memoria)en un editor que da referencia visual, ¿en fenix se hacen por coordenadas respecto de los ejes o algo asi o se pueden crear las formas en algun color "invisible" para aplicarlo? demasiadas dudas... :loco:

De todos modos gracias por la ayuda , una vez lo tenga que poner en codigo en fenix , volvere a preguntar si tengo problemas (cosa segura)

[juanvvc]

Jean, lo de los rectángulos es más sencillo de lo que crees: si tiene un caballero centrado en (x,y) y una espada dentrada en (a,b) y defines un rectángulo alrededor del caballero de 30 pixeles de alto y 60 de ancho, entonces el código de colisión se reduce a:



if(abs(a-x)<30/2 && abs(b-y)<60/2) sword_collides()


Que es much&#237;simo, pero much&#237;simo m&#225;s r&#225;pido que calcular solapamiento entre sprites y el error puede limitarse. El truco es definir la altura y anchura del rect&#225;ngulo para minimizar el error, y eso normalmente significa que el rect&#225;ngulo sea algo m&#225;s peque&#241;o que el ancho del caballero. En este caso seguramente funcionar&#237;a si tu caballero es un sprite de 40x80, por ejemplo.