PSS (NES); 20151212/13

Antes de seguir tengo que optimizar. Me ha dicho David que el juego pierde frames en modo NTSC. Tengo que tratar de ganar ciclos en todas las rutinas. Una de las principales candidatas es la que envía los sprites desordenados a la OAM.

Creo que el cambio pasa por hacer la estructura de tamaño fijo. Los elemenos que no existan en cada fase (enemigos de menos, monedas de menos) deben enviarse igualmente, pero fuera de la pantalla. Así la velocidad será fija por nivel y controlaré mucho mejor todo. Además, se tardará menos tiempo en el proceso porque no habrá que estar poniendo a cero la estructura temporal de sprites ni haciendo comprobaciones a la hora de enviarlos a la OAM.

Si hemos dicho que habrá un máximo de 15 monedas, el máximo de metasprites gestionados por el sistema será de 19, lo que viene de la hostia porque es un número primo. Eso significa que con un incremento de 2 lo tengo. Puedo incluso precalcular los ordenes.

Voy a ello…

~~

Bueno, ya he conseguido ir a velocidad fija en todas las fases… Pero en NTSC pierdo el frame y va a 30fps. Tengo que optimizar. Y si no es suficiente, encontrar el valor máximo de objetos que puedo procesar.

Lo que me jode es que ni siquiera están las colisiones :-/

~

Creo que va a haber que tomar medidas drásticas. Ahora los jugadores son un array de 2 posiciones y la llamada a la función que los mueve está parametrizada.

Creo que lo suyo va a ser duplicar la función y usar variables normales. Hago copia de seguridad de /dev y meto el cambio, a ver.

~~

Haciendo la guarrada de desdoblar variables y funciones ¡ya tengo tiempo suficiente de frame! Lo malo es eso, que tengo tela de código duplicado. Lo bueno es que la mayor parte de ese código no lo tengo que tocar para nada. Además, puedo hacer todos los cambios con el modo 1P activo y sólo para [PERSONAJE_1] y luego no es más que CTRL+C, CTRL+V, y Find & Replace “_personaje_1” por “_personaje_2”. Tampoco es tan malo ¿no? Además, nadie mira el código luego.

Aún así, sigo andando por el filo de la navaja, así que mejor que optimice todo lo que pueda.

Estoy dándole vueltas a la mejor forma de detectar las monedas. Lo más directo es hacer una colisión por caja en el bucle que mueve las monedas, pero quizá sea mejor pasar de ahí y hacer una detección en dos partes: primero detectando que el jugador toca un tile donde hay una moneda (siempre andan alineadas a tile, recordemos que se ponen en el mapa), y luego buscando de qué moneda se trata. Con comprobar el punto central del jugador tengo suficiente. Recordemos que aquí los rectángulos lógicos de cada jugador miden 8×16 pixels, así que el centro sería en prx+3, pry+7. Con mirar un ATTR ((prx + 3) >> 4, (pry + 7) >> 4)) lo tengo. Y luego un bucle de N vueltas. Precalculo un rda con yy*16+xx basándome en esas coordenadas y lo comparo con las entradas en la ROM, que están en ese formato. Es una comparación de un número con otro, a fin de cuentas.

El otro método sería pasar a ese formato la ubicación del centro del jugador en cada frame, y aprovechando el bucle que mueve las monedas comparar el dato en rom con dicho valor.

La primera forma solo implicaría dos comprobaciones por frame en modo de dos jugadores, aunque luego tenga ahí un bucle metido. Si eso hace que pierda un frame de vez en cuando me da igual si lo que gano es 30 comprobaciones menos por frame en general.

¡Hay que mirar cada ciclo! ¡Que triste es de pedí, pero más triste es de robá!

~~

Monedas cogiscibles (con animación que, conociéndome, acabaré cambiando mil veces). Colisionemos ahora con los enemigos…

~~

Probando me he dado cuenta que la búsqueda de la moneda en la colisión ralentiza el juego. Tengo que:

  • Desactivar la moneda en el buffer de pantalla.
  • Codificar el nº de la moneda en el nibble alto del byte! ¡Y así no tengo que buscar nada! ¡qué gran picha tiene este descubrimiento!

~

Hecho. Lo dejo por hoy. Lo próximo que haré será:

  • Tema camiseta. Con los tres comportamientos diferentes según sea 1P, 2P_COOP o 2P_VS.
  • Detección de que no hay más monedas, aparición de las flechas (tiles y sprites!). Desaparición de los enemigos
  • Tiempo. Cálculo de tiempo. Que aparezca [MALO_ESPECIAL] cuando se acabe el tiempo.

^ JOIN WHEN GOOGLE DRIVE BEHAVES.

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