OBJETOS y SPRITES en el FM77AV2

[jltursan]

Ah, ya veo por donde vas.

Yo siempre planteo nuevas sintaxis en cada archivo AGD según la máquina la que va destinada, un comando DEFINEOBJECT diferente en el que no esté incluida la imagen (que se definiría empleando otra instrucción, al estilo de DEFINEOBJECTIMAGE o similar).

Para lo que tu dices, siempre puedes generar un checksum MD5 para cada objeto que proceses y asociarlo con su número.

[pser1]

Ah, ya veo por donde vas.
Yo siempre planteo nuevas sintaxis en cada archivo AGD según la máquina la que va destinada, un comando DEFINEOBJECT diferente en el que no esté incluida la imagen (que se definiría empleando otra instrucción, al estilo de DEFINEOBJECTIMAGE o similar).
Para lo que tu dices, siempre puedes generar un checksum MD5 para cada objeto que proceses y asociarlo con su número.

Yo estaba pensando en usar la fuerza bruta, es decir comparar los 128 octetos correspondientes al objeto en curso con cada una de las imágenes ya guardadas. Si encuentra una, utiliza este número, sino sigue y al final lo añade como otra imagen mas si no ha encontrado ninguna.
En C esto va a ser suficientemente rápido como para no notarlo, espero
Actualmente yo tengo dos definiciones de objeto:
DEFINEOBJECT y DEFINEOBJ4C el primero es el std de AGD y el otro era 'mi variante' para objetos con cuatro pares de colores, uno por cuadrante.
Ambas definiciones generan el objeto a 32 bytes y cuatro bytes de colores.
Para el FM77AV posiblemente elija el DEFINEOBJECT para que convierta los 32 bytes en cuatro planos de colores mientras que el DEFINEOBJ4C lo
podría reaprovechar para que 'espere' recibir 128 bytes en el fichero AGD
Ya iremos viendo sobre la marcha como manejarlo, pero debo mantener la opción de convertir la escasa info de Spectrum AGD a formato 4 planos
saludos

[jltursan]

Sí, en el caso del FM77AV me parece fundamental el mantener viva siempre la posibilidad de soportar las conversiones de los originales del ZX.

De todas formas, ¿no sería más fácil un conversor externo que transformara los recursos del ZX a los del FM77AV?. Básicamente pasar todo a 4 planos, aunque fuese de forma literal, sin aprovechar la ventajas del FM77AV.

[pser1]

Sí, en el caso del FM77AV me parece fundamental el mantener viva siempre la posibilidad de soportar las conversiones de los originales del ZX.
De todas formas, ¿no sería más fácil un conversor externo que transformara los recursos del ZX a los del FM77AV?. Básicamente pasar todo a 4 planos, aunque fuese de forma literal, sin aprovechar la ventajas del FM77AV.

Lo cierto es que lo estoy haciendo fuera del compilador, me refiero que es un simple programa C que debería generarme las fcb para los tiles y también el fichero binario por si en algún momento podemos /queremos editar su contenido ...
Cuando funcione lo añadiré al compilador de esta forma me lo hará todo de golpe en lugar de ir paso a paso ...
Cuando funcione correctamente el generador de tiles, haré lo mismo para objetos y finalmente para sprites aunque sobre esto aun tenemos que hablar y explorar algunos temillas
saludos

[jltursan]

Pues nada ya me iras contando. De momento en el Springbot no hay objetos que valgan (cosa que me sorprende ya que veo que hay "llaves" y por lo que veo, no son sprites) así que poca cosa habrá que rediseñar.

[pser1]

Pues nada ya me iras contando. De momento en el Springbot no hay objetos que valgan (cosa que me sorprende ya que veo que hay "llaves" y por lo que veo, no son sprites) así que poca cosa habrá que rediseñar.

Hola,
me ha costado lo suyo recordar la sintaxis en C para algunas conversiones de datos. No voy a decir que ha sido coser y cantar, pero tampoco ha sido
tremendamente complicado
He creado un compilador AGDFM77.C como copia del AGDV9958.C que una vez compilado, valga la redundancia, genera el AGDFM77.EXE que es capaz de procesar los ficheros AGD que le pasemos como parámetro, por ejemplo AGDFM77 SPRNGBOT 0 siendo 0 el valor de flags (ninguno)
Os adjunto en el zip tanto el fuente en C como el resultado de compilarlo, junto con ficheros relevantes para el tema de los Tiles/Patrones
SPRNGBOT.blk que contiene los Patrones tal como los lee de AGD (solo 10 bytes por cada uno: Tipo, forma y color)
SPRNGBOT.PAT que contiene el formato gráfico de cuatro planos en el orden adecuado para el nuevo motor en fase de desarrollo.
SPRNGBOT.inc es el fichero en ensamblador que genera el compilador. Para el caso que nos afecta solo nos interesa la creación de bloques y propiedades que se pueden ver en las tablas chgFx para los bloques y bProp para las propiedades (tipo de bloque)
saludos
Pd El resultado de la compilación AGDFM77.EXE es rechazado por el sistema de subida de ficheros a pesar de estar dentro del ZIP
Si fuera necesario para alguien ya buscaríamos otro camino ...

[pser1]

tal como habíamos hablado con jltursan, el espacio de objetos pasa a ser de $4000 (16.384 bytes) en lugar de solo $2000 como tenía hasta ahora
Debido a esto ha cambiado la zona de mapeado de la pantalla de $A000-$BFFF a $C000-$DFFF. El motivo es que para dibujar objetos necesitamos
mapear EXT ram desde $06000 hasta $09FFF a las direcciones $8000-$BFFF que solapan las antiguas direcciones de mapeo usadas al trabajar con pantallas.
He modificado el fuente tanto FM77LDA1 para que copie los datos a las nuevas áreas reservadas y el FM77CODE para que los use correctamente
Veréis en el nuevo mapa de memoria que adjunto en el zip que tanto mensajes como fonts han sido desplazados hacia abajo en la EXT ram
La versión actual con estos cambios y utilizando el fichero de patrones de jltursan es la FM77DISK-v09E
saludos

FM77DISK-v09E.ZIP

[pser1]

Antes de ponerme a modificar el Compilador C para que genere los fcb con datos de objetos para el fichero ensamblador y genere también el fichero binario de objetos en el nuevo formato de 128 bytes por imagen, he estado tratando de maximizar el número de imágenes de objetos a guardar a partir de $6000 sin perjudicar el número de entradas en la tabla de datos. He optado por estos nuevos valores:
Reservo el rango $6000-$9BFF para imágenes y $9C00-$9FFF para datos
Esto permite 15.360 bytes/128 = 120 imágenes diferentes y 1024 bytes para datos dan para 146 objetos
Así pues, ya he cambiado las constantes que definen el principio de ambas tablas y ha funcionado sin problemas
Adjunto FM77DISK-v09G junto con el nuevo mapa de memoria ...
saludos

FM77DISK-v09G.ZIP

Pd. Había subido la versión v09F que es anterior a los cambios aquí mencionados. He sustituido el fichero zip por el que contiene la v09G

[pser1]

Hola,
parece que ya tengo a punto el compilador C para generar las dos tablas para objetos, la de imágenes y la de datos
En principio usa los cuatro colores que recibe en el fichero AGD, uno por cuadrante y solo en caso de recibir el primer color igual a cero
busca en el mapa de pantallas las tiles/patrones que serán sobrescritos por el objeto y una vez averiguados los números de tile/patrón,
accede a una tabla de colores donde "CreateBloques" ha guardado el color de cada uno.
Aparentemente genera correctamente las líneas fcb para cada tabla
Adjunto aquí para quien quiera echarle una ojeada el compilador C y el resultado de la aplicación sobre SPRINGBOT.AGD
El fichero resultante es SPRINGBOT.inc pero además se genera un fichero binario con ambas tablas separadas por una imagen todo ceros
el nombre del fichero es SPRNGBOT.OBJ
Ahora tendré que sustituir los fcb en FM77LDA1.ASM para ver cuan grande es el binario resultante y luego comprobar que los datos siguen
generando los mimos objetos sin cambiarles los colores
saludos

CompilandoObjetos.ZIP

[pser1]

Tras copiar los fcb al FM77LDA1.ASM tuve que substituir la función de dibujar objetos que dependía de los bytes de color por la que no había
probado nunca que simplemente envía los datos a los 4 planos de color secuencialmente.
Tras algunas correcciones, muestra todos los objetos con la forma adecuada, pero con los colores erróneos.
Obviamente esto es culpa de compilador en C que llena los cuatro planos en un orden que me pareció el correcto, pero va a ser que requiere
revisión ...
saludos

NuevosObjetos128bytes.jpg

[pser1]

Hola,
era mas simple de lo previsto!
El compilador funciona correctamente. El problema es que yo preparé la paleta para sprites/objetos contando que trabajaría con los bytes que
indican a que planos hay que enviar la imagen y esto conlleva la inversión de los bits 1-2 y 3-4 respectivamente.
He modificado la paleta para dejarla como estaba antes de llevar a cabo estas inversiones
Ahora cuando menos muestra los colores que se han previsto en el compilador en función de los colores recibidos en la descripción de los objetos
Os adjunto un pantallazo de los objetos obtenidos con la versión v09G y otra con los de la v10 que es la última.
Veo alguna 'sutil' diferencia de colores, pero me parecen mas correctos los que se van ahora.
En todo caso si hubiera que cambiar algo, habría que cambiarlo en el compilador donde de momento solo hay una función para convertir los colores y es utilizada tanto por los patrones/tiles como por los objetos ... y con los cambios que hicimos en la paleta para los patrones, creo que debería
disponer de dos funciones, cada una aplicando la conversión correspondiente a la paleta del tipo de elemento que procesa.
saludos

OldObjects-v09G.jpg

NewObjects-v10.jpg

[jltursan]

Buena pinta tiene

[pser1]

con las prisas olvidé subir la última versión que ya dibuja los objetos a cuatro planos gráficos como los bloques/patrones
Considero definitiva esta parte y quedo a la espera que aclaremos el tema de los colores en ambas paletas
saludos

FM77DISK-v10.ZIP

[pser1]

Una vez corregida la v10 con los cambios sugeridos por jimbobaby os subo la v11
En ella he cambiado el método de cambio de colores en el margen volviendo a usar la redefinición del color #1 en lugar de repintar los márgenes
cada vez. Al cambiar de pantalla se calculan tres nuevos valores parra GRB del color #1 y se aplican de inmediato.
Al salir del programa se realizan 15 cambios de color ...
Como el bucle principal todavía no hace nada ... la velocidad de parpadeo de los bloques es exagerada, así que he ampliado los tiempos necesarios
para que parpadeen. Creo que ahora es mas 'soportable' y uniforme, todos los bloques parpadeantes en la pantalla están sincronizados, no como antes que había algunos que casi no se les veía el parpadeo
saludos

FM77DISK-v11.ZIP

[pser1]

Le he cambiado el título a este hilo para tratar aquí mismo tanto de Objetos como de Sprites
La estructura de Objetos parece ya firme, una tabla de imágenes ya en cuatro planos de color y otra tabla de objetos con los datos que indican
donde deben ser usados incluyendo el número de imagen a utilizar. Por tanto NO se puede cambiar el color de un objeto una vez definido ...
Dicho esto, pasemos a los sprites.
Esta es la estructura de datos que tengo para el V9958

Código: Seleccionar todo

;;; ix+0  = type
;;; ix+1  = VRAM Atribute Pointer high byte
;;; ix+2  = VRAM Atribute Pointer low byte
;;; ix+3  = VRAM Colour Data Pointer high byte
;;; ix+4  = VRAM Colour Data Pointer high byte
;;; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
;;; ix+5  = new type
;;; ix+6  = new image number
;;; ix+7  = new frame
;;; ix+8  = new Y coord
;;; ix+9  = new X coord
;;; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
;;; ix+10 = direction
;;; ix+11 = parameter 1
;;; ix+12 = parameter 2
;;; ix+13 = jump pointer low (in the air flag)
;;; ix+14 = jump pointer high (step in jump tabe)
;;; ix+15 = data pointer low
;;; ix+16 = data pointer high
;;; 1x+17 = frame 0 to be used by this sprite in VRAM as 4 patterns block
;;; ix+18 = current image number
;;; ix+19 = number of frames used by current image

Mientras que para el MC6847 en blanco y negro la estructura es

Código: Seleccionar todo

; Sprite table.
; ix+0  = type.
; ix+1  = sprite image number.
; ix+2  = frame.
; ix+3  = x coord.
; ix+4  = y coord.

; ix+5  = new type.
; ix+6  = new image number.
; ix+7  = new frame.
; ix+8  = new x coord.
; ix+9  = new y coord.

; ix+10 = direction.
; ix+11 = parameter 1.
; ix+12 = parameter 2.
; ix+13 = jump pointer low.
; ix+14 = jump pointer high.
; ix+15 = data pointer low.
; ix+16 = data pointer high.

En cualquier caso, la imagen viene como 32 bytes (en blanco y negro) ya que el color se le asigna directamente en el fichero AGD.
Como ya hemos hecho con los objetos, lo mas razonable parece tener las imágenes como 4x32=128 bytes ya coloreadas.
En V9958 el movimiento lo realiza el solito, pero con el MC6847 y con el FM77AV necesitaríamos tener las imágenes por cuadruplicado (la orginal mas tres desplazadas 2,4,6 pixels a la derecha) para crear el movimiento/animación. La alternativa es emplear las tablas pre-desplazadas que ya tengo
en EXT ram ocupando 1024 bytes. Usarlas va a hacer la rutina de dibujo algo mas complicada pero al menos habrá que probarlo ...
saludos

[pser1]

Hablemos de Sprites ...
Si dedicamos la VRAM que no usamos en el banco #0, o sea de $18000 hasta 1BFFF = $4000 -> 16.384 bytes lo máximo que podríamos tener ahí
serían 128 imágenes de 128 bytes (4x32 ya coloreadas).
Esta cantidad me parece mas que suficiente, pero no da para crear 4 versiones de cada sprite para disponer de las copias desplazadas a 2,4 y 6
píxels ya que bajaríamos a solamente 32 sprites, cifra que parece suficiente pero me da la impresión de que mas de un juego tendrá mas de este límite de 32 sprites diferentes.
Si nunca nos tropezaremos con un juego con mas de 32 sprites, podríamos evitar el uso de las tablas pre-desplazadas que seguro que ralentizan
el proceso de dibujado ...
Lo único que se puede garantizar es que nunca hay mas de 16 sprites en una pantalla, pero en el conjunto de todo un juego se puede exceder
de 32, lo malo es que ahora mismo no recuerdo ningún juego con tantos sprites y lo peor es que NO existe una variable/constante que nos diga
cuantos sprites se han definido en el fichero AGD.
Intentaré mirar varios juegos que tal vez dispongan de muchos sprites, pero no puedo estar seguro de no olvidar uno que rompa el esquema
Evidentemente la alternativa mas segura es no duplicar sprites y basarnos en las tablas predesplazadas que, por cierto, ya tenemos cargadas
en la ram EXTENDIDA ocupando 1024 bytes.
Cualquier idea será super bien recibida
saludos