OBJETOS y SPRITES en el FM77AV2

[pser1]

Buenas tardes,
me he decidido a abrir un nuevo hilo para los objetos y probablemente los sprites también.
Hasta ahora hemos visto dos posibles formas de dibujar un objeto de 16x16 píxels, o sea 2 bytes consecutivos en 16 líneas verticales
- La primera y mas 'evidente' es disponer de antemano los cuatro planos de datos o sea 4 x 32 bytes = 128 bytes
Esto permite enviar los datos de forma eficiente a la VRAM a costa de espacio en RAM para tener los cuatro planos que definen los
colores de cada uno de los píxels que forman el dibujo. Máxima libertad en aplicar colores a cada píxel a cambio de usar mas memoria
para guardar la imagen y con el inconveniente de que los colores *ya* están fijados y no podremos modificarlos posteriormente
- La segunda opción sería disponer de la forma del objeto definida en blanco y negro (solo un plano) requiriendo solamente 32 bytes
y habría que añadir una tabla de colores que, en el caso de AGD imitando juegos de Spectrum, implicaría dos colores para cada cuarta
parte del objeto (superior izda, superior dcha, inferior izda, inferior dcha) o sea un total de ocho bytes:
UL-FG,UL-BG,UR-FG,UR-BG,BL-FG,BL-BG,BR-FG,BR-BG
Con esta estructura de datos, una misma forma/imagen podría ser empleada en varios objetos que podrían recibir colores distintos
Inconveniente del sistema, no permite aplicar los 16 colores a cada pixel.
Por lo tanto hemos de decidirnos por uno de los dos sistemas o bien algún otro que vosotros propongáis en este hilo
En el próximo mensaje subiré dos rutinas para dibujar los objetos, una para cada uno de las dos opciones antes mencionadas
saludos

[pser1]

Adjunto un fichero fuente ASM que contiene dos rutinas para dibujar objetos
- DrawObj para el método que se basa en disponer de los 4 planos (128 octetos)
- DrawObjX para el otro método
Además he adjuntado el listo de la compilación con LWASM que contiene los ciclos que usa cada instrucción. Así podemos comparar los tiempos
necesarios en cada caso además de ver la diferencia de tamaño del código.
Estos son los resultados

DrawObj		--->	  	     41
DObjL1		--->   226 x  4 =   904
		--->    	     19
TOTAL		--->   964 cycles
		--->   139 bytes

DrawObjX	--->    	     84  
DObjXL1		--->    19 x  4 =    36
DObjXL2		--->   100 x 16 = 1.600
		--->    	     23
ObX0Quad	--->    49 x  4 =   196
ObXFQuad	--->    46 x  4 =   184
ObBGQuad	--->    77 x  4 =   308
ObFGQuad	--->    69 x  4 =   276
TOTAL		---> 2.707 cycles
		--->   477 bytes

Sorprendentemente el segundo método que permite reusar las formas, utiliza casi el triple de tiempo (ciclos de reloj) que el otro método y para rematarlo ocupa casi cuatro veces el espacio del otro ...
Está claro que el sistema que he usado para el segundo método no debe ser el mejor posible así que se admite cualquier sugerencia para mejorar tanto el uso de memoria como el tiempo de ejecución.
saludos

OBJCYCLE.zip

[jimbobaby]

Hasta ahora hemos visto dos posibles formas de dibujar un objeto de 16x16 píxels, o sea 2 bytes consecutivos en 16 líneas verticales
- La primera y mas 'evidente' es disponer de antemano los cuatro planos de datos o sea 4 x 32 bytes = 128 bytes
Esto permite enviar los datos de forma eficiente a la VRAM a costa de espacio en RAM para tener los cuatro planos que definen los
colores de cada uno de los píxels que forman el dibujo. Máxima libertad en aplicar colores a cada píxel a cambio de usar mas memoria
para guardar la imagen y con el inconveniente de que los colores *ya* están fijados y no podremos modificarlos posteriormente
- La segunda opción sería disponer de la forma del objeto definida en blanco y negro (solo un plano) requiriendo solamente 32 bytes
y habría que añadir una tabla de colores que, en el caso de AGD imitando juegos de Spectrum, implicaría dos colores para cada cuarta
parte del objeto (superior izda, superior dcha, inferior izda, inferior dcha) o sea un total de ocho bytes:
UL-FG,UL-BG,UR-FG,UR-BG,BL-FG,BL-BG,BR-FG,BR-BG

Pues depende de lo que vayas mas apurado, cpu o ram

Me falta ahi una mascara. A no ser que el propio bitmap que define el sprite sea mascara a su vez, pero eso me pareceria raro.

Una idea seria, asumiendo la segunda opcion (32bytes de sprite monocromo + 32 bytes de mascara + 4x2 colores), un bitplane para sprite (tal cual), otro bitplane para la mascara (tal cual), y luego colorear (1 byte pinta 8 pixeles del mismo color solido, 1 cuadrante). Y claro esta, ajustar la paleta para que entre la mascara y el sprite monten la "tabla de verdad" para ver si los otros 4 bits de color se acaban viendo, o se ve negro o transparente.

Claro que con eso te comes los bitplanes en 0 coma (6 de golpe) y aunque cada bitplane individual pueda ser mas o menos optimo, es un 50% extra de render time por la cantidad de bitplanes (ademas de la complejidad de calcular la paleta, aunque eso sea mas un one-off).

Esto del planar es un dolor de webis para la mayoria de usos (salvo pintar tiles muy anchos, rellenar o transparencias)

Le doy una vuelta a ver si se me ocurre algo...

[pser1]

Pues depende de lo que vayas mas apurado, cpu o ram
Me falta ahi una mascara. A no ser que el propio bitmap que define el sprite sea mascara a su vez, pero eso me pareceria raro.

Estaba hablando de objetos que no se van a mover de sitio hasta que lo recoja el jugador. No hace falta máscara por tanto.
Para el caso spectrum AGD con dos colores por área 8x8 entonces cuando hay que aplicar el color del fondo, basta con usar el complemento a
unos del byte de la forma. En el fichero ASM se puede ver que la rutina ObBGQuad lee dos bytes y los invierte antes de enviarlos a la VRAM
Cuando en un plano (bit de color) coexisten tinta y papel, se usan bytes a 255 ($FF). Así que habría que buscar algún procedimiento o algoritmo
mejor que el que he utilizado.
De todas formas, si queremos permitir que los objetos tengan 16 colores en cualquier pixel, la opción de tenerlos definidos ya con los colores en 4x32 bytes parece la mejor opción. Incluso se podría tener la definición (128 bytes) en tabla aparte para reusar estas definiciones en mas de un objeto cuando haya mas de uno con el mismo color como es el caso de SPRINGBOT. He jugado con el .tap de Spectrum y los diamantes siempre me salen de color amarillo ...
saludos

[pser1]

Una corrección importante a las valoraciones de ciclos/espacio ocupados por las dos variantes para mostrar Objetos
- La segunda 'solo' ocupa 1,5 veces lo que la primero, *NO* cuatro veces como dije. Grave error de cálculo
Mientras espero la llegada de alguna idea sobre como mejorar cualquiera de estas dos rutinas, voy a seguir con el motor y la
primera parte que viene es la inicialización de objetos, así que voy a tomar la opción de solo 32 bytes mas 8 de colores
a ver si es 'soportable' el número de ciclos que requiere ...
saludos

[pser1]

Hola,
os subo la versión FM77DISK-v08B que ya muestra los objetos de una pantalla siguiendo el procedimiento AGD
Esta versión se basa en objetos que tienen su imagen definida con 32 bytes (1 solo plano) en la tabla objImg
Luego en la tabla objDta tiene el número de imagen, 4 bytes de colores y los datos típicos de pantalla, posY,posX ...
Para agilizar la rutina de dibujo, los datos de la imagen deben venir primero los 8 bytes del cuadrante arriba izquierda, luego los de
arriba derecha, seguidos de abajo izquierda y abajo derecha.
Por desgracia, el compilador AGD que uso para V9958 me genera la imagen de los objetos como 16 filas de dos bytes por lo que hará falta
un cambio en dicho programa C. De momento lo he cambiado manualmente
Además, para reducir la ocupación de la tabla de colores, he pasado de un byte por color a un nibble, juntándolos así
FGarribaDerecha+FGarribaIzquierda,BGarribaDerecha+BGarribaIzquierda,FGabajoDerecha+FGabajoIzquierda,BGabajoDerecha+BGabajoIzquierda
De esta forma las rotaciones hacia la derecha de los bytes 1 y 2 sacan primero los colores FG/BG de la izquierda y luego los de la derecha
simplificando también el código ...
Como siempre, encontraréis los fuentes ASM, los binarios, los listados de la compilación y el disco virtual
saludos

FM77DISK-v08B.ZIP

Objects-FM77AV-AGD.jpg

[pser1]

Hola de nuevo,
he tratado de añadir un bucle para poder pasar de una pantalla a otra y así ir viendo los objetos de todas las pantallas ...
Sorpresa! Estaba utilizando los datos de la estructura del objeto para hacer las rotaciones a derecha con lo que al finalizar
los colores quedaban a cero
Ahora los copia a un área de trabajo que es la que sufre las rotaciones. Problema resuelto
La versión FM77DISK-v08C permite pasar a la siguiente pantalla con 'P' y a la anterior con 'O'. Para finalizar pulsad "Espacio"+ ControlIzquierdo
si es la tecla que tenéis vinculada en XM7 al Espacio Izquierda.
saludos

FM77DISK-v08C.ZIP

[pser1]

Hola,
Actualmente, la estructura de datos de un objeto en la tabla "objDta" es la siguiente, copiada del fuente FM77CODE

Código: Seleccionar todo

WObjImage	equ	00		; image number associated to the object
WObjColTF	equ	01		; received FG default colours for top right-left quadants
WObjColTB	equ	02		; received BG default colours for top right-left quadants
WObjColBF	equ	03		; received default colours (FG/BG) for botom left quadant
WObjColBB	equ	04		; received default colours (FG/BG) for botom right quadant
WObjRoom	equ	05		; working room number
WObjPosY	equ	06		; working vertical coordinate
WObjPosX	equ	07		; working horizontal coordinate
IObjRoom	equ	08		; initial room number
IObjPosY	equ	09		; initial vertical coordinate 
IObjPosX	equ	10		; initial horizontal coordinate 

El número de imagen asociado es un número de 0 a 255 que permite buscar los datos de la forma del objeto en la tabla "objImg"
Esta tabla contiene simplemente los 32 bytes que definen la forma del objeto en un bitplano (B/N)
¿Os parece suficiente esta estructura a la vista del resultado obtenido?
o por el contrario, ¿Preferiríais trabajar con definiciones a cuatro planos o sea 128 bytes?
Quedo a la espera de vuestras opiniones antes de pasar al tema de los sprites de nuevo ...
saludos

[jltursan]

Yo la verdad es que al igual que los bloques, siendo estáticos los objetos, siempre preferiría el presentarlos con los cuatro planos y por tanto, me parece muy relevante el añadir ese byte con la imagen asociada a ese objeto.
Como comentabas, se pierde la posibilidad de presentar el mismo objeto con diferentes colores; pero la verdad, no suelen necesitarse tantas versiones del mismo objeto como para que no se puedan redibujar cada uno de ellos y aprovechar todo el detalle en cada uno.

Con los sprites, pues pienso algo parecido. Sólo me parecererían sacrificables los cuatro planos si se tuviera algún motor de sprites que no recurriera siempre a los cuatro planos y fuera capaz de pintar un sprite monocromo escribiendo únicamente en los planos necesarios (hasta un máximo de 3 si se decidieran limitar los colores a 8).

Todo lo anterior sin perder de vista el consumo de memoria, claro. En 48K no metes esto ni queriendo.

[pser1]

Yo la verdad es que al igual que los bloques, siendo estáticos los objetos, siempre preferiría el presentarlos con los cuatro planos y por tanto, me parece muy relevante el añadir ese byte con la imagen asociada a ese objeto.
Como comentabas, se pierde la posibilidad de presentar el mismo objeto con diferentes colores; pero la verdad, no suelen necesitarse tantas versiones del mismo objeto como para que no se puedan redibujar cada uno de ellos y aprovechar todo el detalle en cada uno.

La verdad es que a mi no me gusta la idea de tener las definiciones con 128 bytes por objeto. Por ejemplo en SPRNGBOT para V9958 casi no he repetido colores en los objetos y a pesar de ello solo debo guardar 5 imágenes, una por tipo de objeto. Esto reduce el uso de memoria a solo 160 bytes para todos los objetos, en la tabla objImg por supuesto
Si decidiera guardar 128 bytes entonces ocuparía en la tabla objImg 49x128= 6.272 bytes. Desgraciadamente en el mapa de memoria solamente
tengo reservados 4.096 bytes para las dos tablas de objetos
Esto no significa que no pueda hacerse, pero habría que cambiar el mapa de memoria para prever 8192 bytes para las tablas de objetos y además habría que cambiar la rutina de dibujado para dejar de usar bytes de colores y simplemente llenar bitplanes como con los partrones.
Viendo la conversión de objetos de Spectrum AGD que los tiene todos en color blanco porqué deja que sean los patrones sobre los que se
coloca cada objeto quienes decidan los colores que debe adoptar y comparándola con dar color a los cuatro cuadrantes, lo cierto es que
no veo gran diferencia de calidad de imagen.
No sé, si dispones de una versión 'mejorada' de los objetos, podrías subirla y haré una versión nueva de FM77CODE para que pueda trabajar
con los nuevos objetos.

Con los sprites, pues pienso algo parecido. Sólo me parecererían sacrificables los cuatro planos si se tuviera algún motor de sprites que no recurriera siempre a los cuatro planos y fuera capaz de pintar un sprite monocromo escribiendo únicamente en los planos necesarios (hasta un máximo de 3 si se decidieran limitar los colores a 8).Todo lo anterior sin perder de vista el consumo de memoria, claro. En 48K no metes esto ni queriendo.

Por supuesto que los sprites podrían ser igual que los objetos, 16x16 y definidos a 128 bytes (4 planos)
Pero ahí si tropezaremos con AGD que se permite modificar los colores de un sprite al vuelo ... No lo veo fácil así a botepronto, quizás tendríamos
que darle unas cuantas vueltas mas
saludos

[jltursan]

Sip, estoy de acuerdo en lo que comentas; pero claro, como decía yo lo ligo todo a la disponibilidad de memoria, si se tiene RAM, hay que usarla

Lo más parecido a lo que me he enfrentado es en los MSX2, con el V9938 lo que hago es comprimir toda la información gráfica referente a bloques y objetos y al inicializar, descomprimo todo eso en una página de VRAM, aprovechando que toda esa memoria es independiente de la RAM principal. Me caben los 256 bloques y hasta 128 imágenes de objetos.

Con los sprites, que van aparte, la historia es diferente. Los sprites los mantengo en RAM y van rotando en la VRAM según se necesitan. Como ya sabes, mantenía los 16 bytes de color; pero permito que el comando SPRITEINK reescriba la tabla con un único byte. Lo que no recuerdo es si implementé otro comando que hacía un "restore" de los patrones de color.
Con eso, permitía decidir si quería que un sprite hiciera un "flash" o simplemente dejarlo monocromo; todo ello, sin perder la posibilidad de verlo multicolor.

[pser1]

Buenos días,
te has adelantado con tu respuesta. Este mensaje o había preparado esta mañana y parece que no fué enviado correctamente
En cuanto pueda, voy a tratar de modificar la copia del compilador C para V9958 de forma que obtenga los datos de los Patrones en el formato
que queremos para el FM77AV y miraré como podría hacer lo mismo para los objetos (formato ampliado a 128 bytes)
Pensándolo bien, supongo que sería mejor que el compilador aceptara definiciones de objetos formato ampliado, esto reduce mucho el tiempo de pintado!
Trataré de obtener ficheros aparte como hice con el MC6847 y también para el V9958 además de generar código ensamblador con líneas fcb
saludos

[pser1]

Sip, estoy de acuerdo en lo que comentas; pero claro, como decía yo lo ligo todo a la disponibilidad de memoria, si se tiene RAM, hay que usarla
Lo más parecido a lo que me he enfrentado es en los MSX2, con el V9938 lo que hago es comprimir toda la información gráfica referente a bloques y objetos y al inicializar, descomprimo todo eso en una página de VRAM, aprovechando que toda esa memoria es independiente de la RAM principal. Me caben los 256 bloques y hasta 128 imágenes de objetos.

Como en el FM77AV disponemos de nada menos que 64Kb de EXTended ram, no creo que sea un problema reservar $2000 (8192 bytes) para las dos tablas de objetos. No creo que haga falta exagerar y llegar al doble (16.384 bytes).
Actualmente creo que solo he empleado la mitad, desde $0000 hasta $7FFF por lo que nos sobra para mas cosas ...

Con los sprites, que van aparte, la historia es diferente. Los sprites los mantengo en RAM y van rotando en la VRAM según se necesitan. Como ya sabes, mantenía los 16 bytes de color; pero permito que el comando SPRITEINK reescriba la tabla con un único byte. Lo que no recuerdo es si implementé otro comando que hacía un "restore" de los patrones de color.
Con eso, permitía decidir si quería que un sprite hiciera un "flash" o simplemente dejarlo monocromo; todo ello, sin perder la posibilidad de verlo multicolor.

Esto me recuerda lo que hice para el V9958 donde los sprites estan en memoria y se suben cuando hacen falta a la VRAM
Allí es fácil cambiar de color, solo machacando la tabla de 16 bytes de color por sprite te permite hacer lo que quieras, pero con el FM77AV estamos atados de pies y manos
Desafortunadamente es la forma del sprite la que lleva guardada la información de colores así que no barrunto ninguna forma de cambiarle el color a un sprite aunque no tengo claro que esto vaya a ser un gran inconveniente!
Así que, de momento, voy a prever que objetos y sprites lleguen con 128 bytes (4 planos), de esta forma igual se pueden reusar algunas subrutinas
Como dije antes, voy a meterme con el compilador de C a ver si puedo obtener los datos de Patrones, Objetos y Sprites en formato 4 planos.
saludos

[pser1]

Hola,
estaba pensando que, ya que vamos de ricos en lo que a EXTended ram se refiere, no me hace falta para nada tener dos tablas para
los objetos, una para la imagen y otra para sus datos/atributos, si lo pongo todo en una sola, me ahorro un puntero ya que lo tengo todo a mano.
Probablemente pondré la imagen al final, para no usar offsets grandes.
Si hago esto, le dejaré $4000 (16.384 bytes) a objetos. Espero no pasarme y agotar pronto la EXTram
Le veo un pequeño problema/incordio a reservar tanto espacio ...
Para acceder a los datos de objetos necesitaré mapear digamos que EXT ram $6000-$9FFF a RAM $8000-$BFFF que son cuatro páginas
Luego para dibujar en VRAM se necesitan dos páginas mas que serán obligatoriamente $C000-$DFFF cuando para modificar bytes en pantalla
he estado mapeando siempre $A000-$BFFF
A lo largo de tus conversiones de juegos, ¿Has encontrado alguno que utilizara mas de 64 objetos? Yo no recuerdo ninguno ahora mismo ...
saludos

CORRECCION: He visto que os juegos CAPS1-2-3 llegan a tener 121 objetos
Esto representa casi la totalidad de los 16Kb, realmente 121 objetos x (128 imagen + 6 datos) = 16.214 ... qué peligro

EDITO: Y los mas patético del caso CAPSn es que TODOS los objetos se pintan con los mismos colores, cosa que parece que se podría tratar
mejor separando datos en dos tablas ... Confusión TOTAL

[jltursan]

No me creo que haya 121 objetos totalmente diferentes, ya sea por imagen o color. Utilizando una tabla de imágenes, en un caso como este seguro que se ahorra una barbaridad.

[pser1]

No me creo que haya 121 objetos totalmente diferentes, ya sea por imagen o color. Utilizando una tabla de imágenes, en un caso como este seguro que se ahorra una barbaridad.

Por supuesto, peo no podemos hacer excepciones para casos concretos, así que tendré que mantener el sistema de dos tablas y añadir el número de imagen a la tabla pequeña de solo 7 bytes por objeto con imagen, pantalla, posY,poX, y las tres últimas con los valores iniciales ...
El peñazo será en el compilador C ir descubriendo si un objeto ya ha sido creado con la misma imagen anteriormente para utilizar dicho número de imagen
saludos