Temas AGD

[pser1]

PAL16C2.jpg (18.89 KiB) Visto 458 veces

_Spectrum Palette 15 colours.jpg (16.39 KiB) Visto 458 veces

Estos son los colores a cuadrar. A la izquierda vemos los empleados en MSX-V9958
Y a la derecha están los equivalentes de Spectrum 48K

Código: Seleccionar todo

; ---------------------------------------------------------------------------
;MSX	COLOUR NAME		SPC	COLOUR
; ---------------------------------------------------------------------------
; 0 	TRANSPARENT 	 
; 1 	BLACK				0,8	BLACK
; 2 	BRIGHT GREEN	  (?) no existe en Spectrum
; 3 	LIGHT GREEN		12		BRIGHT GREEN
; 4 	DEEP BLUE		  1		BLUE
; 5 	BRIGHT BLUE		9		BRIGHT BLUE
; 6 	DEEP RED			2		RED
; 7 	LIGHT BLUE		 5,13	CYAN - BRIGHT CYAN  (solo uno en MSX)
; 8 	BRIGHT RED		 10		BRIGHT RED
; 9 	LIGHT RED		  (?) no existe en Spectrum
; A 	BRIGHT YELLOW	 6		YELLOW
; B 	PALE YELLOW		14		BRIGHT YELLOW
; C 	DEEP GREEN		 4		GREEN
; D 	DEEP PURPLE		3,11	PURPLE - BRIGHT PURPLE (MAGENTA) (solo uno en MSX)
; E 	GREY				 7		GREY
; F 	WHITE				15		WHITE
; ---------------------------------------------------------------------------

Claramente en MSX-V9958-FM77AV2 no tenemos previstos los colores
- Cyan claro
- Magenta claro
Pero tenemos una tercera opción (no usada) para
- color 2 - Verde brillante (ya usamos 3 y 12)
- color 9 - Rojo claro (ya usamos 6 y 8)
Parecería, pues, lógico cambiar estos terceros colores por los que no tenemos implementados.
De esta forma conseguiríamos pantallas con los colores mas parecidos a los de Spectrum.
Podría utilizar el color 2 para contener el Cyan claro, y el color 9 para contener el Magenta claro

Jamás había caído en estos detalles, me he limitado a programar y reutilizar valores de tablas usadas en otras plataformas

¿Que os parece la idea de modificar la paleta para asemejarla lo mas posible a los colores originales de los juegos AGD (Spectrum 48k)
saludos

[jltursan]

Sí, yo también me refería al compilador de C, no tengo en cuenta para nada la "paleta" del Spectrum dado que en ningún momento me planteé la conversión automática de los juegos de Spectrum.

En un caso como el del FM77AV, que me imagino que tendrá casi nulo soporte por parte de programadores occidentales y si media un milagro, escaso por parte de los japoneses, no parece mala idea hacer algo parecido a lo que hiciste con el Dragon, automatizar en lo posible la conversión de las fuentes que ya tienes. Esto igual si que se le puede preguntar a malik si se abre un hilo (ese sí en inglés) a propósito.

¿Realmente te planteas una adaptación al FM77AV?, eso ya me parece una pasada suprema y un sujétame la cerveza de aúpa

Si vas en serio, considero imprescindible que se de soporte a la paleta tal como hice en la versión MSX2. Por defecto se puede inicializar con la compatible Spectrum; pero proporcionar un comando para redefinirla.

[pser1]

Sí, yo también me refería al compilador de C, no tengo en cuenta para nada la "paleta" del Spectrum dado que en ningún momento me planteé la conversión automática de los juegos de Spectrum.
En un caso como el del FM77AV, que me imagino que tendrá casi nulo soporte por parte de programadores occidentales y si media un milagro, escaso por parte de los japoneses, no parece mala idea hacer algo parecido a lo que hiciste con el Dragon, automatizar en lo posible la conversión de las fuentes que ya tienes. Esto igual si que se le puede preguntar a malik si se abre un hilo (ese sí en inglés) a propósito.

La verdad es que me parece mejor mantener el método empleado para CoCo-Dragón con el V9958 y tratar de usar los mismos colores
que se emplean en el juego original de Spectrum.

¿Realmente te planteas una adaptación al FM77AV?, eso ya me parece una pasada suprema y un sujétame la cerveza de aúpa
Si vas en serio, considero imprescindible que se de soporte a la paleta tal como hice en la versión MSX2. Por defecto se puede inicializar con la compatible Spectrum; pero proporcionar un comando para redefinirla.

Es una idea, de momento, hay que salvar unas cuantas dificultades antes de lanzarse al vacío
En cualquier caso añadir soporte para cambiar colores de la paleta en los ficheros AGD me parece una buena idea aunque dudo que alguien
haga un juego/programa para esta máquina usando el entorno AGD. No será simple convertir los gráficos para el FM77AV
Por ahora nadie lo he hecho ni para CoCo-Dragón en B/N ni para el V9958
saludos

[pser1]

He cambiado el color Negro a código 0 en lugar de 1
En el color 1 está un gris claro extra, no relacionado a ningún color de Spectrum
El color 2 ahora es Cyan oscuro, antes no existente
El color 9 ahora es Magenta oscuro, antes no existente
De esta forma no hay repetidos en la tabla ni colores no empleados, salvo el 1
Así queda la tabla para el compilador ...
unsigned short ConvertColours( unsigned short oldCol)
unsigned short int convCol[16]={0,4,6,13,12,7,10,14,0,5,8,9,3,2,11,15};
saludos

PaletaFinalFM77AV2.jpg (18.94 KiB) Visto 441 veces

[pser1]

Pasemos al siguiente punto en que se diferencian las pantallas para el V9958 y para el FM77AV2
La resolución horizontal es de 32 bytes en V9959 mientras que el FM77AV tiene 40 bytes por línea
Está claro que no podemos modificar la anchura de los tiles para adaptarnos al mayor numero de pixels disponibles
V9958 tiene 32 tiles x 8 pixels = 256 pixels
FM77AV podría tener 32 tiles x 10 bits = 320 pixels
La hipotética conversión de 8 a 10 pixels no la veo viable y esto sin hablar de como mostrarlos ...
En las pantallas que he subido en el hilo "TILES on the FM77AV2" lo que he hecho ha sido añadir cuatro tiles con color de fondo (negro)
tanto a la izquierda como a la derecha, centrando la imagen.
Esto implica que se verá algo mas 'pequeña' la imagen comparado con como se ven en el V9958, pero habrá que vivir con ello
Si se os ocurre alguna otra posibilidad para ocupar toda la pantalla ya me diréis.
saludos

[jimbobaby]

Está claro que no podemos modificar la anchura de los tiles para adaptarnos al mayor numero de pixels disponibles
V9958 tiene 32 tiles x 8 pixels = 256 pixels
FM77AV podría tener 32 tiles x 10 bits = 320 pixels
La hipotética conversión de 8 a 10 pixels no la veo viable y esto sin hablar de como mostrarlos ...
En las pantallas que he subido en el hilo "TILES on the FM77AV2" lo que he hecho ha sido añadir cuatro tiles con color de fondo (negro)
tanto a la izquierda como a la derecha, centrando la imagen.
Esto implica que se verá algo mas 'pequeña' la imagen comparado con como se ven en el V9958, pero habrá que vivir con ello

¿Borde? ¿Que borde?

Nada, asi como esta le da un toque mas Spectrum . Yo lo veo perfecto. Con pixel art y tamaños tan poco divisibles, no puedes hacer otra cosa, y no vas a inventar tiles en una "enhanced display edition".

[jltursan]

Evidentemente no queda otra que "centrar" la ventana. La otra implica el cambiar el código fuente para reorganizar la ventana de juego, los marcadores, etc.

Eso sí, a ver si puede ser con un flag que active el modo de compatibilidad o ventana centrada; que si lo que pretendes es usar las 40 columnas que te ofrece el FM77AV, que puedas hacerlo. De hecho, la opción por defecto debería ser esta última, el modo nativo si no especificas el modo "Spectrum".

[pser1]

Evidentemente no queda otra que "centrar" la ventana. La otra implica el cambiar el código fuente para reorganizar la ventana de juego, los marcadores, etc.
Eso sí, a ver si puede ser con un flag que active el modo de compatibilidad o ventana centrada; que si lo que pretendes es usar las 40 columnas que te ofrece el FM77AV, que puedas hacerlo. De hecho, la opción por defecto debería ser esta última, el modo nativo si no especificas el modo "Spectrum".

Hola,
de momento para las pruebas iniciales voy a mantener la tabla de tiles como 32x24 como en el V9958, pero mas adelante lo pasaré a 40x24
así si alguien, caso sumamente improbable, decidiera crear un juego AGD podría emplear la pantalla entera ...
Además las definiciones de tiles, objetos y sprites deberían poder hacerse en modo 16 colores en lugar de solo dos (fondo y tinta) pero esto
ya es harina de otro costal
El paso en que estoy ahora mismo es pasar el código de dibujado de pantalla al subsistema. Previamente habré cargado en el bitplane G1
los tiles y al principio del G0 pondré la tabla de tiles (mapa de la pantalla en curso)
Intento usar el comando IKEMOTO para reservar el máximo (768 bytes), luego debo enviar el código por acceso directo a la zona reservada
y finalmente tengo que declarar/definir los comandos que soportará el subsistema. De momento uno, el $80=Dibujar pantalla ...
Va a ser entretenido!
saludos

[jimbobaby]

El paso en que estoy ahora mismo es pasar el código de dibujado de pantalla al subsistema. Previamente habré cargado en el bitplane G1
los tiles y al principio del G0 pondré la tabla de tiles (mapa de la pantalla en curso)
Intento usar el comando IKEMOTO para reservar el máximo (768 bytes), luego debo enviar el código por acceso directo a la zona reservada
y finalmente tengo que declarar/definir los comandos que soportará el subsistema. De momento uno, el $80=Dibujar pantalla ...

Bueno, si 768 bytes se quedan cortos... nadie ha dicho que en VRAM solo puedan haber pixeles...

[pser1]

Bueno, si 768 bytes se quedan cortos... nadie ha dicho que en VRAM solo puedan haber pixeles...

Hola,
en la versión que subiré mañana, que ya utiliza el Subsistema para pintar la pantalla completa, he ubicado los tiles en los bitplanes G1-G0
y la tabla del layout de 'pantalla en curso' al final de la G0, ocupando 768 bytes ($300)
Como ahora paso a modo 'todo RAM', dispongo de mas memoria en las 32Kb bajas de RAM porqué prácticamente no se pagina nada salvo el I/O
Así que he podido meter las 39 pantallas del juego Springbot

Para cuando empiece con el motor AGD, entonces las pantallas las cargaré en la RAM extendida, a partir de $00000 (banco 0), esto requerirá
un par de mapeos para leer los datos de una pantalla que, en el peor caso, estará a caballo entre dos páginas consecutivas.
Vamos, que ya podemos empezar a buscar en el 'Shounen Mike' como gestiona los sprites
saludos
pere

[pser1]

Hola,
subo aquí el programa que ya utiliza el comando IKEMOTO para reservar un dominio en la RAM del subsistema donde luego envío
el código necesario para dibujar una pantalla.
Antes de llamar a esta función del SUB, el programa en la CPU principal descomprime los datos de la definición de pantalla correspondiente
y los coloca en la VRAM final del bitplane G0 que equivale a la antigua tabla 'tileCpy'
La función de dibujar la pantalla utiliza las definiciones de tiles/patrones que previamente se han subido a los bitplanes G1-G0
Esta versión permite ver la totalidad de pantallas del juego 'SPRINGBOT' que son 39
Como en las versiones anteriores, P para siguiente pantalla, O para anterior y E para salir. Siempre en Mayúsculas!
saludos
pere

SHOWSCR7.ZIP

(161.33 KiB) Descargado 10 veces

[jimbobaby]

Antes de llamar a esta función del SUB, el programa en la CPU principal descomprime los datos de la definición de pantalla correspondiente
y los coloca en la VRAM final del bitplane G0 que equivale a la antigua tabla 'tileCpy'
La función de dibujar la pantalla utiliza las definiciones de tiles/patrones que previamente se han subido a los bitplanes G1-G0
Esta versión permite ver la totalidad de pantallas del juego 'SPRINGBOT' que son 39

Muchas gracias

Despues de pegarle un vistazo, asi pensando en voz alta...
-Ahora, de momento y solo para esto que esta haciendo (dibujar pantalla), se ha pasado de toda la carga en MAIN a casi toda la carga a SUB.
-No se cuanta memoria ocupa todo lo "gordo" (tiles, sprites, definicion de pantallas...). Entiendo que sera mas "critico" la parte de los sprites (por aquello del tiempo real) que el dibujo de cada pantalla. Ahora va mas rapido que la version MAIN+MMR, claro, pero a costa de meter tiles en VRAM.
Mirare de hacer pruebas con un modelo hibrido (texturas en (extended)RAM, calculo de tile en MAIN y pintado en SUB). De esa forma podria liberarse VRAM y igual no va tan lento comparativamente. De todas formas, todo dependera de si se va sobrado de VRAM o no, claro, si se va sobrado no tiene sentido.
-¿Como lo debian hacer en los 80? Con 2 CPUs medir el rendimiento de forma precisa y saber donde lo pierdes tenia que ser una pesadilla

[pser1]

Muchas gracias
Despues de pegarle un vistazo, asi pensando en voz alta...
-Ahora, de momento y solo para esto que esta haciendo (dibujar pantalla), se ha pasado de toda la carga en MAIN a casi toda la carga a SUB.
-No se cuanta memoria ocupa todo lo "gordo" (tiles, sprites, definicion de pantallas...). Entiendo que sera mas "critico" la parte de los sprites (por aquello del tiempo real) que el dibujo de cada pantalla. Ahora va mas rapido que la version MAIN+MMR, claro, pero a costa de meter tiles en VRAM.
Mirare de hacer pruebas con un modelo hibrido (texturas en (extended)RAM, calculo de tile en MAIN y pintado en SUB). De esa forma podria liberarse VRAM y igual no va tan lento comparativamente. De todas formas, todo dependera de si se va sobrado de VRAM o no, claro, si se va sobrado no tiene sentido.
-¿Como lo debian hacer en los 80? Con 2 CPUs medir el rendimiento de forma precisa y saber donde lo pierdes tenia que ser una pesadilla

Hola,
veamos, para pintar una pantalla hacen falta alguna operaciones:
- Calcular la posición en la que empiezan los datos comprimidos de la pantalla requerida, actualmente en RAM std
- Descomprimir estos datos y guardarlos en una tabla, antes llamada cpyTile, ahora VRAM bitplane G0 final
- Leer esta tabla y acceder a los datos de cada tile que están en VRAM bitplanes G1-G0
- dibujar en los bitplanes B1-B0-R1-R0 de VRAM los bloques de 32 bytes de cada tile
Las dos primeras operaciones las realiza la CPU principal, mientras que las otras dos las lleva a cabo la SUB
De esta forma, mientras esté 'pintando' la pantalla, la CPU principal podrá calcular las nuevas posiciones que ocuparán los sprites ...

Ahora voy a añadir una subrutina que enviará los datos de las pantallas a la memoria extendida, bloque 0 para liberar espacio para el
motor AGD y el programa AGD compilado. Las pantallas ocupan unos 13.120 bytes y los tiles 6.754 bytes
Luego tendré que modificar la parte que descomprime pantalla y llena la tabla en VRAM.
saludos
pere

[pser1]

Hola,
he modificado la rutina que pasa los tiles/patrones a VRAM para que además copie los datos de pantallas comprimidas a la memoria
extendida a partir de $0000.
La rutina que rellena el 'layout' de la pantalla actual, ahora utiliza los datos de la memoria extendida.

Hechos estos pasos, ya podré desdoblar el programa en dos.
La primera parte se encargará de enviar los tiles a VRAM y las pantallas a la memoria extendida.
Puede que incluso haga que cargue los ficheros de datos (tiles, pantallas, objetos, sprites)
La segunda parte llenará el layout de la pantalla solicitada por teclado y pasará el comando "Mostrar pantalla" al subsistema
y mas adelante llevará el motor AGD y el juego compilado
saludos
pere

SHOWSCR8.ZIP

(161.62 KiB) Descargado 9 veces

[pser1]

Hola,
Ahora que ya tenemos algo que nos permite mostrar pantallas hechas con patrones y dibujar-mover sprites por pantalla, voy a añadir
una parte importante como es el texto con el que mostraremos las puntuaciones y mensajes en su momento ...
saludos

[pser1]

Hola,
como primer paso, os adjunto versión AGDDISK-vB1 que ya se atreve a mostrar cadenas de caracteres tamaño normal aplicándoles color
Me he pasado un poco y le hago cambiar de color a cada letra ... exagerado que es uno
He extraído el código de impresión de texto del motor para MC6849 y lo he adaptado para el FM77AV2, así ya vamos empezando a crear
el futuro motor AGD para esta máquina. Pasito a pasito!
Voy a ver si puedo hacer una versión simple que pinte letras grandes (doble altura como en AGD)
saludos

AGDDEMO-vB1.ZIP

(240.93 KiB) Descargado 4 veces

TEXT-DEMO.jpg (59.31 KiB) Visto 153 veces