motor AGD para V9958 modo gráfico G4 para HD6309

[pser1]

@jltursan
Adjunto unas preguntas que pueden ayudarme a decidir como plantearme el uso de datos. Mejor antes de programar nada
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 - Cuando quitas un objeto de pantalla, ¿Redibujas las 768 celdas o solo las 4 afectadas?
en realidad el código de patrón no ha cambiado en la tabla de estas celdas sobre-escritas.
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 - Como el panel (marco alrededor de la ventana de juego) se dibuja directamente,
¿Guardas un valor ficticio en estas celdas para evitar re-dibujarlas?
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3 - ¿Como te las apañas para los juegos que tienen un marco fijo que se cargaba desde disco
en los juegos AGD para CoCo-Dragón para el MC6847 en B/N?
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4 - Para los sprites, ¿Al final te pasas los 16 bytes de color en el fichero AGD o en la salida del compilador?
Me refiero en sprGfx tras cada frame, ahora 32 bytes, luego serían 32+16 = 48 por frame
Creo que habías comentado algo sobre tener dos funciones SpriteInk, una con un solor color y otra
que permitiera 16 colores, uno por fila
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
saludos
pere

[pser1]

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 - Cuando quitas un objeto de pantalla, ¿Redibujas las 768 celdas o solo las 4 afectadas?
en realidad el código de patrón no ha cambiado en la tabla de estas celdas sobre-escritas.
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mirando tu rutina robj: parece claro que pintas de nuevo los cuatro patrones que habían sido sobre escritos al poner el objeto
Iré mirando los otros temas ...
saludos
pere

[jltursan]

1 - Es exactamente lo que dices que has visto, redibujo sólo los cuatro bloques afectados.
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 - El marco alrededor no forma parte del mapa y por tanto no se ve afectado por los redibujados de la pantalla. Se imprime una vez y ahí se queda.
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3 - Los marcos que se precargaban como gráfico se precargarán igual en esta versión (como en la de MSX1), el cargador de BASIC lo hará y en el arranque del juego se omitirá la inicialización del modo gráfico para evitar borrarlos.
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4 - El AGD ha cambiado por completo adaptándose a los nuevos formatos. El sprite tiene lo que dices, 48 bytes. El spriteink de momento sólo es compatible con el funcionamiento clásico de 1 color. Eso significa que repinto el sprite a 1 color, perdiendo su mapa de color.

[pser1]

1 - Es exactamente lo que dices que has visto, redibujo sólo los cuatro bloques afectados.
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 - El marco alrededor no forma parte del mapa y por tanto no se ve afectado por los redibujados de la pantalla. Se imprime una vez y ahí se queda.
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3 - Los marcos que se precargaban como gráfico se precargarán igual en esta versión (como en la de MSX1), el cargador de BASIC lo hará y en el arranque del juego se omitirá la inicialización del modo gráfico para evitar borrarlos.
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4 - El AGD ha cambiado por completo adaptándose a los nuevos formatos. El sprite tiene lo que dices, 48 bytes. El spriteink de momento sólo es compatible con el funcionamiento clásico de 1 color. Eso significa que repinto el sprite a 1 color, perdiendo su mapa de color.

2 - Para el modo G3 yo tenía en RAM una tabla de 768 bytes que contenía todos los bloques usados para crear el marco. Tendré que mirar que
hacía cuando el marco era imagen cargada de disco
Por esto decía yo de poner un código en las celdas no empleadas en el juego (todas al empezar) que luego sea considerado como patrón a no ser
mostrado/enviado en pantalla/VRAM
3 - Supongo que usando un ClearWindow en lugar de un Cls se evitaría problemas
4 - Pues así lo haré, añadiré 16 bytes idénticos (de momento) al final de cada 'frame' y mas adelante ya veré como añadir una función al
compilador que me permita enviarle 16 colores. En realidad como solo puede tener valores de 0 a 15 se podrían enviar 8 bytes
(un color en cada nibble) aunque haría un poco mas liado el proceso de carga de bytes a la tabla de colores de los sprites
saludos
pere

[jltursan]

3 - Supongo que usando un ClearWindow en lugar de un Cls se evitaría problemas

Exacto, si no me equivoco al AGD le paso lo mismo. Cuando has cargado una imagen demarco, si haces un CLS te la cargas, tienes que usar un CLW. que sólo borra el área definida en DEFINEWINDOW y que es justo el SCREEN.
Lo que mencionas de emplear una marca para celdas "dirty" lo empleo; pero sólo para el SCREEN. De hecho como dibujo las pantallas basándome en el delta entre una y otra, en muchas ocasiones me ahorro redibujar más de la mitad de las celdas, lo que en MSX2 viene de perlas.

[pser1]

Lo que mencionas de emplear una marca para celdas "dirty" lo empleo; pero sólo para el SCREEN. De hecho como dibujo las pantallas basándome en el delta entre una y otra, en muchas ocasiones me ahorro redibujar más de la mitad de las celdas, lo que en MSX2 viene de perlas.

Entiendo que cuando hablas de 'delta', estas comparando el patrón en pantalla con el patrón de la nueva pantalla para decidir si lo pintas o no.
Puede representar un buen ahorro, como tu indicas, me parece una idea excelente
Voy a tener que implementarla también en mi motor para HD6309
muchas gracias
pere

[pser1]

Estaba pensando que las fuentes de caracteres se podrían convertir a formato G4 en blanco y negro y guardarlos en la VRAM a partir de $10000.
Son 96 x 32 = 3072 bytes ($c00). Podría hacerlo el compilador también creando otro fichero mas
Usando el valor $f para color blanco (tinta) y $0 para negro (papel), luego se podrían aplicar los colores de la variable vdpCol
que se informa en el fichero AGD para colorear textos. Contiene 16*FG+BG. Primero habría que leer el fuente a RAM para procesarlo antes de enviarlo a pantalla. Probablemente sea un trabajo excesivo para 'ahorrar' solamente 96x8=768 bytes del binario actual.
Supongamos los cuatro posibles patrones 00000000 00001111 11110000 11111111 (cuatro posibilidades que ofrecen 2 píxeles a dos colores)
Si queremos aplicar PAPEL '0010' y TINTA '0110', podríamos hacer
- PAPEL2 = 00100010, o sea ambos nibbles/pixeles iguales
- TINTA2 = 01100110, lo mismo
PatronFondo = (PATRON | PAPEL2) & /PATRON; siendo /PATRON el complemento a Unos de PATRON
PatronTinta = PATRON & TINTA2
Resultado -> PatronFondo + PatronTinta

Comprobemos los cuatro casos
PATRON ................ 00000000 00001111 11110000 11111111
/PATRON ............... 11111111 11110000 00001111 00000000
PATRON | PAPEL2 ..... 00100010 00101111 11110010 11111111

previo & /PATRON .... 00100010 00100000 00000010 00000000 -> PATRON con NUEVO PAPEL
PATRON & TINTA2 ..... 00000000 00000110 01100000 01100110 -> PATRON con NUEVA TINTA
Sumados dan .......... 00100010 00100110 01100010 01100110
que son cada uno ..... BG BG ... BG FG ... FG BG ... FG FG, que es lo que queríamos obtener

Reconozco que parece enrevesado, pero se puede hacer con unas pocas operaciones lógicas

Código: Seleccionar todo

   ldb   PATRON      ; lee un byte del patrón
   comb            ; calcula complemento a 1 y se guarda en regB
   lda   PATRON      ; lee otra vez el mismo byte
   ora   FONDO2      ; añade fondo a los 2 nibbles (pixels)
   andr   a,b         ; pasa a cero los nibbles de tinta, guarda resultado en regB
   lda   PATRON      ; lee de nuevo mismo byte
   anda   TINTA2      ; aplica tinta a los dos nibbles (fondo se autocancela)
   orr   b,a         ; añade fondo antes calculado
   sta   PANTALLA   ; resultado = byte en colores


En fin es pura elucubración, seguramente me decantaré por la opción de mantener la tabla de fuentes en RAM
y aplicar colorido cada dos pixeles como haces tu ...
saludos
pere

[pser1]

Mas elucubracions ...
De hecho estoy utilizando este hilo como borrador donde voy anotando ideas, así podréis añadir cualquier comentario que deseéis
Con la alternativa de mantener las fuentes en RAM, una vez separados INK y PAPER de vdpCol, crearemos una tabla de cuatro elementos así
BGBG, BGFG, FGBG, FGFG siguiendo el ejemplo anterior: 00100010 00100110 01100010 01100110 índices (0-1-2-3)
El código ahora podría ser

Código: Seleccionar todo

      ldu   #TabCol      ; puntero a la tabla de 4 combinaciones antes descrita
      ldy   #Result      ; tabla resultados (4 bytes) o directo al VDP
      lde   #4         ; 4 bytes por linea (font byte)
      ldb   PATRON      ; lee un byte del patron
Loop1   clra         ; indice a cero
      lsld            ; envia 2 bits de la izquierda de regB
      lsld            ; a regA
      lda   a,u      ; recupera valor de este indice de la tabla TabCol
      sta   ,y+      ; guardar byte, mover puntero (podría ser parte de un comando HMMC) (sta  ,x)
      dece            ; decrementa contador
      bne   Loop1      ; no acabado? bucle atras para el siguiente
      rts            ; retorna   


Por supuesto la tabla de cuatro elementos de color TabCol se podrá emplear para todos los bytes del carácter actual y para los que vengan
mientras vdpCol no cambie. La rutina es bastante corta y genera los cuatro bytes a partir del byte de la fuente y los colores de vdpCol
saludos
pere

[jltursan]

Pues cualquier variante que se pueda encontrar a la hora de imprimir las fuentes, bienvenida sea. Le echaré un vistazo a lo que cuentas

Entiendo que cuando hablas de 'delta', estas comparando el patrón en pantalla con el patrón de la nueva pantalla para decidir si lo pintas o no.

Exacto, es eso. Pero ojo, que tiene su miga ya que hay que considerar que un objeto machaca los bloques y por tanto eso significa que al cambiar de pantalla, no se puede obviar el repintado de esas celdas que ocupaba el objeto. Para "marcar" como sucia el área ocupada por los objetos empleo el block 255. Y ya lo se, con eso estoy fastidiando el empleo del último código de bloque (255); pero ya sería casualidad que se llegaran a emplear los 256 disponibles y que me pusieran un objeto encima de bloques 255

De momento no le he dado muchas más vueltas ya que precisamente el HMMC, al ser lentillo, el que haya un poco de código de CPU entre byte y byte enviado me viene bien, ya que así me ahorro esperar por TR exprofeso.

[pser1]

Exacto, es eso. Pero ojo, que tiene su miga ya que hay que considerar que un objeto machaca los bloques y por tanto eso significa que al cambiar de pantalla, no se puede obviar el repintado de esas celdas que ocupaba el objeto. Para "marcar" como sucia el área ocupada por los objetos empleo el block 255. Y ya lo se, con eso estoy fastidiando el empleo del último código de bloque (255); pero ya sería casualidad que se llegaran a emplear los 256 disponibles y que me pusieran un objeto encima de bloques 255

Veamos, ocasiones en las que es necesario pintar una pantalla entera:
- al cambiar de pantalla
- después de mostrar el menú de inventario tras seleccionar algun objeto (o no)
No se me ocurre ningún otro motivo para hacerlo, pero igual hay otras ocasiones que ahora no veo
En ambos casos habrá que pintar los objetos después de los patrones, así que no veo necesidad de poner el 255 aposta.
Yo no me guardo los patrones sobrescritos por un objeto y cuando este 'desaparece' leo en la tabla de layout en RAM los cuatro códigos
que ocupaban estas posiciones y los redibujo.
saludos
pere

Pd Yo quería utilizar el 255 como indicador de celda a no repintar para así evitar sobrescribir la parte del panel cargado de fichero o bien
dibujado en la presentación como es el caso de Foggy's Quest

[jltursan]

Empleamos mecanismos ligeramente diferentes. Por ejemplo, yo sólo pinto la pantalla entera:

1) Al comenzar el juego
2) Al hacer un CLS/CLW/REDRAW

En todos los demás casos, sólo pinto lo que hace falta. Lo que te decía de como empleo el código 255 para marcar como sucias las posiciones ocupadas por un objeto, también se aplica a los textos, por ejemplo, si se me ocurre imprimir un mensaje en plena SCREEN justo antes de cambiar de nivel.

[pser1]

Empleamos mecanismos ligeramente diferentes. Por ejemplo, yo sólo pinto la pantalla entera:
1) Al comenzar el juego
2) Al hacer un CLS/CLW/REDRAW

Yo hago lo mismo, solo que al pasar de una pantalla a la siguiente también estoy pintándola completa.
Pero ya haré lo mimso, ver si los bloques cambian o no se pintan ...

En todos los demás casos, sólo pinto lo que hace falta. Lo que te decía de como empleo el código 255 para marcar como sucias las posiciones ocupadas por un objeto, también se aplica a los textos, por ejemplo, si se me ocurre imprimir un mensaje en plena SCREEN justo antes de cambiar de nivel.

Yo solamente tengo una copia en RAM de los bloques que hay en cada celda de pantalla (32x24=768). Por lo tanto, si al pintar un Objeto
le pongo un 255 a las cuatro celdas sobrescritas, ya no sé que patrones había allí para volverlos a pintar si el objeto desaparece.
En la versión G3 cada objeto se formaba creando cuatro bloques nuevos, con nuevos números y se ponían en la tabla en RAM, perdiendo esta
información, por lo que me los guardaba en el objeto para uso posterior, si era necesario. Pero ahora al no ser sobrescritos, he eliminado
los cuatro bytes de la estructura de objetos, así que poner un 255 en su lugar me implica no saber que bloques reponer luego ...
Y ya no te cuento al presentar el diálogo de inventario que puede ser enorme, por ello la rutina de Inventario/Menú siempre acaba con un Redraw
que pinta la pantalla y luego los objetos si hay alguno.
¿Como sabes tu en tu motor que bloques había antes de poner un 255 en su lugar?
saludos
pere

[jltursan]

Nah, no me hagas caso, hace demasiado tiempo de eso...

Los códigos 255 los empleo sólo para textos. Los objetos no alteran el mapa de códigos, me guardo las coordenadas en las que se ubica cada objeto (soporto hasta un max. de 128 por facilitar las cosas) y cuando los elimino, recojo los códigos de bloques originales a partir de esas coordenadas guardadas y los restauro.

El problema que originalmente tuve, ahora me acuerdo, era que como los objetos no alteran el mapa, los bloques parecía que no habían cambiado y si en la pantalla siguiente se mantenían los mismos, al no redibujarse, fragmentos del objeto podían permanecer tras cambiar pantalla.

[pser1]

Nah, no me hagas caso, hace demasiado tiempo de eso...
Los códigos 255 los empleo sólo para textos. Los objetos no alteran el mapa de códigos, me guardo las coordenadas en las que se ubica cada objeto (soporto hasta un max. de 128 por facilitar las cosas) y cuando los elimino, recojo los códigos de bloques originales a partir de esas coordenadas guardadas y los restauro.

Yo también tengo las coordenadas (arriba izquierda) y con esto restauro los cuatro bloques leyendo la tabla de 768 en RAM

El problema que originalmente tuve, ahora me acuerdo, era que como los objetos no alteran el mapa, los bloques parecía que no habían cambiado y si en la pantalla siguiente se mantenían los mismos, al no redibujarse, fragmentos del objeto podían permanecer tras cambiar pantalla.

Efectivamente, si los 'tapa' un objeto, y el mismo bloque existe en la siguiente pantalla en la misma celda, no se repintaría. Ya sería mala suerte, pero como hay muchos bloques neutros (negro) puede pasar. Como el re dibujado de pantalla es rápido y cambiando de una a otra no requiere mas, creo que mantendré el sistema actual de repintar lo que no sean códigos 255.
saludos
pere

[pser1]

buenas tardes,
me he estado peleando para tener una subrutina que calcule los cuatro elementos de la tabla
de combinaciones de dos colores partiendo de los colores recibidos para el carácter a mostrar
Recibimos 16*FG+BG en la variable vdpCol
Copio el código que he acabado de dar por bueno, que me sigue pareciendo muy laborioso.
Si alguien tiene cualquier idea para mejorar el proceso, se agradecerá un montón
Esta rutina (FillTab) solo hará falta llamarla al principio de Dmsg

saludos y buen fin de semana

Código: Seleccionar todo

TabCol   fcb   $00,$00,$00,$00      ; BGBG, BGFG, FGBG, FGFG
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FillTab   ldb   <vdpCol      ; tomar colores solicitados (FGBG)
         cmpb   <lastVdpCol   ; son igual a los últimos usados?
         beq   FillBuff      ; si, salta seccion e ir a llenar el buffer
         stb   <lastVdpCol   ; guardar como últimos colores usados
         stb   TabCol+2      ; guardar como indice 2 en tabla
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
         clra               ; regD=0000 FGBG
         lsld               ; mover el nibble alto
         lsld               ; de regB
         lsld               ; al nibble bajo de regA
         lsld               ; regD=00FG BG00
         addr   b,a         ; regA=BGFG
         sta   TabCol+1      ; guardar como indice 1 en tabla
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
         ldb   <vdpCol      ; regD=BGFG FGBG
         andd   #$0ff0      ; regD=00FG FG00
         addr   b,a         ; regA=FGFG
         sta   TabCol+3      ; guardar como indice 3 en tabla
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
         ldd   TabCol+1      ; regD=BGFG FGBG
         andd   #$f00f      ; regD=BG00 00BG
         addr   b,a         ; regA=BGBG
         sta   TabCol+0      ; guardar como indice 0 en tabla

[pser1]

y para rematar la jugada, una rutina que partiendo de los ocho bytes de un carácter nos creará los 32 necesarios en modo G4
para enviarlos a pantalla mediante un comando HMMC
Cualquier comentario será bien recibido!
saludos
pere

Código: Seleccionar todo

; asumiendo que regX apunta al principio de datos del carácter a enviar a pantalla
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FillBuff   ldu   #TabCol      ; puntero a la tabla de 4 combinaciones antes descrita
         ldy   #Result      ; tabla resultados (32 bytes)
         ldf   #8            ; bytes del carácter
Loop1      lde   #4            ; 4 bytes por línea (font byte)
         ldb   ,x+         ; lee un byte del patrón y apunta al siguiente
Loop2      clra               ; índice a cero
         lsld               ; envia 2 bits de la izquierda de regB
         lsld               ; a regA
         lda   a,u         ; recupera valor de este índice de la tabla TabCol
         sta   ,y+         ; guarda byte en buffer, avanza puntero
         dece               ; decrementa contador de pares de pixels
         bne   Loop2         ; no acabado? bucle atrás para el siguiente par de pixels
         decf               ; decrementa contador de bytes
         bne   Loop1         ; no acabado? bucle atrás para el siguiente byte
         rts               ; retorna   
Result   rzb   32            ; espacio para los 4x8 bytes del carácter en modo G4
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; Una vez llenados los 32 bytes se puede llamar al comando HMMC