PSS (SG-1000), 20151225

Comienzo el diario de la versión de SG-1000 un poco tarde. Pensaba que sería un camino de rosas pero estoy teniendo problemas de rendimiento.

Por lo visto cc65 es mucho mejor compilador que SDCC. Esto me ha sorprendido… Pensé que un motor que no tenía problemas para moverse bien en un 6502 lo haría en un Z80, y que el código generado para Z80 sería más eficiente por tener este procesador más registros… Pero no es así.

En cuanto hay que actualizar muchas cosas pierdo frames en NTSC. Es un problema porque en SMS hay que copiar incluso más datos a VRAM en cada frame. Creo que es bastante posible que este sea uno de los handicaps junto con el compilador, ya que en NES las copias a VRAM son movimientos normales (la VRAM está en el espacio de direcciones) y en SEGA 8-bit se hacen escribiendo a un puerto. Estoy seguro de que esto limita bastante el ancho de banda.

El tema es que tengo que intentar rediseñar y optimizar todo el tema de movimiento de sprites.

SGlib (basada en SMSlib) proporciona una estructura en memoria que es copiada a VRAM una vez por frame. Yo necesito rellenar esta estructura empleando un orden diferente cada vez para introducir parpadeo y evitar que los sprites desaparezcan cuando se alinean más de 4. En este trasiego estoy perdiendo mucho tiempo y creo que es una de las cosas que tengo que optimizar. Se ve perfectamente como el juego deja de perder frames en cuanto comienzan a desaparecer monedas de la pantalla.

El SAT se copia completamente en cada frame. Ahora mismo tengo un máximo de 21 sprites y quizá pueda empezar por instruir a la biblioteca (que ya he modificado a saco) para que sólo procese 21 sprites. Veamos si esto mejora algo (todo suma).

El siguiente paso será diseñar qué se hace con cada tipo de sprite en pantalla para intentar reducir a la minima expresión las actualizaciones. Por ejemplo, las monedas pasan casi todo el tiempo fijas, y sus gráficos se modifican cambiando los patrones en el SGT. Esto implica 8×4 = 32 bytes a VRAM. Quizá también ahorraría tiempo teniendo todos los gráficos en VRAM y cambiando solo el valor de la SAT, que a fin de cuentas se actualiza cada frame… Eso es cambiar 13 valores cada frame.

Luego haré un estudio de todas las actualizaciones posibles e intentaré rediseñar de nuevo el sprite mixer. También ayudaría que el sprite mixer pudiese escribir directamente en la copia de la SAT en vez de estar haciendo cosas intermedias. Cogeré papel y lápiz luego.

~~

Oh, wait, 21 elementos, no 21 sprites. Tengo:

4x2 para enemigos => 8
2x4 para jugadores => 8
2x2 para items => 4
13 monedas 
13+16+4= 33 - ole mis webs, me estoy colando.

Bueno, voy a coger un papel y ver qué necesita cada objeto en pantalla. Pero antes voy a ver si puedo apañar rápidamente lo de las monedas…

La putada es que SDCC es DESESPERANTEMENTE LENTO. Dios, qué coñazo es esperar varios minutos cada vez que tengo que recompilar para probar algo…

~~

De entrada pueden ser incluso más de 33. Hay que tener en cuenta que tanto [PERSONAJE_1] como [PERSONAJE_2] pueden desaparecer por el borde de la pantalla y para simular ese efecto hay que duplicar los sprites.

Tengo que ver de donde recortar. De entrada, [ENEMIGO_ESPECIAL] podría pintarlo solo con el reborde, y las camisetas más de lo mismo. Esto me dejaría con:

3x2 enemigos => 6
1 [ENEMIGO_ESPECIAL] 
2x2x2 jugadores => 8
13 monedas
2 ítems

2+13+6+16 = 37. Me sigo pasando un HUEVO. Voy a examinar los sprites de [PERSONAJE_1] y [PERSONAJE_2] a ver si puedo ahorrar algo.

No. Tengo que pensar en algo.

En modo 1P:

8 enemigos
8 [PERSONAJE_1]
13 monedas
2 items

Total 31.

En modo 2P tengo que limitar a 4 por jugador. Esto significa que cuando un jugador esté en el borde no lo puedo duplicar. Esto introducira un glitch con el que tendremos que vivir hasta que se me ocurra algo mejor.

En ese caso lo suyo es manejar yo la SAT manualmente. La copia de la SAT la escribo directamente, y luego la copio yo también en el orden que sea.

El byte de colores no necesito tocarlo en mi copia. Se puede inicializar al principio.

~~~~

Entradas en mi copia de la SAT

Off
0		4 		[PERSONAJE_1]
4 		4 		[PERSONAJE_2]
8 		2 		Enem 1
10 		2 		Enem 2
12 		2 		Enem 3
14 		2 		[ENEMIGO_ESPECIAL]
16 		1 		Item 1
17 		1 		Item 2
18 		13 		Coins
  • Veamos, los enemigos están cargados a partir del patron 128.
  • Un enemigo de sprite “s” muestra los metasprites s y s + 1, con s = 0…
  • Cada metasprite está formado por dos sprites, y cada sprite por 4 patrones
  • patron = 128 + s * 8

~~~~~~~~~~~~

Mucho más tarde – He reescrito todo mil veces y al final me he quedado con lo primero, pero limpio. Le he metido a SGlib las funciones de metasprites directamente para escribir en el array con la copia de la SAT. He modificado las funciones que añaden sprites para usar un puntero e ir escribiendo a manaca, sin comprobaciones.

Más o menos va bien, pero ahora se jode un registro del VDP cuando enciendo la pantalla a veces. Parece que quizá se corrompa la copia de VDPregs en RAM, o yo qué sé.

Tendré que hacer algo de debug con el emulicious, pero la verdad es que no sé para qué va a valer… Pero bueno, más se perdió en Roma.

~~

Me estaba escribiendo las estructuras const unsigned char * en RAM. He tenido que hacer la paranoia const unsigned char * const unsigned char a [] = { para que no lo haga … y deste entonces parece no fallar.

Mañana más. Este proyecto me está matando.

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