jueves, 22 de enero de 2009

ayFX: otra versión más!!!

Buenas:

Pues sí. Tras publicar la última versión le volví a echar un vistazo al código y me di cuenta de que si en un frame resultaba que el volumen del sample era cero (bien porque estuviera así en el sample original o bien porque el ajuste del volumen así lo produjera), los valores del sample sobreescribían a los producidos por el reproductor de música, silenciando el canal.

Lo correcto debería ser detectar esa situación y no sobreescribir los valores, por lo que aquí tenéis la versión 1.11, que arregla esto. Normalmente esto sólo pasaría con la versión que ajusta el volumen, ya que es muy raro que un frame se declare explícitamente con volumen cero, pero con tono o ruido, aunque todo es posible.

De paso, he aprovechado para limpiar un poco el código eliminando la variable ayFX_PLAYING que ahora no es necesaria porque se consulta ayFX_PRIORITY (antigua ayFX_CURRENT) para ver cuál es la prioridad del sample en reproducción. Si la prioridad tiene el bit 7 activo se asume que no hay sample en reproducción, ya que las prioridades válidas van de 0 a 15. Gracias a eso hay unas cuantas instrucciones innecesarias y parte de la rutina de inicialización (ayFX_SETUP) sirve, además, como la rutina de final de sample (ayFX_END), por lo que las he integrado.

Como siempre, cualquier sugerencia o comentario será siempre bienvenido.

martes, 20 de enero de 2009

Nueva versión del Replayer ayFX

Hola nuevamente:

Tras corregir el bug que había en el replayer y tener unas cuantas charlas al respecto con AR, hice unas pequeñas modificaciones en el código y aquí está la versión 1.1 como resultado. Aunque sería más correcto hablar de versiones, porque son dos diferentes.

La novedad más importante con respecto a la anterior versión es que ahora necesitamos pasar dos parámetros al llamar a ayFX_INIT: en el registro A el número del sample (de 0 a 255) y en el registro C la prioridad con la que dicho sample sonará (de 0 a 15), siendo 0 la prioridad más alta (el sample siempre sonará a menos que haya otro sonando de prioridad 0) y 15 la más baja (sólo sonará el sample si no hay otro sonando).

Bien. Eso es lo que encontraréis en la versión 1.1f, en la que el volumen de los samples es fijo y está marcado por el propio sample. De ahí el nombre "Fixed Volume" y la letra f en el número de versión.

La otra versión incluye una novedad y es que el volumen está directamente controlado por la prioridad del sample. Es decir, un sample con prioridad 0 tiene un volumen relativo de 15 (máximo volumen del PSG) y un sample con prioridad 15 tiene un volumen relativo de 0 (silencio). Esta idea viene de AR, que la resumió en una frase como:

"Los sonidos más cercanos deben sonar más alto que los lejanos y, además,
tienen que tener una prioridad más alta porque deben tapar a los lejanos"

Sin embargo, dado que los volúmenes del PSG no son lineales, es necesario recurrir a una tabla para que se pueda bajar el volumen del sample de forma adecuada. Esto es lo que hace el replayer del PT3: construye esa tabla y así puede bajar y subir el volumen relativo de los samples sin ningún problema. Puesto que ya tenemos esa tabla si usamos el replayer del PT3, es tontería no utilizarla. Por eso, la versión 1.1r ("Relative Volume") hace uso de esta tabla y la busca bajo la etiqueta VT_ (que es la que usa el replayer del PT3).

Si por un casual no usais dicho replayer, no pasa nada, ya que en el directorio de la versión 1.1r encontraréis un fichero de 240 bytes llamado vt.bin, que contiene, precisamente, la tabla ya creada. Bastará con descomentar las líneas correspondientes en ayFX-ROM.asm y ayFX-RAM.asm y todo irá como la seda.

Como siempre, os pido que probéis el software y que mandéis sugerencias y comentarios para poder mejorarlo.

jueves, 15 de enero de 2009

Corregido bug en el Replayer ayFX

Hola a todos:

Pues sí, en el replayer de ayFX que hice hace unos meses hay un bug. Un pequeño bug, un bug tan pequeño tan pequeño que no ha surgido hasta hoy.

Todo ha comenzado con un mensaje por parte de AR (programador del juego D&D, que está anunciado para la MSXDev'08), comentándome que estaba teniendo problemas con algunos samples ayFX al utilizar mi replayer.

Tras intercambiar algunos mensajes localicé el fallo: una simple instrucción que faltaba. Estaba claro que el fallo se presentaba cuando el sample utilizaba ruido, así que me centré en ver qué pasaba al reproducir ruido. Nada surgió por ahí.

El problema venía de más atrás, concretamente al leer el nuevo valor del canal de ruido, ya que el puntero al siguiente frame del stream de sonido no se actualizaba, interpretándose en el siguiente frame el valor del canal de ruido como el byte de control de un frame, lo que desbarajustaba todo.

Tras añadir una simple instrucción inc hl todo ha ido como la seda y ya está disponible la nueva versión del replayer con el bug corregido.

Nuevamente agradecer a AR que se ha pegado con el replayer y me ha permitido localizar el bug. ¡Suerte en la Dev!