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

jltursan
Mensajes: 2959
Registrado: 20 Sep 2011 13:59
Agradecido : 244 veces
Agradecimiento recibido: 719 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 12 May 2020 21:18

Último mensaje de la página anterior:

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

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 00:31

jltursan escribió: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

En la versión anterior en B/N entrando y saliendo varias veces acababa por dejarte pasar ...
Pero aquí por algún motivo se empeña en venir siempre hacia la derecha. El código en Event06 muestra que si en el offset 11,y del
sprite hay un valor no cero, lo primero que mira es si puede ir a la derecha y siempre puede -banghead
Trataré de ver como cambiaba antes de valor el programa solito ...
De momento, para poder ver mas pantallas, he añadido un aleatorio en el Event09 para el sprite 06 y así tengo un 50% de probabilidades
de pasar, por lo que no cuesta demasiado. Lo cierto es que creo que ya he pasado por todas las pantallas y me he llenado los bolsillos con
muchos objetos porqué el inventario se veía largo en algunos puntos del juego.
Creo que ya podría finalizar el juego si me mirara el walkthrough mañana. Estaría muy bien, ya que podría decir que YA tengo un juego
convertido! Realmente ha sido muchísimo mas rápido que la otra vez -thumbup
saludos
pere

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 00:32

por supuesto que quedan funciones por convertir, especialmente complejas las de Shrapnel (disparos, explosiones y demás)
Y alguna mas para mostrar valores numéricos con mas de un dígito ...
Pasito a pasito ...
saludos
pere

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 09:41

Buenos días,
He descubierto en que se basa la versión Spectrum y la anterior para MC6847 para que el enemigo 'incordión' cambie de dirección -507
Resulta que cuando se limpian los slots empleados por los sprites, NO se borran los datos de parámetros, solamente se pasan a 255
el tipo de sprite para indicar que el slot está libre!
Siempre que venimos de la pantalla 6 hacia la 4 suele perseguirnos el sprite que se mueve en horizontal por la linea larga de bloques.
Pero tan de cerca, que cuando nosotros llegamos al punto de cambio de pantalla, el sprite ya ha llegado a su límite izquierdo y se mueve
hacia la derecha. Comparando la lista de enemigos para ambas pantallas en la tabla nmeDat, he visto esto:
P6 - 0,0,80,32 - 6,6,104,168 - 4,3,8,192 - 4,6,72,144 - 1,7,128,64 - 1,7,128,176
P4 - 0,0,64,24 - 6,4,80,152 - 2,5,40,88

Al pasar de la pantalla 6 hacia la cuatro, el sprite 6,4 de la segunda fila heredará los parámetros del 6,6, de la primera fila
que, afortunadamente es del mismo tipo y por tanto 'cuadra' el uso de los parámetros -thumbup
Visto ésto, se ve claramente que debemos esperar a entrar en la pantalla 4 hasta que el enemigo indicado en la pantalla donde estamos
se mueva hacia la izquierda, así el de la pantalla 4 hará lo mismo alejándose y permitiéndonos entrar!
Lo he probado en la versión anterior de Dragón y funciona *siempre* -drinks
Ahora me quedo con la duda de si valdrá la pena 'emular' este procedimiento ... veré si es cosa simple de hacer ...
Lo que se aprende a base de tropiezos!
saludos
pere

Avatar de Usuario
minter
Mensajes: 2925
Registrado: 22 Jul 2014 18:51
Agradecido : 3194 veces
Agradecimiento recibido: 1343 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor minter » 13 May 2020 14:53

Eso de entrar en algunas pantallas y encontrarme enemigos a punto de matarme... siempre me ha matado!!! -banghead

O situaciones en las que entras en una pantalla y te mueres por una caida. Y al volver a situar al jugador, lo coloca por donde entraste y te vuelve a matar. Y así un bucle que te matan todas las vidas.
Ejemplo de esto dicho anteriormente: EL Goody de Opera. Si te caías del edificio en construcción... todas las vidas a la porra, porque te situaba otra vez por donde te caes.

Osea, Pere, quieres decir que el enemigo hereda los movimientos de la anterior pantalla, no? Es decir, que la dificultad o el truco radica en esperar a ver que hace el enemigo de nuestra pantalla para ya saber que ocurrirá en la siguiente, ¿no?
Bueno... un sistema cabroncete, pero puede valer. Peor es si el sprite de la pantalla siguiente tiene su propio contador de posición y nunca se resetea. Por lo que si está cerca del borde... te mata una vida nada mas entrar. -grin

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 16:52

minter escribió:Osea, Pere, quieres decir que el enemigo hereda los movimientos de la anterior pantalla, no? Es decir, que la dificultad o el truco radica en esperar a ver que hace el enemigo de nuestra pantalla para ya saber que ocurrirá en la siguiente, ¿no?
Efectivamente, viendo la dirección en la que se mueve el sprite de igual forma en la pantalla actual, el de pantalla de la izquierda heredará dicha dirección de movimiento, así que realmente puedes predecir lo que pasará, pero para ello hay que patearse el código y las tablas de datos ... Pero bueno es una forma de crear una aparente aleatoriedad
Bueno... un sistema cabroncete, pero puede valer. Peor es si el sprite de la pantalla siguiente tiene su propio contador de posición y nunca se resetea. Por lo que si está cerca del borde... te mata una vida nada mas entrar. -grin
En este caso y mas bien diría que muy mala 'idea' por no decir otra cosa, por parte del creador del programa ...
saludos
pere

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 17:10

@jltursan
antes de dar por buena la parte ya convertida, quería hacer que los objetos aparezcan en pantalla con los colores que se ven
en el walkthrough colgado en Internet para Spectrum.
He vuelto a generar el fichero AGD mediante el convert.exe pero veo que me crea casi lo mismo que tengo ...
*Todos* los objetos tienen en su DEFINEOBJECT un 71 como primer byte y esto implica que *todos* adquieren el color blanco :-(
No veo por ninguna parte como consigue el programa 'asociar' algún color a cada objeto ... también podría ser que el convert.exe
que utilizamos con Kees van Oss sea el culpable de esta uniformidad que ahora *no* deseamos ...
¿Puedes decirme como lo solucionaste tu? Manualmente puede hacerse, pero no me parece correcto que deba hacerse para cada juego!
saludos
pere

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 17:16

acabo de probar el convert.exe que se utiliza para MSX con el mismo resultado -banghead
¿Qué se me está escapando? -nb
muchas gracias
pere

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 17:24

minter escribió: Peor es si el sprite de la pantalla siguiente tiene su propio contador de posición y nunca se resetea. Por lo que si está cerca del borde... te mata una vida nada mas entrar. -grin
No me había fijado en el tema de 'contador de posición'. Los parámetros de los sprites son reseteados (excepto el Param 1) pero luego en la rutina ISpr se copian tres atributos importantes: imagen a emplear, posY, posX de forma que cada
sparite debe aparecer donde el creador del programa previó en cada pantalla
saludos
pere[/quote]

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 17:35

@jltursan
se me ha ocurrido mirar el programa convert.C y he visto que se pone a piñón fijo este valor porqué esta función
no estaba implementada antes, o sea que usan la variable cDefaultAttr para todos los objetos.
Puedes verlo en la función "OutputObjects"
Menuda trastada ... me parece una verdadera #~%& tener que buscarse la vida para averiguar los colores que hay que asignar
a cada objeto en cada juego. Con esto las ganas se caen al -25% -banghead
saludos
pere

jltursan
Mensajes: 2959
Registrado: 20 Sep 2011 13:59
Agradecido : 244 veces
Agradecimiento recibido: 719 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 13 May 2020 20:34

El "convert" no forma parte de mi suite MSX. No me parecía un objetivo demasiado interesante y no le dediqué tiempo, creo que Kees si que trató de apañar algo pero no se en que estado se quedó. En mi Github ya comento que no le brindaba soporte.

¿Cual es el problema exacto?, los objetos ZX tienen un atributo único de color que puede convertirse con mi cutre-conversor. En este caso es un atributo completo con ink+paper por lo que sólo ink podrá ser convertido al color del sprite MSX que se emplee. No creo que haya muchos objetos por ahí que vayan a emplear un paper diferente al del color de fondo común en su juego; así que el ink debería ser suficiente.

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 13 May 2020 23:18

jltursan escribió:El "convert" no forma parte de mi suite MSX. No me parecía un objetivo demasiado interesante y no le dediqué tiempo, creo que Kees si que trató de apañar algo pero no se en que estado se quedó. En mi Github ya comento que no le brindaba soporte.
¿Cual es el problema exacto?, los objetos ZX tienen un atributo único de color que puede convertirse con mi cutre-conversor. En este caso es un atributo completo con ink+paper por lo que sólo ink podrá ser convertido al color del sprite MSX que se emplee. No creo que haya muchos objetos por ahí que vayan a emplear un paper diferente al del color de fondo común en su juego; así que el ink debería ser suficiente.

Me he explicado fatal :-(
Todos los objetos definidos en la tabla objDat tienen el mismo valor en el campo COLOR: 71 que implica BLANCO
Mi pregunta es ... ¿Donde se puede encontrar la información de color que vemos que es aplicada a lo largo del juego?
El walkthrough muestra muchos objetos en color y alguno en blanco y negro. No existe el comando ObjectInk así que
me quedo a dos velas ...
¿Tienes alguna información adicional so bre este tema de color para objetos?
Para convertir juegos, la primera fase es extraer el fichero AGD a partir del .sna de Spectrum y para ello empleamos la utilidad convert.exe
y ésta *siempre* le coloca un 71 en el campo de color a todos los objetos -banghead
saludos
pere

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 14 May 2020 16:01

Buenas tardes,
He comentado mis dudas/problemas respecto a los colores de los objetos en el grupo de Facebook "Happy Coding!" y Allan Turvey
me ha explicado que los programadores lo que hacen es poner los objetos sobre bloques vacíos pero con colores ya definidos, entonces
debido al sistema de atributos de color del Spectrum, cualquier cosa que aterrice ahí tomará dichos colores.
Lo malo es que al ser bloques permite definir cuatro colores por objeto, uno para cada cuadrante del mismo, pero al usarlos como
sprites solo puedo llegar a tener dos colores, uno para la mitad superior y otro para la mitad inferior.
Veré si puedo implementar una rutina que en base a las coordenadas que se asignan al objeto puede recuperar los cuatro bloques que
va a sobreescribir, ver los colores asociados a los mismos y, tal vez, utilizar los dos de la izquierda para cada 8 bytes del sprite ... como
siempre es pura elucubración ... veremos si no lo complica demasiado. De hecho hará falta tanto al crear los objetos al montar una
pantalla como cuando se hace un DropObject ... creo que tienen una rutina en común que envía los datos al VDP ...
saludos
pere

jltursan
Mensajes: 2959
Registrado: 20 Sep 2011 13:59
Agradecido : 244 veces
Agradecimiento recibido: 719 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 14 May 2020 19:34

Ah, vaya, ya veo, es que esa es una problemática muy específica del ZX.

Como en el caso de mi conversión se requiere un rediseño por completo del objeto ya que empleo cuatro caracteres con la máxima resolución de color, asumo que los objetos MSX hay que rehacerlos manualmente por completo a todo color o como mínimo, emplear un mismo atributo 32 veces para el objeto, por ejemplo el que venga definido en la fuente AGD (que en las recuperadas del ZX, no siempre encuentras 71).

Si se rehacen, hay que estudiar el juego y por tanto, puedes darte cuenta de si un objeto emplea el truco de los atributos para tener cuatro zonas diferentes (en el Foggy, por ejemplo, el cubo de colores) y se diseña para MSX de forma acorde.

Yo no me comería mucho la cabeza y los dejaba monocromos, total, si en el Dragon estaban en B&N, ahora todavía se sigue ganando algo. Si se quiere ajuste fino, que más tarde se decida manualmente si se definen esa mitad superior de un color y la inferior de otro. En el atributo de color puedes emplear un nibble para una mitad y el otro para la otra.

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 14 May 2020 22:05

honestamente, José Luis, no creo que haya mucha gente que vaya a diseñar juegos nuevos para el V9958 a menos
que se consiga un entorno tipo AGDX para Windows/Mac/Linux y por tanto se pueda generar ficheros AGD fácilmente.
Lo mejor que puede pasar es que, alguien, tal vez yo mismo, se dedique a buscar entre los 219 juegos AGD ya convertidos
para MC6847 y seleccione los que le gusten y los convierta haciendo todo el proceso como la vez anterior.
Me suena que alguno de los usuarios de WorldOfDragon que han programado algún juego para Dragón se han interesado
por el nuevo módulo que está diseñando John. He visto resultados sobre una placa de desarrollo (breadboard) y según dice
mejora mucho la calidad del vídeo. Será cuestión de esperar para conseguir el nuevo módulo con el YM2149 añadido -thumbup
Algunos juegos funcionaban con muy pocos cambios, como ya se 'depuraron' espero que con disponer de un compilador en C
que lleve a cabo los cambios necesarios como re-ordenar datos de objetos y sprites y añadirle unas pocas funciones extra para que
la gestión de colores de sprites y patrones resulte casi automática en la generación del fichero fuente ASM para compilarlo -drinks
Tengo ya hecha la rutina para pintar los objetos, leerá los patrones de la izquierda de las dos filas que ocupa en su primera columna
y los utilizará para cada mitad del sprite (objeto), a ver que sucede. Siempre me queda la alternativa de poner a mano en cada objeto
el color que prefiera ...
saludos
pere

jltursan
Mensajes: 2959
Registrado: 20 Sep 2011 13:59
Agradecido : 244 veces
Agradecimiento recibido: 719 veces

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor jltursan » 15 May 2020 08:25

Yo tampoco creo que haya demasiados desarrollos específicos para MSX usando AGD; pero mira, a lo tonto ya han salido un par:

Paco el bombas:
https://www.youtube.com/watch?v=XnWhj7dEJGY

Numberman:
https://www.youtube.com/watch?v=1QFXCTUmfpE&feature=emb_logo

Conversiones sólo han aparecido las mías y el Terrahawks; pero es un pelín descuidada por el tema de las temporizaciones, además parece que se han reportado problemas con los MSX1 a 60Hz (japoneses) y tendría que dedicarle mucho tiempo a investigar un problema que no es fácil de reproducir en el emulador. En fin, que no creo que mucha gente se arremangue para convertir muchos juegos, yo seguro que me animo con alguna más, hay más de un juego que me gusta un montón y merecen pasar a formar parte del catálogo MSX.

En cualquier caso, el diseñador WinAGD ya está disponible para MSX y permite el diseño de elementos gráficos MSX nativos. Hay unos pocos detalles que todavía no permite; pero si uno se ha acostumbrado ya a usar esta herramienta, no está mal del todo. La conversión ZX->MSX es automática y es lo suficientemente buena como para obtener una versión MSX decente en dos patadas.

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

Re: Aprendiendo a manejar el chip de video V9958

Mensajepor pser1 » 15 May 2020 08:31

Hola de nuevo,
ya he conseguido añadir código para que los objetos hereden los colores de los bloques de la izquierda a los que su superponen ...
No requiere mucho código y es rápido y además cumple con los requisitos de los sprites en V9958, pero ...
MIrando bien el juego, se ven objetos que utilizan 4 colores, uno para cada bloque (cuadrante) por ejemplo el 'cube' o diamante, la
'pit Plant' por nombrar algunos y la verdad, ya que disponemos de un chip de vídeo superior, creo que lo ideal sería cambiar el proceso
de los objetos para poder tener los cuatro colores ahora y los 16 en el futuro.
Esto implica rehacer de cero todas las rutinas para objetos ya que pasarán a ser cuatro bloques que substituirán a otros tantos en el mapa
de pantalla. Habrá que guardarse los substituidos para reponerlos cuando el objeto sea 'cogido' o deba desaparecer.
Le echaré una ojeada a fondo este fin de semana, a ver si puedo 'dibujarme' un esquema de como procesarlos así.
Además debería hacer un vídeo en plan walkthrough de la situación actual de Foggy que, si no fuera por el tema de los objetos, ya estaría
finalizado y listo para ir en un disquete.
A diferencia de la versión para MC6847 en blanco y negro, esta versión solo requiere 32k así que funcionará en cualquier CoCo-Dragón
con 32k y por supuesto con la CPU HD6309 y el módulo Wordpak2+ o el nuevo módulo de John Whitworth
saludos
pere


Volver a “Software MSX”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 0 invitados