La sincronización del refresco vertical y el retardo del input.

Gracias por abrir el nuevo hilo, Recap.

Hipos, haberlos, haylos.

Por lo que puede deducirse viendo el código de Mame, 'syncrefresh' y 'waitvsync' son exactamente la misma cosa, es decir que es indiferente activar uno u otro.

El problema es que Mame sólo hace caso de estas opciones cuando, simultáneamente, activamos 'throttle' (por eso digo que estan "rotas"). Con la opción 'throttle' se activa, básicamente, un bucle de retardo, que tiene como propósito ajustar la velocidad de la emulación a la original de la placa pcb. Para ello, utiliza el reloj de nuestra cpu.

¡Pero nosotros no queremos que esto sea así! Al contrario, nuestro propósito es programar el reloj de la tarjeta gráfica de manera que sea éste el que temporice la emulación. Si 'throttle' está activo, tendremos, en la práctica, dos relojes tratando de temporizar el juego. Por muy bien que los sincronicemos, siempre habrá una pequeña diferencia entre el periodo de ambos. Podrán caminar al unísono durante bastantes frames, pero al cabo de cierto tiempo, uno no podrá alcanzar al otro, y se perderá un frame por el camino.

El problema es más o menos evidente dependiendo del juego y de si la frecuencia efectiva del modeline que hemos calculado está por encima o por debajo de la buscada. En cualquier caso, el problema existe. Y la forma de solventarlo es desactivando 'throttle'.

Por suerte, al contrario que 'syncrefresh' y 'waitvsync', 'triplebuffer' sí que funciona aunque desactivemos 'throttle'. Con esta configuración, Mame sólo hara caso del reloj de nuestra tarjeta de vídeo, y el resultado es que la velocidad de emulación se ajustará automáticamente a la de nuestra tarjeta, obteniendo scrolles perfectos.

Pero aunque visualmente conseguimos la perfección, por desgracia trasladamos el problema al audio, que sigue tratando de mantener la velocidad original. Si utilizamos modelines bien calculados, normalmente esto no se nota, ya que la diferencia es muy pequeña. Pero no siempre podremos obtener un modeline que reproduzca la velocidad original, debido a la limitación que impone nuestro monitor. El caso típico es el de los juegos verticales rotados, que tengan más de 240 líneas. En este caso el desfase entre el refresco obtenido, y la velocidad original es muy grande, y los problemas con el audio serán muy molestos.

Para solucionar este problema, SailorSat realizó el célebre parche 'soundsync', que incorpora CabMame. Con 'triplebuffer', 'soundsync' y 'nothrottle' tendríamos pues la combinación ganadora.

Pero, desgraciadamente, 'triplebuffer' parece añadir un tercer problema: input lag (retardo en la respuesta de los controles).

Hasta aquí, este es el resumen de la problemática con las versiones existentes de Mame.

No, no es obra mía, sólo colaboro con algunos de los parches. El creador es Chris Kennedy (bitbytebit), él es el que mantiene el proyecto y programa todo el código. Todo esto ha surgido en los últimos meses alrededor del proyecto Switchres/GroovyArcade/GroovyMame. La información está muy desperdigada principalmente por estos hilos:

http://forum.arcadecontrols.com/index.p … c=107255.0
http://forum.arcadecontrols.com/index.p … c=110905.0
http://forum.arcadecontrols.com/index.p … c=106405.0
http://forum.arcadecontrols.com/index.p … c=107620.0

Luego sigo...

Exacto.

Al desactivar 'throttle', Mame corre a todo lo que da la CPU, pero si activamos 'triplebuffer', la sincronización vertical que incorpora esta opción hace que Mame ajuste de nuevo su velocidad al refresco de la tarjeta gráfica.

Tal como está programado en la versión oficial de Mame, no: 'waitvsync y syncrefresh sólo funcionan si simultáneamente activamos 'throttle'. Permíteme Recap que pegue un fragmento del código de Mame donde se ve a las claras que este comportamiento es parte del diseño:

Basta con eliminar lo que pongo en negrita para devolver el funcionamiento esperable a 'syncrefresh' y 'waitvsync', con o sin 'throttle'. Este es uno de los parches que incorpora GroovyMame.

Puede que simplemente no lo consideren un problema, y prefieren que quien quiera sincronización vertical elija  la ruta de 'triplebuffer'.

En cuanto tenga tiempo iré ampliando el tema. Por cierto, gracias por el artículo, muy recomendable, y aclara ciertas cuestiones que enlazan con esto.

Sí, hay ejecutables para Windows y Linux:

http://mario.groovy.org/GroovyMame/

Como dices, la opción -soundsync funciona en cualquier situación en la que exista desfase entre la velocidad original y la emulada, independientemente de la opción de sincrozación de vídeo que se utilice. Su funcionamiento es bastante rudimentario, básicamente consiste en aplicar un coeficiente a la frecuencia de muestreo del buffer de audio, calculado como velocidad-real/velocidad-emulada, que se actualiza constantemente.

Respecto a tus pruebas con MAME UI FX 0.136, parece que en los dos casos que comentas estaríamos tan cerca del refresco original (el error es de centésimas de Hz) que el problema no llega a manifestarse porque el desfase es absorbido. He revisado los parches de MAME UI FX y no actúan sobre las opciones de sincronización, por lo que descarto que en ese aspecto sea "mejor" que la versión normal. De todos modos, el dato correcto de refresco de un modo de vídeo debes obtenerlo mediante la medición que realiza Arcade_OSD el pulsar "5", en vez de usar el valor que aparece en ModeList.txt, especialmente si ya no utilizas la R9250 (en ese caso sí que son prácticamente coincidentes dado que medí uno por uno los valores reales de 'dotclock' de esa tarjeta).

A poco que te alejes de los valores originales de refresco vertical, empezarán a aparecer los problemas de hipos, pero paradójicamente, sólo si la frecuencia obtenida es mayor que la original. Esto se sabe desde hace tiempo, y de hecho, en cierto punto los modelines de la AVGA se rectificaron para que su refresco fuera ligeramente menor de 60Hz, para evitar hipos en el scroll de la mayoría de los juegos. Luego intentaré explicar por qué esto es así.

No obstante lo deseable sería que -syncrefresh ajustase la acción del juego a la frecuencia de la tarjeta de vídeo cualquiera que ésta fuera, porque no siempre podemos contar con obtener una aproximación tan buena como la de tu ejemplo, y al final hay muchos casos especiales a los que dar respuesta.

Lo que pongo a continuación es un comentario extraído del propio código de Mame, donde se explica en que consiste el mecanismo de "throttling" que implementa el emulador:

Supongamos, para simplicar las cosas, que Mame es capaz de emular un ciclo completo en un intervalo de tiempo despreciable. Esto es: procesar el "input", emular el hardware y generar un nuevo frame, todo, en un instante. El resto del tiempo disponible tendremos que esperar, si no queremos que nuestro fps se dispare hasta el infinito.

Esta es la diferencia principal entre la emulación en general, donde normalmente tenemos que respetar el valor fps fijo, y los juegos 3D en tiempo real, donde el valor fps es arbitrario y sólo limitado por la potencia de la CPU/GPU, que es el enfoque que se explica en el artículo sobre triplebuffering que enlazaste al principio del hilo.

Para entender mejor cómo se organiza esto aquí va un esquema de la rutina que ejecuta Mame cada vez que tiene listo un frame:

Lo primero que llama la atención es que el retardo (update_throttle) se ejecuta antes de que Mame muestre el frame, lo cual no parece lógico, aunque como veremos tiene poca o nula repercusión en la práctica.

El hecho de tener dos retardos no significa que ambos se lleguen a producir íntegramente. Lo que realmente ocurre es que, transcurridos unos cuantos ciclos, la suma de los dos retardos (throttle + waitvsync) tiende a ser constante, de forma que throttle se autoregula esperando sólamente el tiempo necesario para conseguir la velocidad deseada.

Consideremos primero el caso en que el refresco de la tarjeta de vídeo sea menor que el refresco original. Esto significa que el intervalo de tiempo empleado en m_machine.osd().update, esto es, esperando el blanking vertical, es mayor que el intervalo original del juego. Por tanto, tras unos pocos ciclos, update_throttle detectará que vamos más despacio que la velocidad original, por tanto cada llamada a update_throttle retornará inmediatamente sin esperar, realizándose sólo la espera propia a waitvsync dentro de m_machine.osd().update. Esto hace que la velocidad de emulación se ajuste a la velocidad de refresco impuesta por la tarjeta gráfica, resultando en un scroll perfecto.

Ahora consideremos el caso en que el refresco de la tarjeta de vídeo es mayor que el refresco original. Ahora, el tiempo empleado esperando al blaking vertical es inferior al intervalo total de retardo que necesitamos para mantener el valor de fps original. Por tanto, update_throttle detectará que vamos más deprisa, y por tanto intentará compensar este desfase con una espera adicional. Por otra parte, el blanking vertical es una breve ventana temporal que se produce en intervalos perfectamente regulares, y que hemos de aprovechar para escribir en el buffer de vídeo. El problema viene porque el pequeño retardo añadido por update_throttle, se va acumulando tras varios frames, hasta que llega un momento en que llegamos demasiado tarde para entrar en el blanking que nos tocaba, y tenemos que esperar al siguiente, lo que visualmente se traduce en un hipo de scroll imposible de ignorar.

Resulta evidente pues que la única forma de conseguir la sincronización perfecta en ambas situaciones es desactivar manualmente el mecanismo de throttling. El problema, como hemos comentado otras veces, es que al hacer esto, Mame interpreta que queremos que funcione a toda velocidad, por lo que ignora el retardo waitvsync. Esto es lo que corregimos en GroovyMame.

Eso es, exacto.

No, el generador de modelines busca la mejor aproximación, quede ésta por encima o por debajo del valor buscado. En cierto momento sí me planteé el poner una opción para obtener la mejor aproximación "por debajo", pero pienso que en la práctica es mejor reparar Mame para no tener que preocuparse por esto.

La razón principal es que no es tan sencillo conocer a priori el refresco real obtenido con una precisión tal como para poder tomar decisiones sobre él, salvo en el caso de la R9250*, como comentaba, pues para esta tarjeta sí que me tome el trabajo de medir uno por uno los resultados para cada valor de dotclock introducido.

* Realmente no depende tanto de la tarjeta sino del algoritmo que utilicen los drivers para programar los PLLs de cierta familia de hardware, es decir que los valores que obtuve para la R9250 también son validos para otras tarjetas soportadas por los mismos drivers, como la X300, aunque probablemente sean diferentes de los modelos más nuevos, como las HD que tienen AtomBIOS. Ya hablaremos de este tema, que tiene miga.

De todos modos, era necesario introducir el funcionamiento del mecanismo de "throttling" que implementa Mame para tratar de explicar más adelante cuáles son las posibles causas de "input lag" que pueden producirse como resultado de la sincronización vertical.