OBJETOS y SPRITES en el FM77AV2

[jimbobaby]

Muchas gracias de nuevo a ambos por las respuestas!

No hay mas preguntas, señorias

[pser1]

Hola,
por fin creo que ya tengo una versión del compilador C que es capaz de generar los sprites a 128 bytes (en cuatro planos de color)
partiendo del fichero AGD modificado. Ahora mismo le estoy añadiendo 16 bytes detrás del número de frames ... y parece ir bien.
Ahora me toca revisar el mapa de memoria para decidir donde se van a ubicar las distintas tablas para sprites ...
sprGfx con las imágenes en color, frmLst como tabla de frames por imagen, sprTab como tabla dinámica de sprites moviéndose
Estaba pensando que si ponemos las imágenes en VRAM, tal vez se podría pasar el curro de pintar los sprites al subsistema y aprovechar
el tiempo que tardará en hacerlo para calcular las posiciones para la siguiente pasada ...
Se admiten sugerencias, como siempre
saludos

[jimbobaby]

Estaba pensando que si ponemos las imágenes en VRAM, tal vez se podría pasar el curro de pintar los sprites al subsistema y aprovechar
el tiempo que tardará en hacerlo para calcular las posiciones para la siguiente pasada ...

Si quieres aprovechar SUB, lo suyo es que trabajen en tandem. Y teniendo en cuenta que ambos no pueden usar VRAM a la vez , tu opcion es esa, MAIN (con o sin MMR, mientras no mapees VRAM puedes usarla para EXT, p.e.) para lo que es la "gestion" (calculos de posiciones y demas), SUB pintando desde VRAM a VRAM, y los 128 bytes de common area para pasarle a SUB que sprite pintar y donde (de uno en uno).
Idealmente, SUB deberia acabar (poco) antes de que MAIN le vuelva a dar mas trabajo, pero eso ya se vera sobre la marcha

EDIT: O bien en MAIN creas una "lista de tareas" para ejecutar en el sub, se la dejas en VRAM, le dices que vaya haciendo y tienes MAIN libre para procesar logica de juego o otras cosas no-triviales que no necesiten SUB ni VRAM, eso ya ...

[pser1]

Si quieres aprovechar SUB, lo suyo es que trabajen en tandem. Y teniendo en cuenta que ambos no pueden usar VRAM a la vez , tu opcion es esa, MAIN (con o sin MMR, mientras no mapees VRAM puedes usarla para EXT, p.e.) para lo que es la "gestion" (calculos de posiciones y demas), SUB pintando desde VRAM a VRAM, y los 128 bytes de common area para pasarle a SUB que sprite pintar y donde (de uno en uno).
Idealmente, SUB deberia acabar (poco) antes de que MAIN le vuelva a dar mas trabajo, pero eso ya se vera sobre la marcha
EDIT: O bien en MAIN creas una "lista de tareas" para ejecutar en el sub, se la dejas en VRAM, le dices que vaya haciendo y tienes MAIN libre para procesar logica de juego o otras cosas no-triviales que no necesiten SUB ni VRAM, eso ya ...

Aquí es cuando surgen algunos problemillas
El subsistema tendrá las imágenes de los sprites en VRAM y los pasará a pantalla ya veremos como pues ésto implica hacer cálculos con las tablas
predesplazadas que también deberán estar en VRAM.
La CPU principal puede trabajar con la tabla de sprites activos donde guarda los valores que van cambiando. Esta tabla ha de estar en RAM, sea del
tipo que sea, mejor incluso en la página directa. La tabla de frames también estará en RAM.
Lo que hay que pensar es el formato del comando que le deberemos pasar al subsistema para que 'mueva' un sprite.
Asumiendo que el subsistema necesitará una tabla para saber que sprites está controlando, podría tener estos campos
- Imagen, frame, posY, posX (quizás mejor VRAM byte de arriba a la izquierda)
Entonces el comando podría ser tan simple como
- Número de Imagen, Frame a utilizar, Dirección de Movimiento (Dcha,Izda,Arriba,Abajo) es decir solamente tres bytes
Hay que darle alguna vueltas mas, pero por ahí podrían ir los tiros ...
De momento, me guardaré el mapa de memoria 1.3 para cuando decidamos dibujar sprites con el subsistema y, de momento, intentaré ir
activando rutinas relacionadas con sprites hasta llegar a dibujarlos desde la CPU principal para ver el tema de las tablas predesplazadas
Tengo que verificar que los espacios reservados por el momento para sprites sigue siendo suficiente ahora a 4 planos ...
saludos

[pser1]

Creía que el compilador ya hacía todo lo esperado, pero me he dado cuenta de que no genera ningún fichero de salida con los 128 bytes de
cada frame. Si que genera el fichero binario con los Bloques y con los Objetos, así que he tenido que volver contra el compilador C para crear
este fichero y añadirle los datos. Un pequeño follón, pero creo que ya lo hace bien. No es imprescindible el fichero en si para compilar el juego
pero se podría utilizar para editar los sprites y cargarlos de nuevo una vez modificados, como hemos hecho con los Bloques mejorados por
jltursan. Está claro que hace falta crear una aplicación que muestre los 'elementos' gráficos, permita su edición y que genere un fichero de
salida con los datos modificados ...
saludos

[pser1]

Hola,
antes liarme la manta a la cabeza y entrar a saco con el tema de dibujar los sprites, sea con la CPU principal o con el Subsistema, he decidido
echar una ojeada visualmente al fichero que me genera el compilador C
Lo añado a un programa en ensamblador como una include y el contenido se pasa a pantalla ordenadamente.
Los colores los puse al azar, pero debo reconocer que no tuve mucho acierto
En realidad iba probando hacer sprites con color distinto arriba/abajo y otros variando el color de izquierda a derecha en algunas líneas
vamos, que fue pura experimentación en realidad, pero podría haber salido mejor!
Ahora puedo comparar lo que veo en pantalla con los colores que pasé como argumentos en los DEFINESPRITE y si cuadran podré cambiarlos
a otros valores que me parezcan mejor ... Si no cuadraran sería un palo revisar la rutina en C que va chequeando los 8 bits de los 16 bytes de
color y va decidiendo que información enviar a cada plano de color
Una variante simple de este programa me va a servir para visualizar los objetos ...
saludos

SHOWSPT.ZIP

ShowingSprites.jpg

[pser1]

He querido hacer la visualización de objetos muy rápido y ha cascado miserablemente.
La tabla de objetos es 'especial' lleva delante la tabla de imágenes no repetidas (incluyendo colores) y le sigue la tabla de datos de objeto
que, obviamente, no hay que visualizar
Una vez encontrados los problemas, aquí se ve el resultado, a mi pesar, me parecen mas aceptables que los sprites, tal vez porque no tienen
mas que un color por cuadrante ...
saludos

SHOWOBJ.ZIP

ShowingObjects.jpg

[jltursan]

Normal, son más "Spectrum" y estamos más acostumbrados a esa pinta. Los sprites, con los colores correctos, preveo que mejorarán bastante.

[pser1]

Normal, son más "Spectrum" y estamos más acostumbrados a esa pinta. Los sprites, con los colores correctos, preveo que mejorarán bastante.

Totalmente de acuerdo, pero por aquello de que Murphy no descansa nunca, veo que elegí, sin saber que colores pillaba, códigos que
eran variaciones del mismo color en demasiados sprites ...
saludos

[pser1]

Adjunto versiones actualizadas de los tres programas que permiten ver los elementos AGD ...
saludos

SHOWnnn.ZIP

Pd como el fichero de objetos lleva tanto las imágenes como los datos, que no hacen falta para editar las imágenes, los voy a eliminar
haciendo que el compilador y no los inserte ahí.
En las instrucciones fcb que se crean, por supuesto que irán!

[pser1]

Hola,
adjunto aquí las versiones de los tres programas con fondo blanco. Los elementos siguen teniendo SU fondo de color negro pues así es
como se ven en los juegos ...
Si no se desea el fondo blanco basta con comentar la línea

	bsr	WhiteScr			; paint screen white

saludos

SHOWSPT1.ZIP

SHOWOBJ1.ZIP

SHOWBLK1.ZIP

SpritesFondoBlanco.jpg

ObjetosFondoBlanco.jpg

BloquesFondoBlanco.jpg

[pser1]

Hola,
tras muchas sesiones de debug minucioso, he acabado con una versión que es capaz de mostrar los sprites de una pantalla a pesar de que por lo que he podido ver el código está bastante lejos de estar optimizado.
Cuando hice la conversión para el MC6847 la hice línea a línea sin tratar de averiguar el porqué de cada línea ...
Para el V9958 no hizo falta nada puesto que la GPU se hace cargo de todo el manejo de los sprites
Así pues, ahora para el FM77AV es cuando descubriremos algunas partes de código que pueden ser claramente optimizadas
En la versión actual, es la CPU principal quien hace todo el trabajo para dibujar los sprites, lo cual significa bajar a 1,6MHz para poder acceder
a la VRAM con el SUB parado ...
Adjunto fuentes y disco por si alguien quiere echarle una ojeada ...
También adjunto el mapa de memoria actualizado a las necesidades de dibujado de sprites desde la CPU principal
En el pantallazo se ven los SEIS sprites de esta pantalla que, por cierto, son dibujados en dos pasadas, la mitad en cada VSync
No lo considero ni mucho menos la versión definitiva ya que solamente he verificado el funcionamiento de SSpriC
Cualquier comentario será bien recibido!
saludos

FM77DISK-v17.ZIP

SpritesAGD-1erPaso.jpg

[pser1]

Sigo con la rutina SSpriC solamente en marcha, pero parece que ahora ya funciona mejor, o sea sin bugs
Sigue sin estar optimizada. Cuando SSpriA y SSpriB funcionen correctamente intentaré ver si se pueden acelerar algo.
La versión actual (v18) permite ir pasando pantallas mostrando tanto los objetos como los sprites que aparecen al jugar en cada pantalla
saludos

EDITO: Supongo que habría sido un detalle añadir el fichero zip

FM77DISK-v18.zip

[pser1]

hola,
he llevado a cabo algunos cambios en el motor básicamente para dar soporte a los Eventos 12 y 13 que siempre se ejecutan al principio de cada juego
el primero es la Intro/Menú y contiene la función que permite elegir teclado o joystick para jugar, el segundo inicializa variables y, para SPRINGBOT, monta el panel de control de datos en la parte superior de pantalla.
Además he ampliado el 'borde' del juego añadiendo las 8 líneas de pixels de la parte inferior (desde línea 193 hasta 200)
Ahora ya sería cuestión de plantearse si valdría la pena pasarle el dibujado de sprites al subsistema, moviendo datos y tablas a su VRAM
Lo único que veo es que nos pasaremos de los miserables 768 bytes reservados cuanto se le solicita un dominio al subsistema, así que quizás haya
que ver lo que se hace en ShounenMike para utilizar desde $C000- en la ram del subsistema. Lo podemos estudiar en el hilo de "temas AGD"
El siguiente paso según el código AGD std ya sería la función PSpr que 'procesa' los sprites para calcular sus nuevas posiciones para el siguiente
paso por la función DSpr. Esto implica los Eventos Player-1-2-3-4-5-6-7-8 y un montón de funciones para controlar si se pueden mover los sprites,
detectar colisiones y otras lindezas
Adjunto la última versión v24 junto con el mapa de memoria tal como se usa ahora y un documento en el que he ido anotando las funcionalidades
que ya están implementadas en esta versión.
saludos

FM77DISK-v24.ZIP

FM77DISK-v24-1.jpg

FM77DISK-v24-2.jpg

[jimbobaby]

he llevado a cabo algunos cambios en el motor básicamente para dar soporte a los Eventos 12 y 13 que siempre se ejecutan al principio de cada juego
el primero es la Intro/Menú y contiene la función que permite elegir teclado o joystick para jugar, el segundo inicializa variables y, para SPRINGBOT, monta el panel de control de datos en la parte superior de pantalla.

Lo único que veo es que nos pasaremos de los miserables 768 bytes reservados cuanto se le solicita un dominio al subsistema, así que quizás haya
que ver lo que se hace en ShounenMike para utilizar desde $C000- en la ram del subsistema. Lo podemos estudiar en el hilo de "temas AGD"

Tienes dos bitplanes aun "sin usar" en la pagina 0 (8KB*2)

El siguiente paso según el código AGD std ya sería la función PSpr que 'procesa' los sprites para calcular sus nuevas posiciones para el siguiente
paso por la función DSpr. Esto implica los Eventos Player-1-2-3-4-5-6-7-8 y un montón de funciones para controlar si se pueden mover los sprites,
detectar colisiones y otras lindezas

Y sera en ese momento cuando veas si pintando con MAIN es suficiente, o si no basta y hay que tirar de SUB, o si ni tirando de SUB . Ahi sera cuando se puedan medir los tiempos.

[pser1]

Lo único que veo es que nos pasaremos de los miserables 768 bytes reservados cuanto se le solicita un dominio al subsistema, así que quizás haya
que ver lo que se hace en ShounenMike para utilizar desde $C000- en la ram del subsistema. Lo podemos estudiar en el hilo de "temas AGD"

Tienes dos bitplanes aun "sin usar" en la pagina 0 (8KB*2)

Lo se, ahí es donde irían, en su caso las imágenes de los sprites que prácticamente se comen los dos bitplanes (ver mapa de memoria actual ...)
Pensando en pasar el dibujado al Subsistema, se complica la cosa ya que al NO tener acceso (el SUB) a las variables del área $F600 que es donde tenemos la tabla de valores de los sprites en curso, habría que inventarse alguna forma de pasarle comandos pero esto sería a costa de estar haciendo cálculos en la CPU principal también. En fin ya veremos ...
Como me 'aburría', he añadido el comando PSpr y todas las funciones asociadas incluyendo los eventos 3 y 6 para los dos tipos de sprites que aparecen en la pantalla 35 (la primera)
Lo he compilado y, sin anestesia, lo he ejecutado. Hay trabajo de debug para rato, pero los sprites redondos se mueven hacia la derecha elegantemente aunque no se detienen nunca. Algo es algo
saludos