Isshokuta; 20160530

He estado dándole vueltas a los proyectiles y no encuentro ninguna opción mejor que usar la técnica que he venido usando hasta ahora: punto fijo, calcular distancia, y precalcular vx y vy al lanzar el proyectil. Esto si quiero proyectiles que vayan en el ángulo que yo quiera (por ejemplo, para poner un sentry gun que te vaya dando el coñazo). La cosa es que quiero aprovechar al máximo el tiempo de frame que me queda y meter ahora algo que use punto fijo real me echa para atrás, cuando tengo todo el resto precalculado y funcionando en enteros.

Quizá meter dos tipos de proyectiles, unos simples (de los que usaría para las estrellas que lanzan los malos) que sólo avanzan usando enteros e incrementos de X en X, y luego los complejos para bosses o sentry guns, sea lo más indicado, pero a lo mejor es gastar ROM para nada.

Voy a ver de meter solo un tipo, los complejos, ver cómo se resiente esto, y luego tomaré una decisión.

Nah.

Que los hago tiesos por ahora, luego si hago sentry guns o bosses o algo ya se me ocurrirá qué hago. O no, los dejos tiesos.

~~~

Aún no tengo apañadas las colisiones, pero lo suyo es que agachándote no te de un proyectil que tiran por arriba… Pero viendo los gráficos, no sé si esto quedará un poco raro.

Si lo alineo 100% al puño que dispara, estando el enemigo de pie, el proyectil ocupa una posición en la que claramente te da si estás agachado (colisionaría con más de la mitad de la cabeza, visualmente, me refiero). Si lo lanzo más arriba queda raro. Si te da un pixel o dos no me importa. Quizá tenga que modificar el puño del sprite?

No sé, voy a verlo en acción. Por ahora lo puedo poner en px – 40 + 4 (-36, vaya). Veamos adónde nos lleva esto.

~~~

Bueno, mal no queda. Vamos a dejarlo por ahora así.

~~

Y ahora uno de los cocos…

Detección de colisiones

Dejando a un lado que aún tengo que integrar cells de animación con los personajes hostiados y ver qué hago con ellos (¿leve desplazamiento horizontal? ¿Deberían caerse en este estado? Eso podría molar, lo apunto por si no es mucho lío), y que me gustaría darle una vuelta a las máquinas de estado para optimizar un poco en espacio, voy a ponerme a divagar y hacer pruebas para ver cómo manejo las colisiones.

Lo primero que se me ocurre es detectar las colisiones en este área:

···
·X·
·X·
·X·
·X·

¿Sería suficiente? No lo sé, a lo mejor queda raro y parece que a veces nos deberían haber dao.

Lo suyo es hacer una función o macro que compruebe si una coordenada cae dentro de ese rectángulo dadas las (x,y) del punto central inferior (que es el origen de los sprites). Luego, en los golpes, designar un “hotspot”, en la parte central de la columna más alejada de puños y pies y, mientras dure el subestado “HIT”, ver si ese punto cae dentro de algún rectángulo enemigo (y al revés para los enemigos dándote a tí).

Más tarde, debería hacer lo mismo con los proyectiles (punto central) y ver cómo manejo las colisiones cuerpo a cuerpo sin hostiar.

Voy a hacer la función de colisión a ver, a intentar detectarla, y a cambiar la paleta.

Para simplificarlo todo, podría hacer un “phitting” y un “phitx, phity” para controlar esto de forma más centralizada. Debería hacer todo esto, además, en un bucle aislado, para que todos los enemigos y los proyectiles estén en un estado conocido cuando vayamos a hacer las comprobaciones.

Pero antes creo que me daré una vuelta por el código (rápida, cosa de un rato) para ver si puedo ir optimizando cosas tontas.

~~

Parece que funciona la colisión (he metido player -> enemigos por ahora), pero ocurre algo: si el enemigo está muy cerca el punto de detección falla, porque se pasa. No sé muy bien qué hacer para prevenir esto, ni cómo manejar las colisiones jugador enemigo. Realmente, necesito jugar a más juegos de este estilo. ¿Quito energía y mato al enemigo?

Por lo pronto tengo que escribir la función que colisiona jugador y enemigo.

Otra cosa que no he tenido en cuenta: bajar el limite superior 8 pixels si el destinatario está agachado. Jur.

Aparte de eso, cada vez pienso más en la idea de tomar TOOOODO un cuadrado de X pixels de lado como “punto gordo” de colisión, sobre todo porque, según lo veo, sería más o menos igual de complejo.

-> lo pruebo, sólo tengo que tocar dos valores en el IF. Asín es.

POR AHORA lo veo mejor con el cuadrado de 8×8. Lo dejo así por el momento. Voy a hacer para meter el estado de hostiado y el estado de enemigo matado.

Ya tengo las animaciones del hostiamiento. Lo que haré será desplazarlo hacia el lado contrario del guantazo durante 8 frames. Necesito precalcularlo en el momento del morrao. A ver si puedo guardarlo en algún sitio reaprovechao – sí, en en el contador de salto. GUARROW! Al final he usado otro array.

 ~~

Hecho y medio rulando. Pero tosco. Tengo que darle varios laneos al código, además. No paro de decirlo, pero no lo hago. Y es que me canso, estoy cansado. A lo mejor vuelvo unos días al Lala y lo finiquito (hay que dibujar un par de escenas para el final), o me dedico a pixelar culos en mis proyectos de aventuras y visual novels que jamás acabaré (por ejemplo, molaría pasar el Vane Engine a cartucho usando el reciéntemente aparecido Second Basic y hacerle el favor a Elusive probándoselo con algo de verdad).

Ahora voy a relajarme un rato con Final Fantasy.

~~

Tengo que colisionar ahora la estrella con el cuerpo del prota, y poco queda.

He visto que esto se cuelga cuando golpeo a un enemigo y está en la animación de “recovery” al bajar de nivel. También he visto que el estado de “hostiado” de los enemigos parece interrumpirse por el script ¿estará relacionado?

Creo que he corregido ese supuesto, pero se sigue colgando. ¿Qué está pasando? Lo puedo reproducir fácilmente, pero es la única situación en la que pasa.

Me suena a bug coñazo… Ar.

Por otro lado he visto que player_hits_baddie hace una asignación supérflua.
También he visto que el estado DAMAGE del jugador estaba siendo invalidado, de alguna forma, y no terminaba por su cuenta: he guardado toda la actualización de las variables de las pulsaciones y tal y el sprite se queda parado.

Nah, era una cosa que había hecho mal, ya está arreglado, pero sigue el fallo.

También he visto que la pantalla parece “parpadear” (se pone entera en blanco y negro) – algo está tardando mucho tiempo (misteriosamente) y parece que se jode todo el split o algo así…

¿Estaré descojonciando algún array, saliéndome, y escribiendo donde no debo?

Hora de mirar el editor hexadecimal. Ganas tengo.

Cosas que veo:

  • Parece que el reaprovechamiento de los slots de los enemigos está bien hecho. Si los saco poco a poco, al desaparecer y aparecer otro vuelve a ocupar el primer slot vacío (el mismo siempre, vaya).
  • El estado en el cuelgue es 0x0f, o sea, el estado DAMAGE.
  • Subestado vale 0, eso está bien.

¿A lo mejor lo he pillado lanzando una estrella (que, por cierto, aunque venga por abajo, no parece darme… -> check)

  • No, los proyectiles están todos apagados.
  • enctstate vale 8, correcto.
  • endamagemx vale 1, correcto.
  • pstate vale 5, agachado, o sea, que ya ha terminado de dar la patada.
  • ennextcommand vale 0, que está bien.
  • enon vale 1, ok
  • FUCK
  • La única actividad que veo asín es cacafuti escribiéndose entre $1f0 y $1f8. ¿Qué hay ahí? -> Es la pila de la CPU. Esto es MU RARO. $01 no para de incrementarse y saturar.
  • PC está dando vueltas por el principio de la ROM ¿es neslib? Supongo. Creo que veo el código de oam_meta_spr y otras cosas, así, a simple vista.
  • QUE MISTERIO

Tengo que encontrar la razón de este bloqueo, pero ya se me están acabando las ideas sobre qué mirar. Hay tantas cosas en juego… La cosa es que se para justo al inicio del estado DAMAGE del enemigo. Voy a poner, no sé, escrituras dummy en memoria en diferenets puntos del programa a ver qué ha ejecutado y qué no antes de joderse.

Voy a colocar valores en 0xff-rda en diferentes puntos de la ejecución del bucle. En concreto:

1-> antes de enems_process_script.
2-> antes de enems_execute_status.
3-> antes de la comprobación player_hits_baddie
4-> antes de la comprobación baddie_hits_player
5-> al final del bucle

No sé si será normal, porque no sé cuándo muestrea esto, pero parece que del bucle sale. Vamos a seguir. Un ratito más. Voy a salir fuera a ver. Mismo método, pero en el bucle principal . . .

Vale, se queda parado en la parada a enems_render. Al menos, ya voy acotando. Voy a ver las variables que están en juego.

Mira, algo que puede ser fuente de conflictos: es un bucle, hay un while (rda–). Sin embargo, dentro no veo nada que pueda estar rompiendo ese bucle, así que eso no debe ser. La variable rda vale 1 en el momento de pararse. rda solo cuenta tres veces, sin importar su valor. El valor que interesa es el de rdb, que es el que va haciendo el “shuffle”. En este caso vale 2, o sea, se ha parado renderizando nuestro muñaco.

enon [rdb] = enon [2] y vale 1, enstate [rdb] == EN_STATE_DAMAGE y además half_life == 1, por lo que entra en el if que pinta.

enlegsoffs = $20
entopsoffs = $40
enfacing + enframebase = $10 + $0f = $1f
enframe = $02 <- esto es. Me estoy saliendo. Esto debería ser 0.

Voy a meter un enframe [rda] = 0 en player_hits_baddie. Si es que…

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s