Comandos especiales en el V9958

[pser1]

Último mensaje de la página anterior:

Bueno, la verdad es que la carga inicial en VRAM me sale muy barata. Dado que de momento todo se carga desde disco y para ello empleo un cargador en MSX-BASIC, es desde este cargador desde donde voy ejecutando las cargas de cada bloque gráfico de manera que cuando el juego arranca, ya está todo en su sitio listo pasa ser usado. El compilador ya se encarga de hacer todas las transformaciones de datos y de generar los archivos de carga de pantallas estandar en el MSX-BASIC (que no son más que poco más que un volcado raw de los datos de la VRAm tal cual).

La verdad es que yo también había pensado en crear un fichero de patrones y objetos que son los que requieren mas bytes ahora, pero esto sería
básicamente para reducir el espacio en memoria del juego en si, cosa que permitiría juegos mayores ...
Pero para CoCo-Dragón habrá que preparar un binario que suba a la VRAM estos ficheros que previamente serán cargados en memoria, así que
va a tener que usar comandos HMMC
Lo que veo es que para hacer mas rápida la carga de patrones, por ejemplo, se deberían alinear de 32 en 32 de forma que ocuparían 128 bytes
y así se podrían enviar todos con un solo comando HMMC a pesar de que en la última fila de patrones podría haber varios a ceros.
Tengo que ver como puedo hacer que el compilador haga este trabajo antes de crear el fichero ASM
Y para los objetos otro tanto, tendría que alinearlos de 16 en 16 para llenar los 128 bytes de una fila y rellenar con ceros la última fila
¿Como preparas los ficheros para hacer mas rápida la carga a VRAM en MSX-BASIC?
saludos
pere

[jltursan]

Genero archivos compatibles con los comandos BLOAD ...,S que en MSX-BASIC permiten cargar directamente datos a la VRAM. Creo dos archivos y los cargo antes de arrancar el juego en sí, cada uno en su página.
Dado que en Dragon también empleas un cargador BASIC lo tienes fácil, sólo tienes que leer el archivo en cuestión y transferirlo a la VRAM, lo mismo que hago yo. El compilador para generar esos archivos, lee el AGD y recompone la imagen siguiendo el orden de un bitmap G4 y genera un binario al que le añade la cabecera para que pueda ser cargado con BLOAD. En tu caso podrías dejar el binario raw y tener por ahí la rutina que transfiera bloques a VRAM.

[pser1]

Genero archivos compatibles con los comandos BLOAD ...,S que en MSX-BASIC permiten cargar directamente datos a la VRAM. Creo dos archivos y los cargo antes de arrancar el juego en sí, cada uno en su página.
Dado que en Dragon también empleas un cargador BASIC lo tienes fácil, sólo tienes que leer el archivo en cuestión y transferirlo a la VRAM, lo mismo que hago yo. El compilador para generar esos archivos, lee el AGD y recompone la imagen siguiendo el orden de un bitmap G4 y genera un binario al que le añade la cabecera para que pueda ser cargado con BLOAD. En tu caso podrías dejar el binario raw y tener por ahí la rutina que transfiera bloques a VRAM.

Buenas tardes,
tendré que modificar el compilador como dije antes para que genere dos ficheros, uno con 8.192 bytes para patrones y otro para objetos que
posiblemente limite a 16K donde cabrían 128 objetos. Dudo que algún juego utilice tantos! Por supuesto, le añadiré la cabecera para Dragón
aunque cuando se haga para CoCo-Dragón las cabeceras son distintas y habrá que añadirlas en el proceso de montaje en el PC
Los tendré que cargar a RAM con un LOAD"file.BIN" y luego llamar a la rutina que los copiará de RAM a VRAM
Estoy dudando de la velocidad del comando HMMC, así que me voy a preparar dos rutinas, una usando el puntero std a la VRAM como está usando
la versión G3 del motor AGD ahora mismo, y otra rutina que envíe el comando HMMC y vaya enviando mas bytes cuando el bit TR de S#2 sea 1,
enviando bytes al R#44. Esta combinación de esperar al bit de S#2 y luego enviar 1 byte a R#44 me parece super lenta, pero voy a escribir
el código y le añadiré los ciclos de cada instrucción para facilitar la comparación ...
saludos
pere

[pser1]

Hola,
he preparado un programa que, conteniendo 8192 bytes para subir a VRAM, borra la pantalla y luego envia los datos
usando el sistema del puntero a VRAM luego vuelve a borrar pantalla y envía los mismos datos mediante el comando HMMC
Una vez verificado que la pantalla se llena con los mismos dibujos con ambos sistemas, he escrito los ciclos de reloj empleados
en cada uno de ellos. Adjunto cada rutina con sus cálculos por separado
Para mi sorpresa, el comando HMMC tarda casi el TRIPLE que el método antiguo con el puntero automático ...
De todas formas, debo decir que ambas rutinas se ejecutan en un periquete y las hago funcionar a velocidad normal, o sea 0.89MHz
Los tiempos serían:
- Std con puntero -> 147.487 ciclos / 0,89MHz = 165.716 usec => 166 milisegundos ... no está nada mal!
- comando HMMC -> 393.414 ciclos / 0,89MHz = 442.038 usec => 442 milisegundos ... casi medio segundo, pero es rápido

Tal vez sobre código en la rutina que envía el comando HMMC
Si vierais algo que se puede reducir, decídmelo y lo aplicaré ...
muchas gracias
pere

Código: Seleccionar todo

DoPtr      ldx   #PDATA         ; point to VDP port#0
         ldu   #tileDta            ; point to data beginning in RAM
         bsr   WaitVDP            ; first must verify that VDP is free!
                           ; point to VRAM desired address
         ldd   #$008e      ; 03 (03)   ; get address high byte and register
         sta   1,x         ; 05 (08)   ; send address high byte to port #1
         stb   1,x         ; 05 (13)   ; send register number to port #1
         clrd               ; 02 (15)   ; to begin  from $0000
         stb   1,x         ; 05 (20)   ; send address low byte to port #1
         adda   #$40         ; 02 (22)   ; set write flag on
         sta   1,x         ; 05 (27)   ; send address medium byte + write flag to port #1
         ldy   #8192         ; 04 (31)   ; number of bytes to send
         
                           ; PREVIOUS = 31 cycles
         
                           ; begin data transfer
NextByte   lda   ,u+         ; 06 (06)   ; get a byte (1 pixel)
         sta   ,x            ; 04 (10)   ; send to VDP port #0
         leay   -1,y         ; 05 (15)   ; decrement counter
         bne   NextByte      ; 03 (18)   ; not yet done? loop
         
                           ; 8.192 x 18 = 147.456 cycles
                           ; TOTAL = 147.456 + 31 = 147.487 cycles
         
         rts                  ; return

Código: Seleccionar todo

DoHMMC   ldx   #PDATA            ; point to VDP port#0
         ldu   #tileDta            ; point to data beginning in RAM
         bsr   WaitVDP            ; first must verify that VDP is free!
                           ; send command HMMC
         lda   ,u+         ; 06 (06)   ; get first data byte
         sta   frstByte      ; 04 (10)   ; put as 1st byte to be sent
         ldd   #$2491      ; 03 (13)   ; indirect addressing - set R#17 b7=0 (auto increment - start at register 36)
         sta   1,x         ; 05 (18)   ; Port#1, send desired first register
         stb   1,x          ; 05 (23)   ; Port#1, to indirect addressing register R#17 setting autoincrement
         ldy   #hmmcDta      ; 04 (27)   ; point to params structure
         ldb   #COMBYTES   ; 02 (29)   ; bytes to send

SendMor   lda   ,y+         ; 06 (06)   ; get a byte
         sta   3,x         ; 05 (11)   ; send to port #3
         decb               ; 01 (12)   ; decrement counter
         bne   SendMor      ; 03 (15)   ; not yet done? loop
         
                           ; 11 x 15 = 165 cycles to send the command HMMC
         
         ldy   #8192         ; 04 (04)   ; number of bytes to send

                           ; PREVIOUS = 165 + 29 + 4 = 198 cycles

                                    ; poll for TR to be 1 before sending next byte
NextVal   ldd   #$028f      ; 03 (03)   ; to access S#2 via R#15
         sta   1,x         ; 05 (08)   ; send status register number
         stb   1,x         ; 05 (13)   ; send register number + bit7 set
TrLoop   lda   1,x         ; 05 (18)   ; get status data
         rola               ; 01 (19)   ; send bit7 to carry (TR)
         bcc   TrLoop      ; 03 (22)   ; if not set (still busy), loop *** LET'S ASUME ALWAYS FOUND READY AT FIRST CHECK ***
         ldb   #44+$80      ; 02 (24)   ; get register 44
         lda   ,u+         ; 06 (30)   ; get one byte
         sta   1,x         ; 05 (35)   ; send value
         stb   1,x         ; 05 (40)   ; to R#44
         leay   -1,y         ; 05 (45)   ; decrement counter
         bne   NextVal      ; 03 (48)   ; not yet done? loopback
         
                           ; 8.192 x 48 = 393.216 cycles
                           ; TOTAL = 393.216 + 198 = 393.414 cycles
         
         rts                           ; return

[pser1]

Hola,
El método del puntero envia los patrones abajo ($2000 - )
El comando HMMC los envia a $0000 -
saludos
pere

Comparacion800.jpg (98.56 KiB) Visto 246 veces

[jltursan]

Si lo piensas, es absolutamente lógico que HMMC sea tremendamente más lento que un envío lineal mediante CPU . Donde en el primer caso estás leyendo unos registros y enviando a otros unos valores; mediante la CPU envías datos a un único registro con una pequeña espera entre cada uno.
La ventaja del HMMC aparece cuando trabajas con una superficie no lineal en VRAM. Dado que cada scanline va a necesitar un reposicionado del puntero de la VRAM, cuanto más alta sea la superficie, más ventajoso resultará el comando. Cuanto más ancho, pues peor. Luego está el tema de optimizar lo que te dije, testear el tiempo que le lloeva a la CPU en cuestión el volcar datos a registros, de manera que no sea necesario leer el bit TR dado que el VDP habrá acabado antes que la CPU y ya estará libre. Con este truco se puede acelerar un poco más la ejecución.

[pser1]

Si lo piensas, es absolutamente lógico que HMMC sea tremendamente más lento que un envío lineal mediante CPU . Donde en el primer caso estás leyendo unos registros y enviando a otros unos valores; mediante la CPU envías datos a un único registro con una pequeña espera entre cada uno.
La ventaja del HMMC aparece cuando trabajas con una superficie no lineal en VRAM. Dado que cada scanline va a necesitar un reposicionado del puntero de la VRAM, cuanto más alta sea la superficie, más ventajoso resultará el comando. Cuanto más ancho, pues peor. Luego está el tema de optimizar lo que te dije, testear el tiempo que le lloeva a la CPU en cuestión el volcar datos a registros, de manera que no sea necesario leer el bit TR dado que el VDP habrá acabado antes que la CPU y ya estará libre. Con este truco se puede acelerar un poco más la ejecución.

Hola,
absolutamente de acuerdo. Probablemente para el tema de los textos sería interesante utilizar el HMMC y seguir con el puntero
a VRAM para la carga inicial.
Cuando pueda trataré de eliminar el control de bit TR para ver sin con uno o dos NOPs basta para funcionar.
Además de tardar el triple, también ocupa mas bytes de memoria
saludos
pere

[pser1]

Ya he hecho la prueba "pasando" del bit TR y además sin añadir un solo NOP de espera ... perfecto!
Además he eliminado la estructura de datos para el comando HMMC y el bucle que emplea bastantes ciclos.
Al llamar al HMMC a piñón sin puntero ocupa mas bytes, pero se ejecuta en la mitad de tiempo!
Adjunto el recuento de ciclos ahora para el comando HMMC

Código: Seleccionar todo

DoHMMC   ldx   #PDATA            ; point to VDP port#0
         ldu   #tileDta            ; point to data beginning in RAM
         bsr   WaitVDP            ; first must verify that VDP is free!
                           ; send command HMMC
         ldd   #$2491      ; 03 (03)   ; indirect addressing - set R#17 b7=0 (auto increment - start at register 36)
         sta   1,x         ; 05 (08)   ; Port#1, send desired first register
         stb   1,x          ; 05 (13)   ; Port#1, to indirect addressing register R#17 setting autoincrement
         clrd            ; 02 (15)   ; DX = $0000
         stb   3,x         ; 05 (20)   ; send DX low byte
         sta   3,x         ; 05 (25)   ; and high byte
         stb   3,x         ; 05 (30)    ; send DY low byte
         sta   3,x         ; 05 (35)   ; and high byte
         lda   #$01         ; 02 (37)   ; NX = $0100
         stb   3,x         ; 05 (42)   ; send NX low byte
         sta   3,x         ; 05 (47)   ; and high byte
         ldd   #$0040      ; 03 (50)   ; NY = $0040
         stb   3,x         ; 05 (55)   ; send NY low byte
         sta   3,x         ; 05 (60)   ; and high byte
         ldb   ,u+         ; 06 (66)   ; get first data byte
         stb   3,x         ; 05 (71)   ; send 1st data byte
         ldb   #$f0         ; 02 (73)   ; get command code
         sta   3,x         ; 05 (78)   ; send VRAM, right, down
         stb   3,x         ; 05 (83)   ; send command
         ldy   #8191      ; 04 (87)   ; number of bytes to send (one already sent)
         ldb   #44+$80      ; 02 (89)   ; get register 44

                           ; PREVIOUS = 89 cycles - instead of previous 165 + 29 + 4 = 198 cycles

NextVal   lda   ,u+         ; 06 (06)   ; get one byte
         sta   1,x         ; 05 (11)   ; send value
         stb   1,x         ; 05 (16)   ; to R#44
         leay   -1,y         ; 05 (21)   ; decrement counter
         bne   NextVal      ; 03 (24)   ; not yet done? loopback
         
                           ; 8.191 x 24 = 196.584 cycles - instead of previous 8.191 x 48 = 393.168 cycles
                           
                           ; TOTAL = 196.584 + 89 = 196.673 cycles - instead of previous  393.168 + 198 = 393.366 cycles
         
         rts                           ; return


Ahora a conseguir que el compilador genere los objetos en su nuevo formato para G4
saludos
pere

[pser1]

@jltursan
Me asalta una duda ...
En el motor para G3, a pesar de recibir los objetos con un solo atributo de color (del fichero AGD), acabé por imponer a cada uno de los cuatro
patrones que lo componen los colores asignados al tile/patrón al que se superponen, así se podían mostrar hasta 8 colores, creo que esto es lo
que hacen en el Spectrum.
¿Has mantenido este mismo sistema para el modo G4?
No veo como determinar de antemano, de forma fácil, los colores que va a tener cada pieza y los necesito para subir a la VRAM cada objeto
con sus datos ya calculados o sea con colores fijos. En caso contrario deberían quedarse en RAM como las fuentes/signos y ya he visto que tu los tienes en la segunda página en la VRAM
Me parece una pringada tener que utilizar los bytes
36 - initial Room
37 - initial posVert
38 - initial posHoriz
de la estructura del Objeto para ver que tile hay en cada posición (N, N+1, N+32, N+33) para poder aplicar sus colores a cada elemento antes
de subirlo o directamente en el compilador, si es posible, claro!
saludos
pere

[jltursan]

Como en la anterior conversión a MSX1, yo empleo el modo nativo de MSX2 de forma pura (mira las capturas), eso implica tener que reconvertir todo un juego a G4. Si se me ocurriese la peregrina idea de sacar un motor G4 heredando las restricciones de un ZX...¡iba a tener que abandonar este país!
Efectivamente, si quieres mantener el sistema de atributos del Spectrum en G4 la cosa se complica. Tendrías que buscar la forma se separar lo que es el patrón de los atributos, lo que prácticamente descarta el empleo de la VRAM.
En mi caso, hagp algo parecido con la fuente. La tengo en RAM y la transfiero a la VRAM operando antes con los datos para "colorearlos" según tinta y papel, vamos, lo que necesitaría hacer tú, aplicar un atributo de color sobre un patrón neutro. Como ya hemos visto HMMC no tiene ni de lejos la velocidad de HMMM; pero menos da una piedra.
Otra alternativa sería no complicarse tanto la vida y cuando el compilador genera el código, construir la imagen del objeto con los colores definidos, olvidándote por completo de respetar los "atributos" de color que en ese momento tenga la celda.
Otra que se me ocurre, si tan importantes son los atributos de color simulados en pantalla, ¿por qué no guardar un mapa con dichos atributos?, consumes una porción de RAM tan grande como una screen; pero aceleras bastante otros cálculos.

Oye, y volviendo a G3, ¿no te quedan bastantes sprites libres?, supongo que empleas los 11 máximos del AGD. Si es así, ¿por qué no apañar las partículas con sprites?. No serían 50 y pico; pero con 20 para muchos juegos ya bastaría.

[pser1]

Como en la anterior conversión a MSX1, yo empleo el modo nativo de MSX2 de forma pura (mira las capturas), eso implica tener que reconvertir todo un juego a G4. Si se me ocurriese la peregrina idea de sacar un motor G4 heredando las restricciones de un ZX...¡iba a tener que abandonar este país!
Efectivamente, si quieres mantener el sistema de atributos del Spectrum en G4 la cosa se complica. Tendrías que buscar la forma se separar lo que es el patrón de los atributos, lo que prácticamente descarta el empleo de la VRAM.
En mi caso, hagp algo parecido con la fuente. La tengo en RAM y la transfiero a la VRAM operando antes con los datos para "colorearlos" según tinta y papel, vamos, lo que necesitaría hacer tú, aplicar un atributo de color sobre un patrón neutro. Como ya hemos visto HMMC no tiene ni de lejos la velocidad de HMMM; pero menos da una piedra.
Otra alternativa sería no complicarse tanto la vida y cuando el compilador genera el código, construir la imagen del objeto con los colores definidos, olvidándote por completo de respetar los "atributos" de color que en ese momento tenga la celda.
Otra que se me ocurre, si tan importantes son los atributos de color simulados en pantalla, ¿por qué no guardar un mapa con dichos atributos?, consumes una porción de RAM tan grande como una screen; pero aceleras bastante otros cálculos.
Oye, y volviendo a G3, ¿no te quedan bastantes sprites libres?, supongo que empleas los 11 máximos del AGD. Si es así, ¿por qué no apañar las partículas con sprites?. No serían 50 y pico; pero con 20 para muchos juegos ya bastaría.

La idea es poder portar juegos AGD tal como nos llegan de Spectrum u otras máquinas utilizando el fichero básico AGD
Los patrones/tiles, en G4 ya no tienen atributo de color puesto que cada uno de sus 32 bytes puede llevar los colores que se desee y por tanto no
hay tabla. Miraré bien en el compilador, tal vez se pueda extraer la información de colores aunque me temo que al comprimir las pantallas,
se pierde la posibilidad de encontrar una tile por coordenadas. Si se puede en tiempo real ...
Veremos como lo hago, sin descartar la edición de los objetos, por supuesto
Por cierto, en mi programa de test HMMC requiere solo 1,33 veces el número de ciclos del otro método, no está nada mal!
He estado viendo que para G3, yo me guardo en la estructura de los objetos las tiles que 'sustituye' capa elemento de forma que acudiendo a
la tabla bCol de los patrones/tiles puedo recuperar los colores y aplicarlos a objetos definidos en blanco y negro, pero para hacer esto debería guardarlos como ahora en la RAM, es decir mantener el mismo tratamiento, como con los sprites, es una posibilidad a tener en cuenta, no hacer nada!
Muchísimas gracias por el montón de ideas aportadas!
saludos
pere

[jltursan]

Los patrones/tiles, en G4 ya no tienen atributo de color puesto que cada uno de sus 32 bytes puede llevar los colores que se desee y por tanto no
hay tabla

En realidad me refiero a que estás manejando un modo bitmap (G4) de manera que buscas "simular" que existe una capa de atributos.

Miraré bien en el compilador, tal vez se pueda extraer la información de colores aunque me temo que al comprimir las pantallas,
se pierde la posibilidad de encontrar una tile por coordenadas. Si se puede en tiempo real ...

En mi caso mantengo un buffer con todas las tiles del mapa así que lo tendría fácil; pero es verdad que si se manejan las pantallas comprimidas no es práctico tratar de buscar información en ellas .

[pser1]

Miraré bien en el compilador, tal vez se pueda extraer la información de colores aunque me temo que al comprimir las pantallas,
se pierde la posibilidad de encontrar una tile por coordenadas. Si se puede en tiempo real ...
En mi caso mantengo un buffer con todas las tiles del mapa así que lo tendría fácil; pero es verdad que si se manejan las pantallas comprimidas no es práctico tratar de buscar información en ellas .

El buffer con las tiles de la pantalla actual lo necesito en G3 y en G4 para 'redibujar' la pantalla después de mostrar el inventario por ejemplo.
La tabla bCol con los colores de los tiles también la puedo crear en el compilador, aunque no se use ni se envíe al .ASM
Por cierto, ¿Tu compilador genera pantallas 'enteras' o comprimidas en el fichero .ASM?
Como en el PC y para el compilador en C no debería haber problemas de espacio, estoy pensando en crear una tabla de 768 bytes para cada
pantalla guardando los tiles cuando se leen los DEFINESCREEN con un malloc a lo grande y dejarlo ahí para cuando se procesen los DEFINEOBJECT
tal vez así podría ir del objeto a la pantalla, de ahi sacar el patrón y luego buscar en bCol los colores necesarios. Como se hace en C no tardará
mucho en hacer el trabajo ... Ya veré como lo hago!
saludos
pere

[jltursan]

Será más bien un malloc a lo pequeño . Esas cantidades de memoria en un PC son ínfimas, puedes guardar las pantallas que quieras y como quieras

Mi compilador actualmente genera la pantallas comprimidas, igual que antes; la única diferencia es que ya no empleo compresión RLE sino LZ.

[pser1]

Será más bien un malloc a lo pequeño . Esas cantidades de memoria en un PC son ínfimas, puedes guardar las pantallas que quieras y como quieras
Mi compilador actualmente genera la pantallas comprimidas, igual que antes; la única diferencia es que ya no empleo compresión RLE sino LZ.

Creo que el pequeño malloc ya me permite guardar todas las pantallas. Además me guardo en una tabla los colores de las tiles/patrones.
Una vez superados ciertos enojosos problemas motivados por un puntero a la tabla de objetos, que al haber sido creada demasiado pequeña
hacia que el puntero fuera mas lejos del espacio reservado por el malloc, pero la única pista era que cascaba en tiempo de ejecución el
compilador y el fichero ASM de salida quedaba cortado ...
Lo que me sale en pantalla al utilizar la tabla de objetos guardada es horroroso, la mayoría en negro!
Voy a trabajar con un único objeto y trataré de seguir todos los cálculos que hace para detectar donde está el problema.
Además otro problema molesto es que ciertos objetos NO tienen pantalla por defecto, sinó que estan deshabilitados con valor = 254
De momento en estos casos utilizaré el valor de color que viene por defecto en la estructura de datos del objeto para las cuatro
partes que lo forman.
Cuando esta parte esté funcionando tal vez podríamos hablar de la compresión LZ. ¿Se gana mucho espacio al emplearla?
¿Has notado el posible aumento de tiempo al descomprimir?
saludos
pere

[pser1]

Buenas tardes,
ha costado, pero valía la pena ...
El compilador en C de ficheros AGD ya genera datos para los patrones (32 bytes) y para los objetos (128 bytes)
De momento los saca en el fichero .ASM de forma que puedo copiarlos y meterlos en el programa que los sube a la VRAM
y así he ido haciendo retoques ...
Dos pequeños inconvenientes del método de buscar las celdas donde irá el objeto para heredar los colores de las cuatro
es que hay objetos (2 en Foggy) que llevan la pantalla destino a 254 (objeto deshabilitado) por lo que no hay forma, en
este caso he utilizado el color que vienen en el fichero AGD, por defecto blanco sobre negro
Como esto pasa para el "crystal red" que tiene dos colores en la parte superior y blanco/negro en la inferior, he decidido
que el fichero AGD llevará cuatro bytes para colores, para los cuatro patrones (o cuatro cuadrantes) del objeto, así puedo
definirlo como quiera sin necesitar un editor gráfico ...
Otra cosa es que el "Pick Axe" cuando está en pantalla se muestra negro sobre negro, o sea invisible. He visto que la versión
MSX se ve en color en el pantallazo que adjuntaste (jltursan), así que he modificado el compilador para que cuando un objeto
resulte con colores negro sobre negro se cambie a azul oscuro sobre negro ... no se si esto perjudicará la idea del juego (?)
Ahora ya puedo dedicarme a definir los dos ficheros de salida, para patrones y objetos y hacer que el compilador los llene
en lugar de enviar los datos al fichero .ASM
Pasito a pasito, parece que el salto al modo G4 está mas cerca para los CoCo-Dragón con la MSX2+ de John
saludos
pere

ObjectsG4.jpg (95.77 KiB) Visto 127 veces

[jltursan]

¡Buenas noticias y notable el progreso!

Cuando esta parte esté funcionando tal vez podríamos hablar de la compresión LZ. ¿Se gana mucho espacio al emplearla?
¿Has notado el posible aumento de tiempo al descomprimir?

Aprox. una media del 40% en el espacio ocupado por el mapa. Se nota el tiempo; pero la verdad es que en la práctica no resulta molesto. Recuerdo que en el AEON2 si que parecía algo noticiable. La principal "desventaja" es que necesita un buffer para descomprimir previamente la pantalla al completo (buffer que por otra parte te puede venir bien). Estuve probando otro mecanismo de compresión que permitía el streaming de los bytes; pero no está bien documentado y había que adaptarlo, no tuve éxito y lo aparqué.
Mi plan es que con eso y un soporte apropiado para los metablocks, el tema de los mapas recupere bastante espacio malgastado.

Otra cosa es que el "Pick Axe" cuando está en pantalla se muestra negro sobre negro, o sea invisible. He visto que la versión
MSX se ve en color en el pantallazo que adjuntaste (jltursan), así que he modificado el compilador para que cuando un objeto
resulte con colores negro sobre negro se cambie a azul oscuro sobre negro

es cierto. La verdad es que lo diseñé sin saber que posición ocupaba (ya sabes que para mí eso es irrelevante dado que doto a los objetos de su propio color) y cuando ví que lo habían hecho invisible, me pareció que era pasarse un pelín así que lo dejé como estaba. Lo podría haber dejado en negro o emplear tu solución, que me parece la mejor, el objeto se ve; pero oscurecido.

Si quieres estudiar lo de la compresión tendré que pasarte también la fuente del compilador, ya te explicaría un poco como lo he montado. A ver si te las empaqueto y te las paso.