TILES / PATRONES / BLOQUES en el FM77AV2

[pser1]

Cualquier cosa de la VRAM que toques no la ves al momento. La veras en el frame siguiente, o, si tienes la opcion de raster activada, lo veras en el mismo frame si y solo si se ha modificado antes de que el barrido de pantalla (emulado, claro) llegue a esa linea (si acaba de pasar no lo veras hasta el frame siguiente).

OK, lo cierto es que la ventana de mostrar los bitplanes de VRAM en XM7 funciona perfectamente.

El mecanismo de tile painting esta pensado para los tres RGB (como tantas cosas, herencia del FM7 original con 8 colores). Segun como organices la memoria y como la uses puedes bloquear la escritura de uno de los "colores"(2 bitplanes x 2 bancos en modo B) , pero tambien significa que en vez de tener el speedup x3 por usar tile paint, tendrias "solo" x2 (que un x2 esta genial, pero viniendo de un x3 es un downgrade ).

En realidad solo usamos 4 bitplanes, luego borrar los otros dos bitplanes sería una pérdida de tiempo

Si, eso es una de las cosas que ando pensando. No es que sea momento de optimizar ahora, ni mucho menos, primero porque es mejor tener una base que funcione y sea clara antes de "romperla" con optimizaciones que no entiende ni el tato , y segundo para no optimizar lo que no es necesario.
En el caso de los sprites, ademas, dibujarlos en coordenadas modulo 8 != 0 es un dolor de eggs . No veo forma sencila de hacerlo, y no es plan de almacenar versiones preshifted de todos los sprites.

No me preocupa el tema de mover solo dos pixels. Está resuelto en el motor AGD para Blanco y Negro (MC6847) y no hace falta tener preshifted sprites. En su lugar se emplean tres tablas de 256 bytes que devuelven el valor ya
'desplazado' 2,4,6 pixels. Lo miraré pero creo que solo hay 3 tablas para esto = 768 bytes en lugar de cuadruplicar la definición de cada frame de todos los sprites!

Tambien tengo una duda (generica y un poco offtopic) sobre el AGD. A nivel de editor/framework/engine, tiene las especificaciones que tiene, por tanto entiendo que, independientemente de que se puedan portear mas o menos de forma directa los juegos ya existentes, si se quisiera hacer un "remaster" de uno de ellos (o uno completamente nuevo) aprovechando al maximo, los limites los marcaria AGD o nuestra capacidad con la maquina?

Si vas a utilizar el framework AGD/MPAGD, te verás limitado por los límites hardware de la máquina para la que trabajes. Si existiera un entorno que generara para MSX entonces podríamos aprovecharlo, pero me temo que no existe aún. Puedo estar equivocado y tal vez alguien ya lo haya compartido ...
saludos

[pser1]

Como primera aproximación voy a copiar la definición del jugador del juego SPRINGBOT y trataré de pintarlo en pantalla y si va bien,
entonces probaría ya con todos los sprites que hay en cada pantalla, con lo cual al cambiar de pantalla veríamos todos los enemigos
que pululan por ahí ...
De entrada haré como en V9958, 16 colores máximo, uno por cada línea horizontal y así iremos viendo como queda
saludos

[pser1]

Hola,
primer contratiempo, no grave, pero si bastante molesto.
Resulta que en el último zip que subí, con los fuentes de SHOWS91, SHOWS92 y el disco SHOWS91.d77 hay una diferencia importante
entre el fuente ensamblador y el binario realmente incluido en el disco
Como he intentado hacerme un bat que me compile directamente el 91 como Loader y el 92 como Engine, me fallaba siempre al
probar el resultado. Aparece la primera pantalla, pero se bloquea el programa en HALT
La versión desensamblada del binario que funciona es bastante diferente de la que me guardé, así que tendré que revisar los cambios
para disponer de una versión a utilizar para añadir los sprites. Me da la impresión de que la versión que me funciona es la anterior a
la optimización de los mapeos. Traté de hacerlos solo una vez, antes los hacia a cada llamada a dibujar pantalla, ya veré
saludos

[pser1]

Hola de nuevo,
tras un buen rato de 'recuperación' del fichero perdido, usando parte del desensamblado del binario que si funciona, estoy de nuevo
con una versión operativa, pero que 'pierde' bastante tiempo.
Habrá que modificarla para que no mapee tantas veces, procurando que no quede colgada como la última versión que fallaba
De momento os dejo aquí los fuentes y ficheros relacionados con nombres ya adecuados al sistema AGD
saludos

AGDDISK.ZIP

[jimbobaby]

Hola de nuevo,
tras un buen rato de 'recuperación' del fichero perdido, usando parte del desensamblado del binario que si funciona, estoy de nuevo
con una versión operativa, pero que 'pierde' bastante tiempo.
Habrá que modificarla para que no mapee tantas veces, procurando que no quede colgada como la última versión que fallaba
De momento os dejo aquí los fuentes y ficheros relacionados con nombres ya adecuados al sistema AGD
saludos
AGDDISK.ZIP

De nada..

[pser1]

De nada..

muchas gracias!
Veamos, la parte de AGDLOAD veo que has desdoblado la rutina que pinta los cuatro bitplanes de los Tiles, es una buena idea, pero el coste
es excesivo bajo mi punto de vista. La versión anterior emplea ocho opcodes STA indexados pero con offsets pequeños, inferiores a 256
o sea un octeto salvo el último que se pasa. La nueva versión emplea demasiados con offsets de 16 bits, que ocupan mucha memoria y
son mas lentos.
Probablemente calculando ciclos resultaría mejor hacer un LEAX $2000,X y seguir empleando offsets de un byte ... ver adjunto.
En cuanto a la parte AGDCODE, prefiero que el MMR esté deshabilitado en cuanto sea posible ya que tenerlo activo implica que la CPU
principal baja de 2Mhz a solo 1,6MHz y el motor tendrá que hacer muchas cosas entre llamada y llamada al SUB.
Para acceder al layout de tiles en pantalla se usa la parte final del bitplane G0, desde $BD00 hasta $BFFF por lo tanto no hace falta
mapear los tiles que están a partir de $A0000 ya que los utiliza el Subsistema que accede a ellos directamente.
Adjunto v1.2 de AGDDISK.d77
saludos

AGDDISK-v1.2.ZIP

[pser1]

revisando el fichero LST obtenido en la compilación de AGDLOAD, he visto que hay demasiados offsets de 16 bits, así que he decidido
darle otra vuelta a la tuerca ...
Adjunto AGDDISK-v1.3
saludos

AGDDISK-v1.3.ZIP

[pser1]

Hola,
ya he añadido los sprites del juego SPRINGBOT al fichero AGDLOAD junto con la posición de los enemigos en cada pantalla.
Luego he añadido código en AGDCODE para pintar los sprites tratando de hacer algo parecido a lo que se hace en el BLK 122 de 'Shounen Mike'
De momento el código me compila bien, pero se ejecuta de pena
Tengo por delante una buena tanda de trazado de esta parte nueva. Como solo se utiliza la CPU principal para dibujar, no tendré
que preocuparme por el código añadido al Subsistema para, mas adelante, borrar parte de un sprite al moverlo ...
saludos

[jimbobaby]

De momento el código me compila bien, pero se ejecuta de pena

Bueno, supongo que era de esperar . Si tienes que estar con datos planar, tablas preshifted, pintando por software, directamente sobre la pantalla y a 60 Hz, puesss... igual parpadea un poquito

Pero bueno, hay que empezar por algun sitio

[pser1]

Bueno, supongo que era de esperar . Si tienes que estar con datos planar, tablas preshifted, pintando por software, directamente sobre la pantalla y a 60 Hz, puesss... igual parpadea un poquito
Pero bueno, hay que empezar por algun sitio

Hola,
de momento, tras haber corregido algunos errores he llegado hasta la rutina que 'debe' dibujar el sprite. Sigo trazando ...
Por ahora solo dibujo el sprite donde indica el script AGD para cada pantalla, siempre es en posiciones exactas centrado en bytes,
más adelante cuando deba moverse, ya añadiré las tablas pre-desplazadas, que ocupan 1024 bytes, no 768 como dije días atrás.
saludos

[pser1]

Hola,
ya consigo que me pinte todos los sprites que debe haber en una pantalla pero, para variar, me sigo liando con historias del subsistema
así que una vez completado el trabajo, el subsistema queda en un estado que produce un bloqueo (cuelgue) en cuanto se intenta un HALT
que es lo primero que hace la rutina de lectura de teclado ...
A ver si mañana lo encuentro!
Por si alguien quiere echarle una ojeada, os adjunto la versión v1.4 del juego SPRINGBOT. La pantalla inicial es la 22, que además del jugador
tiene dos enemigos que parecen ruedas de colores verdosos
saludos

SPRINGBOT v1.4.jpg

AGDDISK-v1.4.ZIP

[pser1]

había olvidado un detallito de nada
Cuando cambiamos de pantalla, redibujamos el fondo con los tiles de la nueva, pero los sprites permanecerán ahí, o sea que,
seguramente, valdrá la pena añadir al Subsistema la rutina de 'Shounen Mike' que borra el banco #0 de VRAM aplicando TilePainting
A ver si hoy puedo dedicarme un rato a comparar el procedimiento empleado en DibujarPantalla con el DibujarSprites en cuanto a HALT,D409,$D10,D430,SUBRST, Mapeos y algún otro que puedo estar olvidando ahora mismo ...
saludos

[pser1]

Hola,
en un rato he podido anotar en un fichero de texto las llamadas del programa AGDCODE para dibujar la pantalla y los sprites
Os lo adjunto, con errores ya encontrados anotados en comentarios, por si alguien encuentra el verdadero problema que hace
que se 'cuelgue' al finalizar de pintar sprites e ir a leer el teclado llamando la función HALT
En cuanto me sea posible haré los cambios mencionados en este documento y trataré de imitar para sprites lo que hago para pantallas ...
saludos

RunningSequenceAGDCODE.zip

[pser1]

Hola,
tras simplificar un poco las operaciones relativas a mapeo y control de VRAM, la versión que os subo ahora ya no se cuelga y admite
las teclas O y P para cambiar de pantalla. Como todavía no he añadido la función de borrado de sprites (VRAM banco #0) pues se van sumando
sprites al ir cambiando de pantalla hasta ser infumable
Añadiré la función y haré unos retoques a la función de dibujo del sprite para optimizarla un poco, tampoco es el objetivo principal ...
saludos

AGDDISK-v1.6.ZIP

Nota: Deberíamos considerar esta versión la 1.5 en realidad, ya que me la he saltado por prisas

[jimbobaby]

Ya he descubierto (no lo bastante rapido ) porque se colgaba la version anterior.

Al dibujar sprites, parabas SUB para poder pintar en VRAM, pero no ponias un comando dummy al levantar de nuevo SUB, con lo cual se quedaba "loopao" esperando un comando que jamas llega...

Código: Seleccionar todo

clr	$FC81       			; continue flag off
ldd	#$6400      			; continue command(dummy)
std	$FC82						; in shared area
jsr	SUBRST					; restart subsystem

Habria que añadir esto al final de la rutina de dibujar sprites, justo al levantar SUB

[pser1]

Ya he descubierto (no lo bastante rapido ) porque se colgaba la version anterior.
Al dibujar sprites, parabas SUB para poder pintar en VRAM, pero no ponias un comando dummy al levantar de nuevo SUB, con lo cual se quedaba "loopao" esperando un comando que jamas llega...

Código: Seleccionar todo

clr	$FC81       			; continue flag off
ldd	#$6400      			; continue command(dummy)
std	$FC82						; in shared area
jsr	SUBRST					; restart subsystem

Abria que añadir esto al final de la rutina de dibujar sprites, justo al levantar SUB

Muchas gracias jimbobaby
He tenido un rato para hacer pruebas y un poco de inspiración porqué reconozco que me ha costado entender el orden en que hay que
realizar estas operaciones. Si echas una ojeada a la última versión que he subido, verás que he cambiado muchas operaciones hacia el
final del dibujado de sprites, ahí encontrarás justamente el código que tu dices!
Como he dicho antes, ahora tengo que añadir la función de borrado de los bitplanes B1-B0-R1-R0 en el banco #0 (sprites) y seguramente
reduciré algunos opcodes en la rutina de dibujado de sprite.
Añadir movimientos a los sprites no va a resultar simple. En primer lugar necesitamos una subrutina para substituir a la que
se usa por defecto para los IRQ donde podamos detectar la llegada de cada interrupción de retrazado, 60 por segundo.
Esto permitiría ver la velocidad de movimiento aunque sea de 8 pixels en 8 pixels.
Creo que malikto999 nos mostró en un ejemplo que utilizando el teclado de forma que devuelva código en lugar de valor ASCII se consigue
una velocidad mucho mas rápida, luego nos interesa.
Y la parte mas importante, hay que crear una tabla de 'atributos' de los tiles que conforman la pantalla para saber cuales son Pared y cuales
son 'transitables', imprescindible para saber hacia donde mover los sprites 'enemigos'. Digamos que ya empieza a pedir partes del motor AGD
para gestionar movimientos, choques, etc. Habrá que ir avanzando como podamos
saludos