Karoshi MSX Community
21 de Agosto de 2018, 02:34:34 pm *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Ingresar Registrarse  
Páginas: [1] 2 3 4
  Imprimir  
Autor Tema: Dudas varias sobre programación en MSX  (Leído 16590 veces)
0 Usuarios y 1 Visitante están viendo este tema.
Mr Matsusaka
Karoshi Newbie
*
Mensajes: 15


Email
« : 29 de Enero de 2014, 01:48:29 pm »

Muy buenas,

Lo primero de todo me presento como nuevo usuario,
Trabajo haciendo aplicaciones para móviles, los lenguajes que domino son Java, C#, JavaScript, C++, etcetc
Recientemente me hice con un MSX1 por pura casualidad. Antiguamente poseia un ZX Spectrum +2b, y movido por la curiosidad y la nostalgia decidí adentrarme en el mundo de la programación retro. Mi pretensión no va mas allá de hacer un juego sencillo pero bien acabado.

El ensamblador utilizado es el asMSX en el EditPlus, tal como viene en el tutorial de zilogZ80

Hasta ahora he avanzado bastante sobretodo gracias a tutoriales como el anteriormente mencionado o el easymbler de Konamiman.
A parte de eso he googleado mucho y estudiado mucho acerca del código maquina, pese a lo cual aun sigo siendo un ignorante y me cuesta picar código de forma fluida. Mi código ahora es una especie de frankenstein hecho a base de pedazos de tutoriales y otros trozos que he ido cogiendo de aquí y allá.

Muchos conceptos del MSX son tratados en los foros como si todo el mundo los conociese y no requiriesen de mayor explicación, pero para un newbie como yo seria de gran ayuda que alguien me ayudase a aclarar algunos de estos conceptos. Tal vez yo tampoco se como buscar para encontrar la información adecuada... En cualquier caso me he decidido a registrarme en este foro y pedir algo de ayuda.

El siguiente video muestra hasta donde he llegado, aunque actualmente ya tengo a los enemigos apareciendo y moviéndose por la pantalla (aunque aun no disparan ni colisionan con los disparos del jugador)
http://www.youtube.com/watch?v=_wI9AUbH5ds

El código, por si alguien quiere verlo esta aqui:
https://drive.google.com/file/d/0B-6vVXEeG1u3Wk02YXVKZ05wTkE/edit?usp=sharing

Bien, las preguntas que quisiera formular son las siguientes:

1) El famoso scroll del MSX. Según he podido leer hay diversas técnicas, pero la única que he llegado a entender es aquella en la que se tiene dos sets de tiles para el escenario, siendo el segundo set el mismo que el primero, pero 4 pixeles subido. De tal modo que alternando entre un set y otro se consigue un efecto mas suave. Esto es así? Aun no he podido probar el programa en la maquina real, no supondrá esta técnica una penalización de velocidad? o el volcado a los bancos de tiles a la VRAM son lo suficientemente rápidos para llevar a cabo esta técnica?

2) Como he dicho en la anterior pregunta, aun no he podido probrar el programa en el ordenador real. Esto es porque el cartucho MegaFlash SCC+ es muy caro y aun no me he decidido a comprarlo. Ello me ha llevado a preguntarme si no es posible meter el juego en otros formatos que no sean rom, pero aunque he buscado mucho, no he encontrado ningún sitio que indique como compilar para disquete o cassete. Como se hace?

3) Según me ha parecido entender, no se puede tener tiles con el atributo de tamaño normal mezclados con tiles con el atributo de tamaño doble, a no ser que se haga algún truco con las interrupciones. Esto es así?

4) El tema de las interrupciones. Es algo que he leído muchas veces pero no llego a entender el concepto de un modo claro.
El siguiente ejemplo expuesto, es posible con las interrupciones?
    a) Pongo los tiles en la mitad de la pantalla arriba
    b) Pongo 32 sprites en la primera mitad de arriba de la pantalla
    c) Interrupción
    d) Pongo los tiles en la mitad de la pantalla abajo
    e) Pongo 32 sprites en la parte inferior de la pantalla
    f) Como resultado se ven 64 sprites en la pantalla, superando el limite por hardware de 32 sprites al mismo tiempo
Es esta suposición correcta? En caso afirmativo, alguien puede ponerme un pequeño ejemplo? En caso negativo, alguien podría explicarme lo de las interrupciones de tal modo que hasta un niño de 5 años entendiera? Hay manera de superar la limitacion de 4 sprites por linea con esta técnica?

5) El tema de la música. He visto algunas librerías para reproducir música. Me gustaría entender como funciona mas o menos.
Según me ha parecido entender, la forma mas básica de reproducir música seria con un array de sonidos pasándolos por una función que va leyendo los datos dinamicamente y durante toda la ejecución del programa, para ir emitiendo los sonidos uno a uno y en orden cronológico. Esto es correcto?

6) Guardado de datos. Es posible guardar records? Como se hace? Es posible hacerlo independientemente de si el programa se compila como .cas, .dsk o .rom?

Muchas dudas de las que tengo las he buscado previamente sin éxito. Sin embargo puede que algunas de las cosas que pregunto sean temas muy trillados anteriormente. En tal caso espero sepan perdonarme.

Gracias de antemano
En línea
SapphiRe_MSX
Visitante
« Respuesta #1 : 29 de Enero de 2014, 03:43:26 pm »

1) El famoso scroll del MSX. Según he podido leer hay diversas técnicas, pero la única que he llegado a entender es aquella en la que se tiene dos sets de tiles para el escenario, siendo el segundo set el mismo que el primero, pero 4 pixeles subido. De tal modo que alternando entre un set y otro se consigue un efecto mas suave. Esto es así? Aun no he podido probar el programa en la maquina real, no supondrá esta técnica una penalización de velocidad? o el volcado a los bancos de tiles a la VRAM son lo suficientemente rápidos para llevar a cabo esta técnica?

Asumo que hablas de MSX1, ya que MSX2 o superior tienen "scroll" (sí, entrecomillado) por hardware.

Hay muchas formas de hacer el scroll en MSX1 y dependen, en gran medida, de qué quieres mover, en qué screen y en qué dirección. Lo que tú comentas sirve para hacer un scroll vertical de 4 pixels en 4 pixels, en lugar de un scroll carácter a carácter (que sería de 8 en Cool.

El volcado a VRAM será más rápido cuanto menos tengas que volcar. Pero podría darte para volcar prácticamente toda la pantalla.

<publi>Si quieres ver esta técnica llevada al extremo (scroll pixel a pixel), échale un vistazo a mi juego QBIQS Smiley </publi>

Citar
2) Como he dicho en la anterior pregunta, aun no he podido probrar el programa en el ordenador real. Esto es porque el cartucho MegaFlash SCC+ es muy caro y aun no me he decidido a comprarlo. Ello me ha llevado a preguntarme si no es posible meter el juego en otros formatos que no sean rom, pero aunque he buscado mucho, no he encontrado ningún sitio que indique como compilar para disquete o cassete. Como se hace?

La ventaja del formato ROM es que todo es mucho más natural. Si tu ROM no tiene más de 48K lineales puedes cargarla a través de disquete con el excelentísimo programa ODO.

Citar
3) Según me ha parecido entender, no se puede tener tiles con el atributo de tamaño normal mezclados con tiles con el atributo de tamaño doble, a no ser que se haga algún truco con las interrupciones. Esto es así?

Si cambias "tile" por "sprite", sí, es así.

Citar
4) El tema de las interrupciones. Es algo que he leído muchas veces pero no llego a entender el concepto de un modo claro.
El siguiente ejemplo expuesto, es posible con las interrupciones?
    a) Pongo los tiles en la mitad de la pantalla arriba
    b) Pongo 32 sprites en la primera mitad de arriba de la pantalla
    c) Interrupción
    d) Pongo los tiles en la mitad de la pantalla abajo
    e) Pongo 32 sprites en la parte inferior de la pantalla
    f) Como resultado se ven 64 sprites en la pantalla, superando el limite por hardware de 32 sprites al mismo tiempo
Es esta suposición correcta?

No en MSX1, ya que el VDP no puede generar interrupciones que no sean de vblank. La única forma sería sacrificar dos sprites y ponerlos superpuestos a mitad de pantalla. Entonces se tendría que hacer un bucle que estuviera comprobando el bit de colisión de sprites y, en el momento en el que se detecte la colisión, cambiar la tabla de atributos de sprites. De esa forma tendrías unos 30 sprites para la parte superior y 32 para la inferior: 62 sprites.

Y ojo, el volcado a VRAM es lo más crítico, porque es lo que más tarda y lo más dependiente de si el VDP está pintando o no. Lo ideal es realizar este volcado durante el vblank (que es el tiempo entre que salta la interrupción de vblank, al pintar la última línea visible de pantalla, y se comienza el dibujado de la primera línea del siguiente frame). A ese tiempo le tienes que descontar lo que emplee la BIOS si es que la utilizas, claro está.

Por lo tanto, lo ideal es volcar TODO a VRAM en ese tiempo. Ten en cuenta que te va a dar escasamente para actualizar los tiles de toda la pantalla, por lo que lo primordial es el diseño: tener muy claro qué hay que actualizar y sólo actualizar eso.

Citar
En caso afirmativo, alguien puede ponerme un pequeño ejemplo? En caso negativo, alguien podría explicarme lo de las interrupciones de tal modo que hasta un niño de 5 años entendiera?

Cuando se termina de pintar la última línea visible, y antes de pintar la primera línea con el color de borde de la parte inferior, el VDP genera una interrupción llamada vblank. Si el procesamiento de las interrupciones está activado, en ese momento se produce un salto a una dirección de memoria que va a depender del modo de interrupción en el que el Z80 esté en ese momento. Lo normal es que esté en modo IM1, así que se salta a #0038.

Esa rutina se ejecuta, por tanto, cada vez que se termina de dibujar la pantalla: unas 50 veces por segundo en PAL y 60 en NTSC. Es la forma básica de controlar el tiempo en MSX y sincronizar las acciones pertinentes. Cuando se termina la rutina de interrupción, se vuelve al punto donde se había interrumpido (jejeje) la ejecución, la cual sigue.

A grandes rasgos eso es una interrupción. El VDP de los MSX2 y superiores pueden generar otros tipos de interrupción. Otros cacharros pueden generar otro tipo de interrupciones. TODAS ELLAS van a provocar un salto a la misma dirección (#0038 en modo IM1), por lo que si tuvieras que tratar varios tipos de interrupciones, la rutina de #0038 debe comprobar cuál se ha producido. Eso lo hace bastante bien la BIOS, que proporciona unos ganchos en la parte superior de la RAM donde puedes poner un salto a tu rutina de tratamiento de interrupciones.

Citar
Hay manera de superar la limitacion de 4 sprites por linea con esta técnica?

No sin parpadeos.

Citar
5) El tema de la música. He visto algunas librerías para reproducir música. Me gustaría entender como funciona mas o menos.
Según me ha parecido entender, la forma mas básica de reproducir música seria con un array de sonidos pasándolos por una función que va leyendo los datos dinamicamente y durante toda la ejecución del programa, para ir emitiendo los sonidos uno a uno y en orden cronológico. Esto es correcto?

Lo primero es saber qué chip quieres usar. Para cada chip hay diferentes programas que permiten hacer música y/o efectos de sonido. Luego sería utilizar el reproductor adecuado, incluir en el código el fichero de música (en el formato que te grabe el programa) y seguir las instrucciones de uso del reproductor.

Por ejemplo, el vortex tracker graba un fichero .pt3, tú lo metes en el código como un binario y el reproductor que hay para asMSX tiene una serie de rutinas que te permiten inicializar la música y luego generar los valores que hay que volcar en los registros de sonido. Yo lo que hago normalmente es seguir este patrón:

esperar interrupción vblank
volcar datos a VRAM (siempre lo más crítico)
volcar datos a registros de sonido
leer mandos
calcular cambios en la visualización para el siguiente frame
generar datos de sonido para el siguiente frame
esperar interrupción vblank...

Citar
6) Guardado de datos. Es posible guardar records? Como se hace? Es posible hacerlo independientemente de si el programa se compila como .cas, .dsk o .rom?

Siempre es posible, pero depende de dónde lo quieras guardar:

  • ¿En la propia ROM? Necesitas que sea FLASH y hacer las rutinas de guardado.
  • ¿En el cassete? Pues necesitas las rutinas de lectura y grabación de/al cassette.
  • ¿En el disco? Tres cuartos de lo mismo, aparte de tener que meterte con el S.O.

Como ves tus preguntas suscitan más preguntas, pero sigue así Cheesy
« Última modificación: 29 de Enero de 2014, 03:45:50 pm por SapphiRe » En línea
pitpan
Karoshi Forum's Guru
*******
Mensajes: 1812


« Respuesta #2 : 29 de Enero de 2014, 04:17:36 pm »

Como programador original del asMSX te hago solo una sugerencia fácil para probar tus juegos en el ordenador real.

- Crea el fichero como una ROM (directiva .ROM) en la página 2, es decir, a partir de 8000h (.page 2)
- Añade la directiva para generar un fichero de audio de salida (directiva .WAV)

Ahora, al ensamblar, además del fichero ROM te producirá un fichero WAV de audio. Reprodúcelo desde el PC, el móvil, el MP3 o lo que tengas y conéctalo al MSX real utilizando el cable de cassette, utilizando la instrucción de carga BLOAD"CAS:",R

Así podrás cargar los juegos gratis, aunque con dos importantes limitaciones:

- Solo te valdrá en principio para ROMs de hasta 16 KB
- La velocidad de carga es la más rápida entre las estándar, es decir, 2.400 baudios

Si en lugar de usar la directiva ROM usas las directiva BASIC, te generará un BIN en lugar de un ROM. Ese BIN lo puedes cargar en el MSX desde BASIC empleando BLOAD. Si lo copias en un disco, podrás cargarlo directamente. Si no, puedes cargar el WAV de audio directamente por el puerto de cassette, y te aguantará así hasta 32 KB (teóricamente).

Y si quieres generar ficheros para cargar desde disco en MSX-DOS, utiliza la directiva .dos o .msxdos, no recuerdo bien. Comprueba las instrucciones para ver qué te cuentan.

Bienvenido al foro y al MSX, y muchos ánimos para seguir adelante con tus proyectos.
En línea
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #3 : 29 de Enero de 2014, 07:13:52 pm »

Hola!

Si es tu primer juego para MSX yo te recomendaría "aparcar" las técnicas avanzadas (scroll suave, screensplit para tener más sprites, etc.) e intentar alinear el juego a las limitaciones del MSX.

Unos comentarios al respecto del código:

Por lo que veo haces scroll sacando una línea de la tabla de nombres de VRAM a RAM y volviendo a volcar una línea más arriba... y todo con la BIOS. Entiendo que el mapa es cíclico de 24 caracteres de alto. Dado que ya tienes los valores a volcar en ROM (GFX_STG_1_MAPS_1 y siguientes), creo que sería mucho más eficiente hacer lo siguiente:
  • Estoy en el frame x, calculo u=x módulo 24 y v=24-u
  • A partir de origen GFX_STG_1_MAPS_1 + 24*v y destino NAMTBL, hago un bucle de u volcados LDIRVM de una línea (24 caracteres) y voy actualizando el destino (avanzando líneas)
  • A partir de origen GFX_STG_1_MAPS_1 y con el destino que tuviera, hago un bucle de v volcados LDIRVM de una línea (24 caracteres)
  • Incremento u
Y además te valdría para el volcado inicial.
Bueno, estoy viendo ahora que tienes 18 líneas de patrones, no 24... habría que ajustar un poco el algoritmo, pero creo que la idea es buena.

Por otra parte, veo que utilizas Pletter-VRAM... Quizá te salga a cuenta pasarte a Pletter-RAM con un buffer. El volcado de gráficos puntuales será algo más lento (habrá que hacer luego un LDIRVM), pero puedes descomprimir una vez y volcar a los tres patrones y además te valdría para los datos: diseño de niveles, enemigos, etc.

Por las extensiones de los ficheros me imagino que usas PCX2MSX. Como veo datos de tablas de nombres en el código, imagino que las habrás hecho a mano. Échale un vistazo a este hilo, que a lo mejor te doy una alegría </autobombo> Tongue

Por lo demás, aunque hay cosillas que pulir, ¡yo creo que vas francamente bien!
En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
ARTRAG
Visitante
« Respuesta #4 : 31 de Enero de 2014, 08:55:19 am »

Hi Mr Matsusaka,
Very nice start! Welcome !
I've mailed you something that answer some of your questions
AR
En línea
MsxKun
Karoshi Forum's Guru
*******
Mensajes: 1554


Kimochi-ii


WWW Email
« Respuesta #5 : 31 de Enero de 2014, 05:47:37 pm »

Bienvenido y tal Cheesy

Te digo lo mismo que Nestruo. Ahora para empezar olvídate de cosas raras y no te compliques. Hazlo sencillo y céntrate en un buen diseño y en que sea divertido. El MSX tiene sus limitaciones y tal. No te calientes ahora en superarlas, simplemente ves aprendiendo, cógele el gustillo, descubre cosas y pásatelo bien con ello.

Los adornos floridos técnicos no valen UNA MIERDA (así escrito en plata) si el juego es aburrido y soso. Lo cual no quita que puedas hacer mil pruebas de mil cosas, ¡es parte de la diversión! Smiley Pero no te ofusques.

Ah, y no te fies jamás de los emuladores, son el diablo Wink Muy bien para probar y debuggear, pero que jamás te eviten probar el código a fondo en la máquina real, que luego hay sorpresas y nada funciona como debe. En este sentido, las Megaflash no son caras. La cantidad de jugo que les sacas valen cada euro invertido.
En línea

--

Cindy Lauper She Bops!
aorante
Karoshi Maniac
****
Mensajes: 450


nuTella Power!


WWW Email
« Respuesta #6 : 31 de Enero de 2014, 07:13:50 pm »

Hola!

Me sumo a lo dicho por mis compañeros.
En lo que puedas utiliza la BIOS donde tienes mucho trabajo hecho y te garantiza compatibilidad entre ordenadores/generaciones.

Sobre el tema música te puedo hablar del WYZplayer desarrollado por un compañero de estos foros (Iggy Rock). La música y los FX se puede desarrollar desde su cross-tracker WYZtracker (para win), y exportar para asMSX (aunque adaptable para otros compiladores). Permite tener varias canciones aprovechando un único set de instrumentos y esta optimizado para ocupar poca memoria pensando en el desarrollo de juegos. Tendrás que bajarte el player y adjuntarlo a tu proyecto. Parta hacerlo funcionar, lo primero es iniciar el player indicando que canción quieres hacer sonar. Luego desde la interrupción llamar la rutina que reproduce el buffer de sonido y en el hilo principal del juego la función que interpreta las pistas de la canción (casi todos los players funcionan igual). En cualquier momento puedes lanzar un FX del juego pero solo uno a la vez.
https://sites.google.com/site/wyzplayer/
https://sites.google.com/site/augustoruiz/

Lo que se muestra en el vídeo tiene muy buena pinta!! Shocked
para ser una "ópera prima" tiene mucho nivel, sobre todo los gráficos.  Wink

participas en la msxdev'14?

Animo con tu proyecto!
En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
Mr Matsusaka
Karoshi Newbie
*
Mensajes: 15


Email
« Respuesta #7 : 01 de Febrero de 2014, 10:19:05 am »

Muchas gracias por vuestras contestaciones y perdonad la tardanza en contestar.

SapphiRe:
Si, hablo de MSX1.
Citar
<publi>Si quieres ver esta técnica llevada al extremo (scroll pixel a pixel), échale un vistazo a mi juego QBIQS Smiley </publi>

Esta buenísimo! No solo lo suave del scroll, tambien lo original de concepto. Una especie de mezcla del tetris con un juego de naves!
Hablando del scroll, creo que de momento, y como dice theNestruo, voy a dejarlo asi de momento para no complicarme demasiado la vida. En cualquier caso si al final lo intento se que camino tomar. Gracias!

Citar
Cuando se termina de pintar la última línea visible, y antes de pintar la primera línea con el color de borde de la parte inferior, el VDP genera una interrupción llamada vblank. Si el procesamiento de las interrupciones está activado, en ese momento se produce un salto a una dirección de memoria que va a depender del modo de interrupción en el que el Z80 esté en ese momento. Lo normal es que esté en modo IM1, así que se salta a #0038.
Creo que me ha quedado bastante claro el tema de las interrupciones, al menos a nivel teórico. A parte de esta explicación he leído mas explicaciones tuyas en otros temas como este.

http://karoshi.auic.es/index.php?topic=1931.0
Esta claro que no había buscado lo suficiente! Tongue
Pero aun no me queda claro un detalle. En la practica, a nivel de código, como se que parte del código entra dentro del vblank y cual no? Se puede controlar?

Otra cosa. Que hace "halt"? Recuerdo que al principio sin una llamada a este comando la velocidad del juego era excesiva. Al añadirlo la velocidad bajo a unos niveles mas normales. A mi modo de ver lo interprete como una especia de controlador de frames. Busque en internet pero las explicaciones sobre este comando eran bastante técnicas, y difíciles de entender. Me gustaría mas que una explicación de como funciona internamente una explicación de como afecta al juego y que usos prácticos tiene.

Citar
Por ejemplo, el vortex tracker graba un fichero .pt3, tú lo metes en el código como un binario y el reproductor que hay para asMSX tiene una serie de rutinas que te permiten inicializar la música y luego generar los valores que hay que volcar en los registros de sonido.
Cuando tenga un poco de tiempo voy a invertigar este vortex tracker.

Citar
Siempre es posible, pero depende de dónde lo quieras guardar:

¿En la propia ROM? Necesitas que sea FLASH y hacer las rutinas de guardado.
¿En el cassete? Pues necesitas las rutinas de lectura y grabación de/al cassette.
¿En el disco? Tres cuartos de lo mismo, aparte de tener que meterte con el S.O.
Uf, supongo que al final el juego será en formato rom, así que mirar lo del cassete o el disco seria una perdida de tiempo de momento.
Podrías explicarme un poco el procedimiento para guardar en la propia rom?
En línea
Mr Matsusaka
Karoshi Newbie
*
Mensajes: 15


Email
« Respuesta #8 : 01 de Febrero de 2014, 10:21:10 am »

Como programador original del asMSX te hago solo una sugerencia fácil para probar tus juegos en el ordenador real.

- Crea el fichero como una ROM (directiva .ROM) en la página 2, es decir, a partir de 8000h (.page 2)
- Añade la directiva para generar un fichero de audio de salida (directiva .WAV)

Ahora, al ensamblar, además del fichero ROM te producirá un fichero WAV de audio. Reprodúcelo desde el PC, el móvil, el MP3 o lo que tengas y conéctalo al MSX real utilizando el cable de cassette, utilizando la instrucción de carga BLOAD"CAS:",R

Así podrás cargar los juegos gratis, aunque con dos importantes limitaciones:

- Solo te valdrá en principio para ROMs de hasta 16 KB
- La velocidad de carga es la más rápida entre las estándar, es decir, 2.400 baudios

Si en lugar de usar la directiva ROM usas las directiva BASIC, te generará un BIN en lugar de un ROM. Ese BIN lo puedes cargar en el MSX desde BASIC empleando BLOAD. Si lo copias en un disco, podrás cargarlo directamente. Si no, puedes cargar el WAV de audio directamente por el puerto de cassette, y te aguantará así hasta 32 KB (teóricamente).


Muchas gracias por tus explicaciones.

De momento he comprado por ebay el cable (el reproductor aun tengo que mirarlo un poco mas)
El rom resultante aun no supera los 16 kilobytes, así que supongo que aun puedo hacer la prueba en formato .wav. Igualmente la directiva BASIC puede ser otra solución alternativa.
EDIT: he probado la directiva BASIC y me genera el bin sin problemas, pero la directiva .WAV no me la reconoce, me da error de sintaxis.
EDIT2: creo que al final me voy a comprar el cartucho flash... Tongue

En cualquier caso muchas gracias y sobre todo agradecerte personalmente que hayas desarrollado asMSX!
En línea
Mr Matsusaka
Karoshi Newbie
*
Mensajes: 15


Email
« Respuesta #9 : 01 de Febrero de 2014, 11:02:55 am »

Por lo que veo haces scroll sacando una línea de la tabla de nombres de VRAM a RAM y volviendo a volcar una línea más arriba... y todo con la BIOS. Entiendo que el mapa es cíclico de 24 caracteres de alto. Dado que ya tienes los valores a volcar en ROM (GFX_STG_1_MAPS_1 y siguientes), creo que sería mucho más eficiente hacer lo siguiente:
  • Estoy en el frame x, calculo u=x módulo 24 y v=24-u
  • A partir de origen GFX_STG_1_MAPS_1 + 24*v y destino NAMTBL, hago un bucle de u volcados LDIRVM de una línea (24 caracteres) y voy actualizando el destino (avanzando líneas)
  • A partir de origen GFX_STG_1_MAPS_1 y con el destino que tuviera, hago un bucle de v volcados LDIRVM de una línea (24 caracteres)
  • Incremento u
Y además te valdría para el volcado inicial.
Bueno, estoy viendo ahora que tienes 18 líneas de patrones, no 24... habría que ajustar un poco el algoritmo, pero creo que la idea es buena.
Basicamente asi es. Copio la primera fila de tiles de la VRAM a RAM en un buffer que no vuelvo a tocar hasta el final.
Luego para el resto de filas hago el mismo procedimiento con otro buffer pero al volver a volcar a VRAM lo hago una fila mas arriba.
Y al final pego el buffer del primer paso a la ultima fila correspondiente en la VRAM.

Supongo que copiar datos de la VRAM a la RAM no es lo mas optimo no?
Con tu sistema lo único que se pierde es un poco de memoria, por lo que me parece entender.

Teniendo en cuenta que mi scroll esta formado por 16 lineas * 24 tiles eso serian 384 bytes de buffer. Supongo que no es tanto, pero lo cierto es que ya he tenido un par de avisos quedándome sin espacio RAM. Merecerá la pena el ahorro de velocidad? Como no puedo testear el juego en el ordenador de verdad no se hasta que punto las cosas que programo serán lentas Tongue

Esto me lleva a otra pregunta que me ronda la cabeza últimamente.
Los datos para engendrar nuevos enemigos son estáticos, no los genero dinamicamente, sino que ya están definidos en un largo array de datos. Al meter la información de las tres fases con las que el juego contará me quede sin espacio en la ram. Hay forma de tener toda la información en la rom pero que solo se cargue en la ram la información de la fase correspondiente?

Como veis soy SUPER newbie. Tongue

Por las extensiones de los ficheros me imagino que usas PCX2MSX. Como veo datos de tablas de nombres en el código, imagino que las habrás hecho a mano. Échale un vistazo a este hilo, que a lo mejor te doy una alegría </autobombo> Tongue
Si, uso PCX2MSX. Aunque he montado un .bat que me procesa los graficos de una manera muy comoda para mi proyecto.
Ahora no tengo mucho tiempo asique hechare un vistazo luego a tu link para ver que me puede ofrecer!
En línea
SapphiRe_MSX
Visitante
« Respuesta #10 : 01 de Febrero de 2014, 05:30:54 pm »

Citar
<publi>Si quieres ver esta técnica llevada al extremo (scroll pixel a pixel), échale un vistazo a mi juego QBIQS Smiley </publi>
Esta buenísimo! No solo lo suave del scroll, tambien lo original de concepto. Una especie de mezcla del tetris con un juego de naves!

Hombre, el concepto es original de Konami, que hizo el Quarth en 1990.

Citar
Creo que me ha quedado bastante claro el tema de las interrupciones, al menos a nivel teórico. A parte de esta explicación he leído mas explicaciones tuyas en otros temas como este.

...

Pero aun no me queda claro un detalle. En la practica, a nivel de código, como se que parte del código entra dentro del vblank y cual no? Se puede controlar?

Se pueden hacer pruebas. Yo lo que hago en la fase de pruebas es cambiar el color de fondo cuando entro en la interrupción y después volver a cambiarlo cuando termino de volcar a VRAM (que es, repito, lo más crítico). Así puedes ver una franja de color diferente. Si esa franja llega (por la parte de arriba) a meterse dentro de la imagen (es decir, llega más abajo del borde), entonces es que el código que has ejecutado entre ambos cambios de color tarda más en ejecutarse que el tiempo de vblank.

Citar
Otra cosa. Que hace "halt"?

Realmente halt lo que hace es repetir indefinidamente la instrucción nop. Sólo se detiene ese bucle indefinido si se produce una interrupción (y no están desactivadas). Así que halt lo que hace es... esperar una interrupción. Como, para nuestros propósitos, la única interrupción que se tiene en cuenta es la del vblank, lo que te permite hacer halt es sincronizar el código con el trazado de la pantalla y así asegurarte de que la actualización de pantalla (por ejemplo) se realiza cuando no se está pintando la pantalla y, por lo tanto, no habrá glitches (errores gráficos visibles).

También, como el vblank ocurre cada cierto periodo de tiempo (1/50 seg en PAL, 1/60 seg en NTSC), te permite tener un control del tiempo, para tareas que lo requieran (timer, reproductor de música...)

Citar
Uf, supongo que al final el juego será en formato rom, así que mirar lo del cassete o el disco seria una perdida de tiempo de momento.
Podrías explicarme un poco el procedimiento para guardar en la propia rom?

Para eso el juego debe estar en formato físico y que el cartucho te permita hacer eso. Yo lo olvidaría de momento, no es algo trivial.
« Última modificación: 01 de Febrero de 2014, 05:35:39 pm por SapphiRe » En línea
Mortimer
Karoshi Lover
***
Mensajes: 216


WWW
« Respuesta #11 : 01 de Febrero de 2014, 10:58:25 pm »

Hola Mr Matsusaka, bienvenido, es una alegría ver cómo sigue llegando gente con ganas de aprender. Me ha gustado mucho el vídeo de lo que llevas hecho, ¿Los gráficos también son tuyos?

Todavía no he podido mirar el código, pero hay una cosa que me extraña un poco y es eso que comentas de que el buffer de 384 bytes puede ser mucho porque te estás quedando sin RAM, ¿Con que la estás ocupando? Una vez que tienes todo ya cargado en vram con un puñado de bytes para las variables de posiciones, disparos, marcadores y alguna cosita más deberían ser suficientes. Quizás te podría servir esto que tengo un poco a medias pero que funciona: http://karoshi.auic.es/index.php/topic,2201.0.html sería muy sencillo modificar las rutinas para hacer que el desplazamiento fuera circular con la misma idea que comenta theNeustro.

En cuanto a la velocidad que tendrá en un MSX real, es prácticamente la misma que la que tendrás en el emulador porque en temporización son bastante exactos, pero deberías probar con la BIOS oficial en lugar de con C-BIOS, porque las rutinas de lectura/escritura oficiales a VRAM son muy conservadoras (lentas), y las de C-BIOS son bastante más rápidas. Así que mejor probar con lo peor que luego funcionará bien en todos los casos. Y por lo mismo deberías de probar con una máquina a 60Hz, porque tienes menos ciclos por interrupción para hacer todo o necesario, y luego a 50Hz seguro que irá bien, pero al contrario puede que no.

Saludos
En línea
Mr Matsusaka
Karoshi Newbie
*
Mensajes: 15


Email
« Respuesta #12 : 02 de Febrero de 2014, 10:17:44 am »

Citar
Pero aun no me queda claro un detalle. En la practica, a nivel de código, como se que parte del código entra dentro del vblank y cual no? Se puede controlar?

Se pueden hacer pruebas. Yo lo que hago en la fase de pruebas es cambiar el color de fondo cuando entro en la interrupción y después volver a cambiarlo cuando termino de volcar a VRAM (que es, repito, lo más crítico). Así puedes ver una franja de color diferente. Si esa franja llega (por la parte de arriba) a meterse dentro de la imagen (es decir, llega más abajo del borde), entonces es que el código que has ejecutado entre ambos cambios de color tarda más en ejecutarse que el tiempo de vblank.

Citar
Otra cosa. Que hace "halt"?

Realmente halt lo que hace es repetir indefinidamente la instrucción nop. Sólo se detiene ese bucle indefinido si se produce una interrupción (y no están desactivadas). Así que halt lo que hace es... esperar una interrupción. Como, para nuestros propósitos, la única interrupción que se tiene en cuenta es la del vblank, lo que te permite hacer halt es sincronizar el código con el trazado de la pantalla y así asegurarte de que la actualización de pantalla (por ejemplo) se realiza cuando no se está pintando la pantalla y, por lo tanto, no habrá glitches (errores gráficos visibles).

También, como el vblank ocurre cada cierto periodo de tiempo (1/50 seg en PAL, 1/60 seg en NTSC), te permite tener un control del tiempo, para tareas que lo requieran (timer, reproductor de música...)

Muchas gracias por tu explicación. Creo que al fin he dado con una explicación .
Las pruebas que dices que cambias el color el fondo cuando entras en la interrupción, a nivel de código seria precisamente tras el halt, no es así?
Creo que voy a probar a insertar este sistema. Muchas gracias!

Una pregunta tonta: si pongo dos halt seguidos, con eso conseguiría que el juego vaya a 25 fps en PAL?

Sobre el guardado, creo que lo vamos a dejar así. Al fin y al cabo solo seria para guardar records.
Los juegos comerciales que guardaban datos, llevaban incorporada una memoria flash para tal efecto, o se hacia de otra manera?

En cualquier caso muchas gracias por todo vuestro apoyo, gracias a la información que aquí he recabado me siento con mas confianza para avanzar en la programación de este juego!
En línea
Mr Matsusaka
Karoshi Newbie
*
Mensajes: 15


Email
« Respuesta #13 : 02 de Febrero de 2014, 10:40:12 am »

Hola Mr Matsusaka, bienvenido, es una alegría ver cómo sigue llegando gente con ganas de aprender. Me ha gustado mucho el vídeo de lo que llevas hecho, ¿Los gráficos también son tuyos?
Bueno, en realidad yo era del Spectrum, pero me hice con un MSX de casualidad y una cosa lleva a la otra y...
Los gráficos son míos al 100%. Si alguien quiere que le haga gráficos para algún proyecto estoy abierto a escuchar propuestas.

Todavía no he podido mirar el código, pero hay una cosa que me extraña un poco y es eso que comentas de que el buffer de 384 bytes puede ser mucho porque te estás quedando sin RAM, ¿Con que la estás ocupando? Una vez que tienes todo ya cargado en vram con un puñado de bytes para las variables de posiciones, disparos, marcadores y alguna cosita más deberían ser suficientes. Quizás te podría servir esto que tengo un poco a medias pero que funciona: http://karoshi.auic.es/index.php/topic,2201.0.html sería muy sencillo modificar las rutinas para hacer que el desplazamiento fuera circular con la misma idea que comenta theNeustro.

Principalmente con la información de los enemigos, donde aparecen, en que momento y con que propiedades. Debe haber como 50 enemigos en la primera fase, y mas de 100 en la tercera. Toda la información está en el código, pero de momento he comentado los datos de la segunda y la tercera fase. Si descomento aunque solo sea la segunda, el compilador me dice que no puede acceder a determinadas partes del código. Supongo que esto es un indicativo de que he sobrepasado la memoria de la pagina, no es así?

En cuanto a la velocidad que tendrá en un MSX real, es prácticamente la misma que la que tendrás en el emulador porque en temporización son bastante exactos, pero deberías probar con la BIOS oficial en lugar de con C-BIOS, porque las rutinas de lectura/escritura oficiales a VRAM son muy conservadoras (lentas), y las de C-BIOS son bastante más rápidas. Así que mejor probar con lo peor que luego funcionará bien en todos los casos. Y por lo mismo deberías de probar con una máquina a 60Hz, porque tienes menos ciclos por interrupción para hacer todo o necesario, y luego a 50Hz seguro que irá bien, pero al contrario puede que no.

Si, yo estoy con la C-BIOS. Tengo que probar la BIOS normal como dices.
Muchas gracias por tu mensaje!


Estoy pensando en comprarme el cartucho flash. He visto que hay principalmente dos.

El MegaFlashRom SCC(60 EUROS) y el MegaFlashRom SCC+ SD(99 EUROS el mas barato). La diferencia de precio es considerable, pero supongo que poder meter las roms en una SD será infinitamente mas cómodo que tener que comprar una interface para poder conectar el cartucho al pc, no?

A parte el MegaFlashRom SCC+ tiene versiones con 512 kb de ram extra + otra ranura para una segunda SD. No se si merece la pena desembolsar un poco mas de dinero por estas características. Es útil para algo en concreto tener esta segunda ranura? Los 512 kb de memoria extra seria para ejecutar roms con mas contenido? Teniendo en cuenta que solo funcionaria en ordenadores con similares capacidades, perderíamos compatibilidad si usamos esos 512 kb, no es así? En caso negativo, para que son esos 512 kb?
En línea
SapphiRe_MSX
Visitante
« Respuesta #14 : 02 de Febrero de 2014, 10:50:38 am »

Muchas gracias por tu explicación. Creo que al fin he dado con una explicación .
Las pruebas que dices que cambias el color el fondo cuando entras en la interrupción, a nivel de código seria precisamente tras el halt, no es así?

Coooorrecto. La primera instrucción tras el HALT será la primera que se ejecute tras procesar la interrupción. Como supongo que usarás la BIOS, perderás un poco de tiempo, pero bueno, de momento es lo que hay.

Citar
Una pregunta tonta: si pongo dos halt seguidos, con eso conseguiría que el juego vaya a 25 fps en PAL?

Sí, pero no es buena idea. Lo que puedes hacer es actualizar la pantalla uno cada dos frames y tendrías el mismo resultado. PERO la música sí hay que actualizarla cada frame.

Citar
Los juegos comerciales que guardaban datos, llevaban incorporada una memoria flash para tal efecto, o se hacia de otra manera?

En la época no había flash, así que usarían S-RAM.
En línea
Páginas: [1] 2 3 4
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!