Aprendiendo a manejar los chips de video V9958 y sonido YM-2149

jltursan
Mensajes: 2937
Registrado: 20 Sep 2011 13:59
Agradecido : 240 veces
Agradecimiento recibido: 707 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 03 May 2020 16:58

Último mensaje de la página anterior:

Ah, ¡curioso!. Mi motor entonces es más parecido al original del ZX o quizás has empleado una fuente AGD del Foggy distinta a la mía :-)
Si pruebas la versión ZX pasa lo que dices, aun no teniendo nada recogido, si vas delante de la puerta azul y pulsas "I", se abre la puerta.

El formato de los gráficos para el MSX (ojo TMS9918, no V9958, aunque en este caso no resulte relevante) es diferente y pensado en que sea lo más óptimo posible a la hora de volcar a VRAM. Cauldwell adaptó el WinAGD y ya genera los gráficos con mi formato cuando se selecciona MSX. Así pues, el compilador realmente no reordena nada, se limita a dejarlos en el ASM tal como le llegan en el AGD.

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 03 May 2020 18:50

jltursan escribió:Ah, ¡curioso!. Mi motor entonces es más parecido al original del ZX o quizás has empleado una fuente AGD del Foggy distinta a la mía :-)
Pues igual al convertirlo y hacer pruebas me aseguré de que solo se saliera del menú si había seleccionado algún elemento, en fin da igual, ahí se queda ...
El formato de los gráficos para el MSX (ojo TMS9918, no V9958, aunque en este caso no resulte relevante) es diferente y pensado en que sea lo más óptimo posible a la hora de volcar a VRAM. Cauldwell adaptó el WinAGD y ya genera los gráficos con mi formato cuando se selecciona MSX. Así pues, el compilador realmente no reordena nada, se limita a dejarlos en el ASM tal como le llegan en el AGD.
Veamos, yo utilizo un fichero AGD que ya contiene la información volcada con el convertidor a partir del .sna de Spectrum
Como los bytes vienen ordenados por filas, uno de cada columna, mi programa los leía en dos pasadas saltando cada vez uno.
Ahora he reordenado las tablas de objetos y sprites y puedo leerlas secuencialmente sin problemas.
Como no voy a basarme en el WinAGD para la conversión de juegos antiguos, tendré que modificar las rutinas que generan objetos y sprites en el
compilador en C, pero no me parece complicado. En la conversión anterior me harté de hacerle cambios para generar mejor código 6809
Ahora estoy haciendo revisiones de código para 'limpiar' y organizar mejor las funciones/rutinas, un pequeño descanso vamos -507
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 05 May 2020 11:15

Veamos, mi colega John Whitworth del grupo de facebook de Dragón está trabajando en la creación de una placa
llamémosle Grafpak3 que contendrá el chip de sonido YM2149 (totalmente compatible con AY-3-8910) y el ya consabido
V9958 con sus 128k VRAM
Me pregunta que ventajas ofrecería la inclusión de las otras 64k VRAM (extendidas)
¿Pueden usarse para guardar datos y luego copiarlos mas rápidamente a la VRAM de video?
Agradeceré cualquier información sobre aplicaciones prácticas que se le puede dar a esta memoria adicional -thumbup -nb
muchas gracias de antemano
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 05 May 2020 17:12

Hablando del tema de retardos que deberían ponerse entre dos accesos consecutivos al V9958...
Leyendo el documento (en portugués-brasileño): "MSX II Top Secret" de EDISON ANTONIO PIRES DE MORAES,
encuentro este texto:
Eles devem ser acessados por via direta; por isso, deve ser tomado um certo cuidado com a
sincronização, aguardando que o VDP esteja pronto. Deve haver uma pausa de 8 us (microseg) entre acessos consecutivos

Me parece desorbitado -shock
El 6809/6309 a velocidad std van a 0,89MHz por lo que 1 ciclo = 1,124 microseg
Si van a doble velocidad, 1,78MHz entonces se reduce a la mitad, 1 ciclo = 0,562 microseg
Voy a poner dos ejemplos de uso. El primero con un bucle que lee de RAM y va enviado bytes al V9958 via port apuntado por el registro X

Código: Seleccionar todo

L1    lda   ,u+      6 ciclos
      sta   ,x        no importa
      decb            2/1 ciclos (normal o modo nativo)
      bne   L1       3 ciclos

El tiempo entre dos envíos (sta ,x) es de 10 ciclos, modo nativo a 1,78MHZ => 5,62 microseg
O sea que debería añadir retardos por valor de 2,4 microseg para completar los 8 microseg descritos
Esto implicaría añadir 5 NOPs (cada uno un ciclo) o mejor una operación inocua como EXG x,x que usaría los mismos 5 ciclos
Otro caso bastante frecuente:

Código: Seleccionar todo

      sta  ,x
      stb  ,x

En este caso debería añadir los 8 microseg o sea 16 NOPs o buscar combinaciones que no hagan nada pero consuman ciclos ...
Me parece una exageración ya que en el segundo caso, a veces solo tengo un NOP ... o ninguno
En el primer caso ya no digo nada ...
¿Existe alguna información mas fiable que este tiempo indicado en este documento brasileño?
muchas gracias
pere

jltursan
Mensajes: 2937
Registrado: 20 Sep 2011 13:59
Agradecido : 240 veces
Agradecimiento recibido: 707 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 05 May 2020 19:15

Pues a ver...

Me pregunta que ventajas ofrecería la inclusión de las otras 64k VRAM (extendidas)
¿Pueden usarse para guardar datos y luego copiarlos mas rápidamente a la VRAM de video?


Sin extenderme mucho, no, el banco extendido de memoria no aporta nada especial a los modos de video que ya funcionan con 128KB. La única ventaja es la que mencionas, es una memoria fácil de controlar gracias al CAS extendido del V9958 y que no deja de ser útil para almacenar datos (que siempre van a transferirse más rápido desde la VRAM que cuando su origen es la RAM principal).

¿Existe alguna información mas fiable que este tiempo indicado en este documento brasileño?


El documento brasileño está algo anticuado y de hecho, esa cifra es aplicable sólo al TMS9918. Lo más reciente es esto: http://openmsx.org/vdp-vram-timing/vdp-timing.html, ojo con la lectura que es bastante espesa.

Podemos resumirlo con esto:

Too fast CPU access

The fastest way for the Z80 to send read or write VRAM request to the VDP is by using a sequence of
IN A,(#98) or OUT (#98),A instructions (of course such a sequence always writes the same value or
ignores all but the last read value). This takes 12 Z80 clock cycles per request. (Instructions like
OUT (C),r or OUTI are all slower). The VDP is clocked at 6× the Z80 speed. So when the Z80 sends
multiple requests to the VDP, the minimal distance between these requests, translated to VDP cycles,
is at least 72 VDP cycles. Earlier we saw that the maximal gap between access slots was 70 VDP cycles,
so at first sight there's no problem. However consider this scenario:

Suppose we're in 'sprites on' mode. At time=236, we're 16 cycles before an access slot. Suppose
there's no pending CPU nor command request at this time. So nothing will get executed at time=252.

- A bit later at time=240 there arrives a CPU write request. This request gets buffered.
- At time=252 there is an access slot, but nothing will get executed in this slot (because this slot
wasn't allocated at time=236).
- At time=300 we're again 16 cycles before an access slot. Now there is a pending CPU request,
so we'll execute that at time=316.
- At time=312 we receive a new CPU write request. This is 312-240=72 VDP cycles (or 12 Z80 cycles,
the duration of a OUT (#98),A instruction) after the previous request. But the buffer still contains
the previous unhandled request. The new request overwrites the old request!
- At time=316 there's an access slot and we've allocated this slot to the CPU (at time=300). So the
pending CPU request gets executed. Though this writes the data from the new request, the data
from the old request is never written!

Note that this scenario used a gap of only 64 VDP cycles between access slots, while there were 72 cycles
between the CPU requests. (And the largest gap between access slots is 70 cycles).


O lo que es lo mismo, podemos acabar haciendo un "overrun" del VDP si empleamos ráfagas de OUT ($98),A, es decir, una escritura cada 12T. Eso traducido a uS y con un reloj estandar del Z80 de 3,579545Mhz vienen a resultar unos 3,348uS. Si empleamos ráfagas de OUTIs, a 18T cada uno, sabemos por experiencia que es raro que haya problemas de "overrun", eso nos da un tiempo por instrucción de 5,022uS.
La conclusión es que el margen de seguridad se debería encontrar entre 3,5uS y 5uS (obviamente por encima funciona seguro).

Y una cosa que no pillo, ¿cuando indicas que sta ,x"no importa", a que te refieres?. Lo digo porque sus ciclos deben tenerse también en cuenta a la hora de calcular el coste de cada escritura a VRAM.

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 05 May 2020 22:13

entendido, me quedo con la cifra entre 3,5 y 5 microseg, muchas gracias -thumbup
Al decir no importa me equivoqué -banghead. El tiempo entre dos inicios de envío de byte al VDP deben tener en cuenta el coste
del envío en sí mismo también.
En este caso habría que sumar 4 ciclos mas dando un total de 14 ciclos (en lugar de 10), a 1,78MHz necesitarían 7,9 microseg
con lo cual el 'espaciado' es mas que holgado!
El caso de máxima rapidez utilizaría 1x4 ciclos=4 que a 1,78Mhz necesitan 2,25 microseg por lo que queda fuera y parece razonable añadir
dos NOPs (2 ciclos) para que 6x0,562=3,37 está en el rango bajo que has calculado tu. Realmente funciona bien con uno solo y en
algunos puntos sin ninguno -507
He podido comprobar que hay otros 'efectos' que requieren mayores esperas, posiblemente la explicación 'complicada'
de tu mensaje detalla una de ellas ... O sea que en ocasiones he tenido que añadir NOPs o se perdían bytes -507
Lo que no tengo claro es si la VRAM extra es utilizada por muchos programas ... En realidad también puedo copiar entre las diversas
páginas que acepte el modo elegido, por ejemplo en el Modo G3, que utiliza 16k, me permite tener hasta 8 páginas completas y la copia
de una sobre la otra no debería necesitar demasiado tiempo al mover solamente 16k (patrones y sprites a la vez)
En fin, se lo comentaré a John Whitworth y que decida el si quiere llenar la placa con otro chip aunque las SRAM actuales SMD son pequeñitas
Repito otra vez, muchas gracias por la información -drinks
Voy a empezar con el tema del 'modo aventura' grabando bloques encima de otros y guardando la información en una tabla para las siguientes
entradas en la pantalla afectada. Creo que así ya podré abrir la puerta, con truco, y pasar a otra área con bastantes pantallas mas para
seguir probando ...
El paso siguiente será implementar el inventario, ya veré como me va con los bloques creados sobre la marcha para texto y marco
y como recupero los códigos empleados en el inventario una vez se borra y se vuelve a la pantalla normal volviendo a poner los contadores
de las tres partes de pantalla a sus valores antes del inventario.
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 06 May 2020 09:51

Buenos días,
por fin pude hacerme un montaje para mantener el móvil quieto mientras yo puedo manejar a Foggy ...
Esta es la situación actual del motor AGD para Dragón V9958 con el Wordpak2+
saludos
pere
FoggysQuestv0.39.zip
(18.01 MiB) Descargado 7 veces

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 06 May 2020 19:58

Hola,
ya me funciona el modo 'aventura' que le permite al programa recordar los cambios que el jugador efectúa en cada pantalla,
por ejemplo abrir una puerta de forma que al regresar de nuevo a ella, el programa pueda reponer dicha situación.
Voy a revisar código para ver si se puede optimizar algo ya que me ha parecido encontrar cosas repetidas o muy parecidas ...
De nuevo el V9958 simplifica enormemente las tareas gráficas, vaya amigazo ;-)
saludos
pere

Próxima estación: Menú de Inventario ...

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 10 May 2020 20:30

Buenas tardes,
La parte de Inventario ha sido mas dura al tener que 'crear' patrones para cada letra y color para montar el menú de Inventario y al
cerrar la ventana, descartarlos volviendo a poner los contadores a los valores anteriores.
Ahora Foggy puede moverse, en teoría, por todas las pantallas ... voy a tener que revisar la solución para recordar el orden en el
que hay que hacer las cosas para llega al final.
He visto que, aunque los sprites que abren puertas son deshabilitados una vez abierta ésta, en cuanto volvemos de nuevo
a la misma pantalla, aparecen otra vez ya que están en la lista de sprites de dicha pantalla.
Esto quiere decir que, a pesar de que la puerta quedó abierta gracias al modo aventura, nadie impide al jugador volver a pulsar
la letra 'I' para abrir de nuevo el inventario y seleccionar la llave adecuada para abrir lo que ya está abierto.
El script AGD no controla esta posibilidad, se limita a dibujar de nuevo los cuatro bloques para 'eliminar' la puerta y como
la rutina de 'añadir' cambios en modo aventura tampoco controla nada, va añadiendo registros, pues la podemos liar si 'abrimos'
repetidamente la puerta hasta cansarnos. El peligro es que si grabamos mas bloques de los que permite la tabla, empezaremos a
sobreescribir otros datos, en mi caso la tabla de 'Shrapnel' para disparos/explosiones
No me gusta dejar este agujero abierto así que voy a ver si encuentro una solución simple que evite duplicados en la
tabla de bloques/aventura y además no imprima algo que ya está en pantalla aunque ésto último no rompe nada ya que
se utiliza un bloque concreto por lo que no es necesario crear un nuevo patrón cada vez ...
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 11 May 2020 00:57

Hola de nuevo,
he implementado una pre-rutina antes de escribir un nuevo bloque en la tabla de aventuras que verifica los registros ya grabados
y si encuentra uno para la pantalla actual, verifica si las coordenadas son las mismas, en cuyo caso sobreescribe el código del bloque ya
que le doy prioridad a la última información (la mas reciente). Si no cuadran las coordenadas mira la siguiente entrada de la tabla.
Si no encuentra nada que coincida, entonces pasa a grabar un nuevo registro.
Para probar, he añadido una rutina que sobreescribe en el campo de número de 'crystals' la cifra 7 en rojo y espera que se pulse Break
La primera vez que abro la puerta opera normal, pero a partir de entonces cualquier apertura de dicha puerta hace que aparezca un 7 en
número de 'crystals' y debo pulsar 'Break' cuatro veces ya que la puerta se abre dibujando cuatro bloques para eliminarla.
Así que parece que funciona el sistema -thumbup Creo que ahora está a prueba de niños 'malos' -507
Ahora necesito ver el walkthrough de nuevo y tratar de ir avanzando en el juego. Necesito ir viendo como funcionan las rutinas para
objetos que yo trato ahora como sprites, léase GetOBj, GotObj, DelObj, RemObj y alguna que me dejo, pero me gusta como va la conversión ;-)
saludos
pere

jltursan
Mensajes: 2937
Registrado: 20 Sep 2011 13:59
Agradecido : 240 veces
Agradecimiento recibido: 707 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 11 May 2020 17:33

Hemos intercambiado los problemas, este último control lo tuve que implementar con los objetos al estar formados por "pseudo-bloques", no por sprites :-)
En cualquier caso, las rutinas de objetos te van a quedar en este caso mucho más simples sin lugar a dudas.

Muy buen trabajo hasta ahora, lo del inventario por ejemplo, yo lo dejé tal cual. Si el fuente AGD no controla la "reutilización" de los objetos, pues arreando. He de reconocer que todas esas tablas de "crecimiento libre" tienen un peligro que pa' que... -507

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 11 May 2020 20:53

jltursan escribió:En cualquier caso, las rutinas de objetos te van a quedar en este caso mucho más simples sin lugar a dudas
Ya están convertidas y son simples. Lo mismo con los sprites ya que el trabajo duro lo hace el V9958
Si el fuente AGD no controla la "reutilización" de los objetos, pues arreando. He de reconocer que todas esas tablas de "crecimiento libre" tienen un peligro que pa' que... -507

Ciertamente peligrosas y no se puede simplemente añadir un control que límite el número de elementos ya que si permitimos 'duplicados' puede
pasar que éstos estan malgastando mucho espacio y luego no quepan bloques imprescindibles ...
De todas formas, para los patrones para textos he previsto una salida 'abrupta' en caso de que algún juego exceda de 255 patrones en algún tercio de pantalla, cosa que espero que no suceda nunca, pero por si las moscas paso las vidas a cero en color ROJO y el programa espera tecla y acaba.
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 12 May 2020 11:56

Antes de avanzar en otras funciones, he estado buscando cambios de color que vienen en el original AGD y que se 'perdieron'
en la conversión del motor AGD para MC6847 al pasarlos a blanco y negro ...
- Ahora tengo la función SetBorder que recibe un color en regA y utiliza su nibble bajo (ANDA #$07)
- De momento, para el comando SPRITEINK he creado un SpriteInk que recibe un color en regA, usa el nibble bajo y
pone a uno el bit5 (IC) => no detectar colisiones. Ya veremos mas adelante como implementar en el compilador una
llamada que pase una tabla de 16 valores (uno por linea del sprite)
Con los colores para los bloques/tiles/patrones no hay problema ya que puedo utilizar tu utilidad de conversión de colores
pero para los sprites el V9958 solo les admite un color, el de tinta, por lo que estoy utilizando el primer dígito hexadecimal de tu
utilidad pero usándolo como nibble bajo, o sea un $74 lo dejo en $04. Espero que esto sea correcto ...
Me he hecho una tabla con los resultados de tu conversor y me ha salido esto
;  -------------------------------------------------------
; SPC V9958 Red Blue Green FINAL values
; -------------------------------------------------------
; 0 1 BLACK 00 00 00 -> 0-0-0
; 1 4 DEEP BLUE 01 07 01 -> 0-7-0
; 2 6 DEEP RED 05 01 01 -> 4-1-1
; 3 D DEEP PURPLE 06 05 02 -> 6-6-0 (*)
; 4 C DEEP GREEN 01 01 04 -> 1-1-4
; 5 7 LIGHT BLUE 02 07 06 -> 0-7-6 (*)
; 6 A BRIGHT YELLOW 06 01 06 -> 7-0-7
; 7 E GREY 05 05 05 -> 4-4-4
; - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; 64 1 BLACK 00 00 00 -> 0-0-0
; 65 5 BRIGHT BLUE 02 07 03 -> 2-7-3
; 66 8 BRIGHT RED 07 01 01 -> 7-0-0
; 67 variante color D -> 6-5-2
; 68 3 LIGHT GREEN 03 03 07 -> 4-4-7
; 69 variante color 7 -> 2-7-6
; 70 B PALE YELLOW 06 04 06 -> 7-4-7
; 71 F WHITE 07 07 07 -> 7-7-7
; - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; NO UTILIZADOS (tenemos 2 tonos de estos colores)
; -- 2 BRIGH GREEN 01 01 06 -> 1-1-7
; -- 9 LIGHT RED 07 03 03 -> 7-4-4
; -------------------------------------------------------
Hay dos colores de Spectrum que se convieren a otros dos colores ya empleados, por lo que les he llamado 'variantes'
y voy a probar a cambiar ligeramente sus componentes RGB a ver que pasa ...
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 12 May 2020 13:35

me re-aparecen los problemas sobre coordenadas. En el original, el autor decidió que posX representaba la posición vertical
mientras que posY la horizontal, y así creó las variables dispX, dispY, charX y charY que te pueden volver loco si haces caso
de la letra final, por lo menos a mí, ya que *siempre* he utilizado Y para el je vertical -banghead
El compilador prepara las coordenadas para que luego la función DrpOb pueda hacer aparecer el objeto en su sitio ...
Pero como yo he decidido aplicar los valores haciendo caso de su letra, pues me llegan invertidas, así que la función DrpOb
ha de desfacer el entuerto. Simple y ya funciona bien.
Pero cuando uso la Pit Plant, ésta debería ser mostrada de inmediato pero ésto *no* sucede.
Cuando salgo de la pantalla y vuelvo a ella, entonces si aparece. Creo que es debido a que al hacer el DropObject lo que hace
el programa es cambiarle el número de pantalla en que se encuentra el objeto en la tabla de objetos, que al ser tratados
como sprites no se presentan gratis hasta que no volvemos a entrar en la pantalla, momento en que el programa carga
dinámicamente los sprites necesarios y los objetos también ... espero que sea ésto ya que bastará con hacer que la función
DrpOb genere el sprite. Ya suponía que los objetos me iban a traer algunos quebraderos de cabeza ...
saludos
pere

Pd El tema del SpriteInk me gusta ya que colorea algunos sprites en determinadas pantallas.
Cada vez se va pareciendo mas a la versión original AGD de Spectrum!

jltursan
Mensajes: 2937
Registrado: 20 Sep 2011 13:59
Agradecido : 240 veces
Agradecimiento recibido: 707 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 12 May 2020 18:48

Cuando salgo de la pantalla y vuelvo a ella, entonces si aparece. Creo que es debido a que al hacer el DropObject lo que hace
el programa es cambiarle el número de pantalla en que se encuentra el objeto en la tabla de objetos, que al ser tratados
como sprites no se presentan gratis hasta que no volvemos a entrar en la pantalla, momento en que el programa carga
dinámicamente los sprites necesarios y los objetos también

Totalmente cierto, si haces un "drop", estás haciendo el equivalente a un "spawn" y reclamando que aparezca en esa pantalla cuando al entrar, no se ha precargado. Si sales y entras, como ya ha sido asignado a esa habitación, se precarga.
Toda esta gestión puede tener otro handicap y es que al hacer el "get", se debería liberar el espacio en VRAM ocupado por el sprite/objeto...o no, igual no es necesario montar el pollo para recuperar un sprite.

La conversión de colores para los sprites es directa ya que los colores empleados no suelen ser en forma de atributo, de hecho, los solía convertir de cabeza, de un color a otro. Te puedo pasar la tabla de conversión que solía hacer y que es la misma en la que se basa el conversor de atributos que incluí.

Avatar de Usuario
pser1
Mensajes: 2989
Registrado: 08 Dic 2012 18:34
Agradecido : 695 veces
Agradecimiento recibido: 771 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 12 May 2020 20:14

muchas gracias José Luis,
no te preocupes por el tema colores. Incluso con los cambios que he hecho para no utilizar dos códigos distintos
con la misma definición RGB, se ve todo muy bien!
Respecto a los objetos, ya tenía una llamada a añadir Sprite cuando se crea un objeto nuevo, pero pasando mal
los parámetros no iba bien. Ahora aparece en el momento en que se selecciona la opción correcta en Inventario.
Con estos cambios me he pateado muchas pantallas, así que realmente necesito echar una ojeada al guia-burros
para poder completar el juego, con nueve vidas por si las moscas ...
Lo que me molesta es que en la pantalla que hay volviendo de coger la bomba, hay un enemigo que prácticamente siempre
se mueve hacia la derecha y no da opción para pasar. Solo 1 de cada 20 veces se va hacia la izquierda dejando paso libre
No veo ninguna diferencia importante entre el motor anterior MV6847 y este para V9958 así que añadiré una llamada a
la rutina Random para asegurar mas aleatoriedad en su dirección inicial -banghead
Referente a objetos al hacer un get, yo no libero nada ya que en cuanto cambias de pantalla se recarga todo dinámicamente
por lo que desaparece de las tablas lo que no hace falta. Y si en algún caso raro se tuviera que dejar el objeto en otro punto
de la misma pantalla, entonces habría que crearlo de nuevo ...
saludos
pere

jltursan
Mensajes: 2937
Registrado: 20 Sep 2011 13:59
Agradecido : 240 veces
Agradecimiento recibido: 707 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 12 May 2020 21:18

Si no recuerdo mal ese enemigo que mencionas se podía saltar. Ya con la versión de MSX en marcha me pasé el Foggy unas cuantas veces :-D
Me dió guerra hasta la última puñetera pantalla estática -banghead


Volver a “Software MSX”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado