Karoshi MSX Community

Hola amigos.

Yo creía que tenia bien claro el tema del 5º Sprite, pero al ir aplicarlo
te he topado de nuevo con problemas y me he atascado. >:(

Ejemplo:

Tengo en linea 5 Sprites, los 2 primeros son del "prota", otros 2 de enemigos
y el 5 otro enemigo.
Para esto tengo un Buffer con los atributos de los Sprites que me ocupa 5*4 bytes, para operar
RAM y después volcar los datos a VRAM.
La solución pasa por intercambiar el Sprite 5 por el 4 intermitentemente para que
así sean los dos "visibles".
Vale hasta ahí perfecto.
Almacenado en RAM, tengo los datos para cada Sprite con velocidad, topes, estado, esperas etc..
Vamos las condiciones que necesite el enemigo para moverse.

Yo a la rutina de movimiento de los enemigos, le paso estos datos con un LD HL,datos_1, de donde
les va cogiendo y apuntando a los atributos del Sprite del buffer.

Claro a la hora de intercambiar los Sprites estos datos que le paso a la rutina no corresponden
con el Sprite que quiero mover.

Como lo hacéis, me estoy complicando la vida yo solo, estoy equivocado en el planteamiento (seguro),
que me aconsejáis.

Muchas gracias.

yo hice lo siguiente... a ver si te sirve, pq la teoria la tenia, pero en la practica algo fallaba :P

Quizas soy mu bruto...yo tengo en ram una copia del buffer de los planos de sprites  (de todos) 4 bytes por cada 1 (posY,posX,color,patron)(32*4 = 128 bytes). Y lo volco cada vez. Lo que cambio cada vez que volvo a VRAM es el orden,pero en RAM siempre tienen el mismo numero de sprite. Es decir...planteo ejemplo que se vera claro.

SPRITE en RAM
00-01-02-03-04-05 ... 30-31 (32 planos eran no?)
Marco que los 2 primeros son fijos

A cada interrupcion en VRAM se suben asi:
00-01-03-04-05...30-31-02
00-01-04-05...30-31-02-03
00-01-05...30-31-02-03-04

De esta manera la referencia RAM siempre es la misma, pero la rutina de subida es la que cambia el orden.
Para tu programa que escribe en RAM, le da igual en que plano se pinte el sprite, el numero que tu usas para el calculo de datos es siempre el mismo.

Esto tiene un problema...que no puedes tratar los sprites con profundidad Z, es decir, controlar quien va delante o quien va detras, pero en muchos juegos eso es irrelevante.
Esta rotacion la haria SIEMPRE, independientemente de que haya bit de 5o Sprite o no, porque aunque si no la hay se verán todos bien y si la hay, ya parpadeará to solito :P

Lo que me fallaba de esta teoria , era algo de punteros, que hacia un sprite de mas y tal, pero la rutina funcionaba bien y el parpadeo era soportable.

Creo recordar que esto me lo explicó viejo_archivero en un post por aquí.

Bien, aunque parezca mentira, en uno de mis muchos viajes en tren al trabajo, se me ha encendido
la neurona y he llegado a la misma comclusion que tu, trabajar sobre el buffer pero sin variarle.
Solamente variar el orden de transferencia a VRAM.

Ahora bien, como lo haces, pues la primera vez tendras que desplazar 4 bytes, despues 8, 12 etc...
Que haces, pones una variable y segun el valor haces una transferencia u otra. ???

Muchas gracias j4mk3

Os digo como lo hago yo. Por un lado, los sprites del prota no me gusta que flickeen, así que siempre los dejo fijos, pero vamos, que podéis hacerlo como queráis, incluyendo al prota o no. Esto es lo que hago en cada frame:

- Esto es el loop del juego
- Gestiono el juego, y todo lo relativo a atributos sprites lo guardo en RAM en un buffer (4 bytes por cada sprite), que lo llamo SPRATR.
- Cuando ya tengo todo listo, y antes de la interrupción, DUPLICO el contenido en otro buffer que está justo seguido en la RAM (llamemosle SPRATR2) con un simple LDIR. De esta forma, tengo 2 buffers con los atributos de sprites duplicados, uno JUSTO SEGUIDO del otro y que ocupan lo mismo.
- Tengo otra variable, que es el PUNTERO desde donde tengo que empezar a leer dichos datos para transferirlos a VRAM. Le sumo 4 y listos. Si ha llegado al tope, lo reinicio al valor incial.

- HALT - synch!

- Transfiero los sprites a VRAM a partir de mi PUNTERO. La cantidad a transferir siempre es la misma, pero el orden no lo será, al ir aumentando +4 el puntero. Cuando se "pase" del buffer normal SPRATR, como tiene una copia exacta seguida en SPRATR2 empezarán los datos desde el primer sprite. Así la rotación es "automática" y solo depende de gestionar ese puntero.

- Vuelvo al loop


Así es como lo hago yo, por ejemplo en Infinity y en British Bob ;), y corre bastante finito.

OK, Jon. ;)

Muy buena la idea del Buffer duplicado.

Voy a hacer pruebas y os comento algo. :D