No has iniciado sesión. Por favor, inicia sesión o registrate.
Postback » Mensajes hechos por Calamity
Pues sí que es raro. El número de modos que nos interesa es el que aperece aquí entre paréntesis (33):
Puedes probar una cosa para salir de dudas: añadir también las resoluciones desde el ejecutable de Mame, con las opciones ListFromXML y GenerateXML. Esto te generará un montón de resoluciones, por lo que si siguen sin poderse editar desde Arcade_OSD entonces estará claro que es por otra cosa.
La parte del programa que lee el archivo ReslList es una castaña, tengo que actualizar urgentemente eso, dado que si el formato de la resolución no es exactamente el que tiene que ser, aunque sea por un solo espacio, no lee correctamente los datos.
Es raro, además es que estoy bastante seguro porque he pasado por esos mismos problemas este verano, haciendo pruebas con un CRT SVGA que tengo aquí.
Por cierto para ver los cambios sí es necesario pulsar "Test" (P1 o Enter).
En cualquier caso, y si se resiste a funcionar, pulsando "Save changes" y reiniciando podrás ver los cambios, aunque es un rollo hacerlo así.
No sé qué estoy haciendo mal pero al variar los valores front/back porch desde Arcade OSD con los cursores no obtengo ningún cambio -- ni pulsando "test", ni guardando los nuevos valores para el modo y saliendo... He seguido paso a paso tus instrucciones, eso es seguro.
Bien, creo que sé lo que pasa.
Resulta que para que funcione la edición dinámica de modelines (esto es: sin reiniciar el equipo) tiene que haber definidos un mínimo de 17 modos de vídeo personalizados. Además, sólo cuentan aquellos que Windows no oculta normalmente. En tu caso, tienes un total de 24, pero seguramente si le restas los que con la versión anterior de Arcade_OSD quedaban ocultos, el total será menor de 17.
Sé que todo esto es un poco cabalístico, de hecho no sé por qué ocurre, ya que esta edición dinámica de modelines es una propiedad no documentada de los drivers de ATI, que debemos aceptar como un regalo de los dioses.
Por tanto lo que tienes que hacer es añadir más resoluciones a ReslList.txt, si es posible en la franja que tu monitor acepta normalmente (480 líneas), de manera que la lista total de resoluciones disponibles (visibles con la versión anterior de Arcade_OSD, índice entre paréntesis) sea mayor de 17. Puedes utilizar resoluciones de relleno si quieres.
Esto no será un problema cuando incorporemos la lista de resoluciones para emulación que estuvimos comentando, porque con toda seguridad superaremos esa cifra.
Sigo con el problema del centeado de la imagen, por otro lado, y no es algo que se arregle completamente con el OSD [del monitor]. Es difícil de explicar, pero lo intento, aunque creo que te lo imaginas: el límite físico de la imagen no coincide con el límite [visible] de la pantalla si encojemos la imagen lo necesario para verla completamente, dejando un margen negro. Es decir -- si variamos el posicionamiento hztal., la imagen se nos empieza a ocultar antes de llegar al límite visible de la pantalla. Me pongo pesado porque estoy con el monitor que Eboshidori recomendaba aquí [ > ], por lo que creo que es interesante para más de uno que siga este Foro.
Vale, está claro. Ese problema es típico cuando el ancho del vídeo activo es excesivo. Para reducir el vídeo activo tienes que aumentar los márgenes. Yo lo que haría es encoger la imagen desde el OSD del monitor, usando el ajuste de amplitud horizontal, para tener bordes negros a ambos lados, es decir, que veas el haz completo. Luego pon el control de centrado del OSD en la posición central (normalmente 50). Entonces fíjate por que lado se sale más la imagen, y desde Arcade_OSD/Geometría horizontal vas aumentando los valores de front/back porch para los lados derecho/izquierdo respectivamente, hasta que consigas que la imagen quede dentro por ambas lados. Finalmente desde el OSD del monitor vuelves a regular la amplitud para que la imagen cubra la pantalla.
Pues bien, si consigues esto, en el propio menú de geometría horizontal del modo que hayas ajustado tienes los valores de front/back porch en microsegundos, que son los que tienes que copiar tal cual a la línea monitor_specs:
monitor_specs_0 = "30000-95000, 50-150, 0.320, 0.950, 1.500, 0.011, 0.032, 0.491, 0, 0, 1200, 768"
Es conveniente que no apures mucho y dejes algo de holgura en los márgenes desde Arcade_OSD, luego puedes corregirlo desde el OSD del monitor. Esto es porque VMMaker permite una tolerancia a la baja de 0.20 microsegundos que resulta ser excesiva para monitores VGA (estaba pensada para monitores arcade), es algo que tengo que corregir en la próxima versión.
Lo que sí he logrado es que el modo 640 x 480 x 60 me saque, según Arcade OSD, 60.0009 Hz. ¿Crees que es debido a la nueva versión del visualizador, a la nueva línea CUSTOM o es más bien porque añadí en ReslList una entrada tal que 640 x 480 a 60.10 Hz (que también se ha generado). Esto sí me parece una cuestión más importante, por su carácter general.
Es debido a la nueva línea custom, al variar los márgenes el resultado de la temporización del modo de vídeo siempre varía algo. En este caso parece que a ese modo concreto le favorece.
Creo que WinX68k utiliza DirectDraw.
De todos modos hay una solución para todo esto que es crear un "EDID override". Esto es un parche por software para el EDID del monitor, que básicamente le dice a Windows que nuestro monitor sí puede mostrar esos modos. Por desgracia todavía no he podido ponerme a explorar esta vía pero todo llegará.
Los modos de 384, 400, 512 líneas etc. no son ningún problema. La pega estaría meterle al monitor una frecuencia fuera de rango, como esos modos de 200 Hz que aparecen cuando desbloqueamos las opciones de seguridad que comentábamos. En principio no debería pasar nada porque los monitores llevan sus filtros y demás, pero ¿y si pasa? Pues eso.
Una cosa más:
Para complicarlo todo un poco, las resoluciones que queden visibles con este método, sólo serán accesibles mediante DirectDraw!
Para Direct3D, estas resoluciones seguirán siendo inaccesibles.
Esto no es un problema en Mame, en donde podemos seleccionar qué API de vídeo usar. Pero los emuladores que sólo funcionen sobre Direct3D no podrán utilizar estos modos de vídeo.
Más información sobre esto aquí:
Bien, es lo que suponía, Windows está ocultando las resoluciones que entiende que tu monitor no puede mostrar. Además, la versión de Arcade_OSD que colgué sólo lista las resoluciones permitidas por Windows, por razones de seguridad.
Para ver todas las resoluciones, debes hacer esto:
- Propiedades de Pantalla/Configuración/Opciones avanzadas/Monitor, desmarca la opción "Ocultar los modos que este monitor no puede mostrar".
- Utiliza está versión de Arcade_OSD, que muestra todos los modos sin excepción: http://www.megaupload.com/?d=HXPX9MIZ
(mucho ojo, activando modos que estén objetivamente fuera de rango podemos averiar el monitor)
Con los modos de 512 líneas no hay problema ninguno, solo que Windows los oculta por precaución.
Respecto al centrado, puedes probar reduciendo algo el front porch y sync pulse a los valores originales (realmente les di algo de margen por seguridad):
monitor_specs_0 = "30000-95000, 50-150, 0.320, 0.950, 1.500, 0.011, 0.032, 0.491, 0, 0, 1200, 768"
Si con estos valores la imagen sigue descentrada, puedes hacer dos cosas:
- Tratar de centrarla con el OSD del monitor. Si lo consigues, entonces se quedará memorizada. Normalmente tendrás que repetir el centrado para cada altura distinta, es decir: 480, 512, etc., no para cada resolución, lo cual es un alivio.
- Tratar de centrarla por software con Arcade_OSD. Si lo consigues, utiliza entonces los valores que te devuelve el programa como valores de entrada en la línea monitor_specs
Sobre mejorar la precisión de los 60 Hz, en efecto la única vía posible es la que comenté en ese hilo.
Actualizados los drivers basados en Catalyst 9.3, para dar soporte a la HD 4890, la tarjeta más potente soportada hasta el momento.
Estoy de vuelta.
Veo que lamentablemente con las prisas metí la pata en la línea que te pasé, la he corregido y editado para que también genere modos de 384 líneas:
monitor_specs_0 = "30000-95000, 50-150, 0.400, 1.000, 1.500, 0.011, 0.032, 0.491, 0, 0, 1200, 768"
La he probado aquí y funciona, al menos genera los modos esperables. He utilizado estos modos en ReslList:
## Recap ##
496 x 400 @ 57.000000 prueba
640 x 480 @ 50.000000 prueba
640 x 480 @ 55.450000 prueba
512 x 512 @ 55.450000 prueba
512 x 384 @ 60.000000 prueba... y me genera estos modelines:
Modeline "496x400_57 30.09KHz 57.09Hz" 16.350 496 504 520 544 400 456 457 527 -hsync -vsync
Modeline "512x384_60 30.00KHz 60.00Hz" 16.830 512 520 536 560 384 434 435 500 -hsync -vsync
Modeline "512x512_55 30.00KHz 55.46Hz" 16.830 512 520 536 560 512 519 520 541 -hsync -vsync
Modeline "640x480_50 29.96KHz 49.94Hz" 21.130 640 648 672 704 480 532 533 600 -hsync -vsync
Modeline "640x480_55 29.96KHz 55.38Hz" 21.130 640 648 672 704 480 503 504 541 -hsync -vsync
Modeline "640x480_60 29.96KHz 59.92Hz" 21.130 640 648 672 704 480 482 483 500 -hsync -vsyncEn tu caso, asegúrate de que estas opciones estén así:
MonitorType = "CUSTOM"
Only32BPPModes = 0
ModeTableMethod = 0
Ahora bien, es posible que Windows esté tomando sus propias decisiones y oculte algunos de los modos para ese monitor. Para evitarlo, entra en Propiedades de Pantalla/Configuración/Opciones avanzadas/Monitor y desmarca la opción "Ocultar los modos que este monitor no puede mostrar".
Recap,
En efecto esa es la información necesaria. Con esos datos y dejando un poco de margen para no ir muy justos podrías utilizar esta línea:
monitor_specs_0 = "30000-95000, 50-150, 1.000, 1.000, 1.500, 0.011, 0.0491, 0., 0, 0, 1200, 800"
¿Qué ocurriría si vía Reslist le decimos que cree un 'modeline' que queda fuera de su rango?
Dependiendo de las circunstancias, el generador de modelines intentará forzar la resolución para que quede dentro de su rango, y si no es posible, la "virtualizará".
Estoy pensando particularmente --y dado que aún no sé realmente el límite inferior del monitor-- en los modos de 24 kHz y las maneras de aproximarnos. Tenemos, por ejemplo, 640 x 400 a 50 Hz que usaban ordenadores como PC88 y FMT. El Mitsubishi parece aceptar 400 líneas horizontales, pero supongo que a 50 Hz queda fuera de rango, ¿qué pasaría si se "generara"?
En un caso así, parece obvio buscar el mínimo valor de la res. vertical que permita el refresco original en nuestro monitor, pero ¿cómo dar con él para generarlo vía Reslist?
Si te fijas en el último valor de la línea que he puesto (800), pues bien, el generador de modos tomará como resolución mínima por defecto ese valor partido por 2, es decir, en este caso 400 líneas.
Por tanto esas resoluciones de 400 líneas a 50 Hz sí que son posibles para ese monitor.
Por debajo de las 400 líneas, el generador intentará escalar la resolución x2, x3, etc. Es decir, que 384 líneas pasarían a ser 768.
Si aun así modificamos el último valor de 800 a 768, entonces sí que intentará generar las 384 líneas sin escalar, pero si al calcular la frecuencia horizontal se queda ésta por debajo de lo permitido, el generador meterá líneas de relleno en los márgenes superior e inferior para compensar.
Asegúrate de utilizar la versión actualizada de VMMaker (es de hoy):
http://www.megaupload.com/?d=HO481JYE
Estaré fuera una semana, a la vuelta podré ver esto con más tiempo.
Saludos
Por partes,
En efecto, basta con que selecciones MonitorType = "VGA" para que todos los modelines se recalculen a 31 KHz. No te preocupes, los valores por defecto son bastante conservadores. Lo que ocurre es que ésta es una configuración, digamos, estándar, por lo que es posible que tengas muchos márgenes o la imagen algo descentrada.
Esos tipos de monitor predefinidos llevan inplícitos uno o más rangos de frecuencia, dependiendo de que el monitor sea o no multifrecuencia. Si no nos apaña ninguno de ellos, lo que hacemos es crearnos nuestro propio tipo "CUSTOM", con sus rangos correspondientes. Por ejemplo, para unas pruebas que estoy haciendo con un monitor LG de 15", estoy usando estos valores:
monitor_specs_0 = "29000-32000, 50-160, 0.549, 0.412, 3.570, 0.014, 0.044, 0.524, 0, 0, 576, 768"
monitor_specs_1 = "32000-70000, 50-160, 0.549, 0.412, 3.570, 0.014, 0.044, 0.524, 0, 0, 1024, 1024"
A los valores del final les llamamos 'active lines limit' y 'virtual lines limit', y su misión es indicarle al generador de modelines cuáles son los límites para usar el entrelazado. Ya explicaré esto con más detalle.
Lo que no puede concurrir simultáneamente en el sistema son dos modelines con la misma etiqueta, por ejemplo: 640x480@60. Realmente, lo que el sistema 've' son las etiquetas, por tanto sólo puede existir un modo llamado 640x480@60. Luego el driver asigna un único modeline por cada etiqueta. Por tanto tenemos que elegir un modeline progresivo o entrelazado. Lo que sí podemos hacer es tener dos etiquetas definidas así:
640x480@60 -> modeline entrelazado (15Khz)
640x480@61 -> modeline progresivo (31Khz)
Además, el modeline del segundo modo, podemos calcularlo para 60 Hz aunque la etiqueta diga otra cosa. El sistema no notará la diferencia porque no sabe nada de modelines. De todos modos esto no puede hacerse con el generador tal cual, quizá en el futuro.
Hay un programita llamado MonInfo, que permite extraer la información del EDID del monitor:
http://www.entechtaiwan.com/util/moninfo.shtm
Lo bueno del EDID es que le devuelve al sistema un 'modeline patrón' (a veces varios), por tanto podemos utilizarlo para extraer los valores con los que el monitor se encuentra cómodo, y construir una línea monitor_specs para generar cualquier modeline que necesitemos a partir de esos valores.
Los modos nativos de 31 KHz del driver siguen siendo funcionales (800x600, 1024x768, etc.), por tanto pueden usarse con un monitor VGA sin necesidad de definir ningún modeline adicional (modo "custom") de 31 Khz.
Para generar modelines a diferentes frecuencias (15/25/31Khz, etc.) lo que hacemos es definir los rangos que soporta nuestro monitor, de esta forma el generador de modelines escogerá el rango óptimo en el que calcular el modeline.
Es decir, que desde ReslList no podemos indicarle al generador que calcule un modeline a 31 Khz, sino que eso lo decide el generador en función de los rangos que definimos para el monitor.
Esto es así por razones prácticas, de todos modos cuando tenga lista la versión con interfaz gráfico quizá sí que sea posible mayor flexibilidad.
¿Esto solventaría automáticamente, por ejemplo, el supuesto problema de aproximación que tengo ahora con el 'modeline' de SFC? O preguntado de otro modo, ¿conllevaría que los 'modelines', en general, quedasen aún más próximos a los buscados o simplemente valdría para evitarnos probar uno a uno cada modo?
Esto lo que permitiría es que VMMaker generase el refresco más aproximado del que tu tarjeta es capaz. Ahora mismo lo hace para la R9250, por eso digo que está optimizado para esta tarjeta. Eso no significa que la precisión final sea mayor: lo será en algunos casos, en otros será la misma. Lo que quiere decir es que los valores de cálculo que aparecen en ModeList.txt coincidirán prácticamente con los valores reales que midas en Arcade_OSD.
En cualquier caso, si tanteas ahora con Arcade_OSD, quizá obtengas un valor más aproximado. Pues bien, si VMMaker contara con los valores reales de dotclock de la HD4350, llegaría automáticamente al mismo valor que tú sin necesidad de reajuste posterior.
¿El inmediatamente superior al buscado, quieres decir? ¿No era mejor escoger siempre el inmediatamente inferior (salvo que la diferencia sea enorme, imagino)?
Me refería al caso concreto del modeline para la SFC, que me comentabas que se queda por debajo, por eso decía que el valor óptimo, si no era ése ya, sería como mucho el inmediato superior.
Rescato de otro hilo el tema de conocer la frecuencia vertical exacta en cada 'modeline' con Arcade OSD. Por lo que he entendido, los valores que el visualizador muestra en la tabla son solo reales si usamos una Arcade VGA / Radeon 9250, de manera que para conocer el valor en otras tarjetas hay que entrar en el 'modeline' y pulsar '5'. Esto reescribe la tabla del programa, pero veo que los valores obtenidos se pierden al cerrarlo. ¿Sería muy difícil de implementar que se guardasen tras el 'test', o se generase un .TXT que pudiera reemplazar a la tabla de fábrica que usa?
Lo más práctico será implementar un auto-test opcional que pruebe cada valor de dotclock in situ, para generar un archivo análogo al ATI9250.txt para cada tarjeta. La ventaja de esto es que una vez obtenidos los valores, VMMaker puede utilizarlos para obtener los refrescos exactos (para *prever* los refrescos exactos, mejor dicho). La pega es que el auto-test dura unas cuantas horas.
Al hilo de esto, me doy cuenta ahora de que el 'modeline' para Super Famicom con la HD-4350 queda sorprendentemente poco ajustado --comparativamente hablando--, tras editar Reslist para 256 x 224 x 60.098475521. El valor más cercano que me genera es de 60.008 Hz. ¿Te ocurre igual?
La verdad es que ahora no puedo probar la HD-4350 porque tuve que instalar de nuevo la 9250 para probar los drivers 6.5 para XP-64.
Puedes tratar de ajustar mejor ese modo yendo a "Edit modeline", y dentro desactivar "Vfreq_lock", y probar a subir un punto el valor "Dotclock", luego pulsa P1 para probar el modo y 5 para calcular el nuevo refresco.
Quizá VMMaker no haya obtenido el mejor valor para tu tarjeta, y manualmente lo encuentres (será el inmediatamente superior en todo caso). Verás que con cada valor de dotclock tendrás un salto en el refresco vertical. Esos son los valores que el hardware de tu tarjeta es capaz de obtener. Esta naturaleza granular del dotclock es más evidente en los modos de baja resolución (como 256x224).
Puedes conseguir mejores aproximaciones utilizando la opción "Iterations" de VMMaker. Esto prueba hasta cinco combinaciones con distinto número total de líneas (márgenes, las líneas visibles no varían) y normalmente obtiene valores más aproximados de refresco vertical. La pega es que aumenta la disparidad de valores de frecuencia horizontal, razón por lo que por defecto está desactivado. De todos modos, los valores que utiliza como referencia siguen siendo los de la R9250, por tanto tampoco es garantía de obtener mejores resultados en el caso de la HD4350.
Entiendo entonces que con un MAME con el Throttle arreglado es indiferente si el refresco de nuestro equipo es superior o inferior al del 'hardware' original, pero con un MAME estándar es mejor que sea inferior, si bien, si las discrepancias son de centésimas de Hz, en la práctica tampoco se nota. ¿?
Eso es, exacto.
¿Realiza Video Mode Maker la configuración de los INI atendiendo a este condicionante?
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.
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:
\src\emu\video.c
Throttling theory:
This routine is called periodically with an up-to-date emulated time.
The idea is to synchronize real time with emulated time. We do this
by "throttling", or waiting for real time to catch up with emulated
time.In an ideal world, it will take less real time to emulate and render
each frame than the emulated time, so we need to slow things down to
get both times in sync.There are many complications to this model:
* some games run too slow, so each frame we get further and
further behind real time; our only choice here is to not
throttle* some games have very uneven frame rates; one frame will take
a long time to emulate, and the next frame may be very fast* we run on top of multitasking OSes; sometimes execution time
is taken away from us, and this means we may not get enough
time to emulate one frame* we may be paused, and emulated time may not be marching
forward* emulated time could jump due to resetting the machine or
restoring from a saved state
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:
video_manager::frame_update
{
.
.
.
update_throttle -> aquí se produce el primer retardo, mientras esperamos que transcurran tantos ciclos del reloj-CPU como sean necesarios para sincronizar el tiempo-real con el tiempo-emulado.
.
.
.
m_machine.osd().update -> aquí se produce el segundo retardo, mientras esperamos al inicio del 'blanking' vertical para dibujar mostrar el nuevo 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.
Por supuesto pueden generarse modos progresivos de 512 líneas. Creo que no lo he probado directamente, de todos modos próximamente quiero darle un empujón al tema para añadir soporte multi-monitor y aprovecharé para probar todo esto. Por soporte multi-monitor me refiero a poder instalar y probar modos de vídeo en el dispositivo primario y secundario indistintamente.
¿A qué te refieres con "probar uno por uno"? Es lo que preguntaba -- si MAME te dice en algún lado los 'modelines' en su totalidad o cuál es la manera de conocerlos.
Mame nos da una información sobre cada juego en formato xml, usando el comando -listxml, por ejemplo:
mame 1942 -listxml
...nos daría todos los datos relevantes sobre el juego 1942. Esta es la misma información que aparece en MAWS, y que utilizan los frontends o MameUI para decirnos las "propiedades" del juego, y es todo lo que hay disponible a nivel de usuario.
El problema es que esta información es incompleta para los juegos que usan varias resoluciones, dado que la base de datos está diseñada para almacenar un sólo campo de resolución por juego, normalmente la primera que se usa.
Para conocer a priori todas las resoluciones que usa un juego, habría que ir al código fuente del driver de dicho juego y estudiarlo.
Como no podía estar seguro, desinstalé e instalé el de enlace. Aparentemente son exactamente iguales, pero lo cierto es que ahora me reconoce la res. del escritorio y he podido hacer el cambio con el modo de vista básica. Esto me ha permitido visualizar la vista avanzada en toda su extensión y crear atajos de teclado, por tanto, problema resuelto. Muchas gracias.
Estupendo. Voy a añadir los enlaces a cada versión de correcta de CCC al post inicial.
¿Y cuál sería la manera de conocer el 'modeline' post-arranque en estos casos? Deduzco que la documentación a nivel usuario de MAME solo define el de arranque, y, por tanto, para los que usamos MAME convencionales y tenemos que configurar manualmente, no nos vale.
La única opción es conocerlo a priori para cada juego, probando uno por uno, y crear un .ini manualmente, y aun así esto no es válido para los juegos que cambian más de una vez de resolución.
Entiendo que entiendes bien. No he conseguido encontrar la verificación, pero es el del CD que viene con la tarjeta. Y no se parece en nada al ATI Control Panel apto para la Arcade VGA.
Si has usado el CCC del CD lo más probable es que se trate de versión posterior a la 9.3, habría usar el CCC de esta página, ("Option 2 - Individual Downloads"):
http://support.amd.com/us/gpudownload/w … ng=English
(sólo por si acaso, si es la misma versión que tienes instalada ignóralo).
Con respecto a los juegos de System 32, si es solo el arranque, no parece que merezca mucho la pena preocuparse por ellos en lo de cambiar dinámicamente el modo. El C-2 de Sega estaba basado en Mega Drive, que, en efecto, contempla esos dos modos. Aunque la mayoría de los juegos emplean 320 x 224, muchos cambian puntualmente a 256 x 224. Ya lo hablaremos al abrir el hilo de la emulación de MD.
El problema es que la única información que podemos conocer a priori es la que nos proporciona Mame sobre el juego en formato xml, y en estos casos sólo nos reporta una resolución, que desgraciadamente no es la que se usa principalmente durante el juego. En el caso de system32, por ejemplo, si hacemos caso a Mame generaríamos la resolución de 416x224, por lo que durante el juego tendríamos bordes negros a cada lado. El caso de segac2 es peor, porque la resolución que reporta mame es 256x224. Si nos fiamos de Mame, tendremos todo el juego cortado a izquierda y derecha. Por eso es una ventaja incluir el generador de modelines dentro de Mame, porque así capturamos todas las solicitudes de cambio de modo de vídeo, sea el que sea, y generamos las resoluciones necesarias sobre la marcha.
De todos modos, no es la parte que más me interesa de Groovy MAME personalmente, al contrario que el parche para corregir las opciones de sincronización. ¿Crees que yo mismo --que no tengo ni idea-- podría añadírselo al código de 32-FX, por ejemplo? El autor parece que se ha retirado indefinidamente.
(Una pena que no queráis hacer una interfaz para GM, por cierto. Se me escapa cómo podéis manejaros con línea de comandos. Va a suponer una barrera enorme para el usuario medio.)
Si no tienes experiencia en C++ es improbable conseguirlo, pero a mí no me costaría mucho añadir esas opciones de sincronización sobre el parche del 32-FX. El tema de generación de modelines ya es otra historia porque influye mucho la versión de Mame y todos los parches se han desarrollado para v0.141/142, mientras que las opciones de sincronización están en una parte del código que no ha variado prácticamente desde la v0.107.
Con 512 líneas tampoco hay suerte. En todo caso, parece que hay ciertos problemas de entendimiento entre el CCC y tu 'driver', porque al intentar cambiar valores de resolución sale en blanco. El CCC tiene un modo básico de configuración, apto para 480 líneas, que no te permite rotar escritorio por no reconocer la resolución del mismo, incluso en 640 x 480 x 60.00.
Ya veo, pues tendré que comprobar esto (entiendo que estás usando el CCC 9.3).
¿En qué momento cambia The Revenge of the Death Adder de resolución? ¿Hay otros uegos de System 32 que lo hagan?
El juego al arrancar reporta como resolución 416x224, pero justo cuando aparecen las llamas de fondo, entonces es 320x224 y así es durante todo el juego. Esto ocurre con todos los juegos de system32 que he probado. En segac2 tenemos el problema inverso, reportan 256x224 pero el juego cambia a 320x224.
¿Crees que el autor implementará una versión con interfaz, si se le pide? Podría convencer al autor de MAME UI 32-FX de que acogiera los parches, de todos modos. Es uno de los que se queja por los problemas de 'v-synch' del MAME oficial.
No creo que Chris lo haga porque la prioridad es mantener los parches lo más sencillos posibles e independientes de la plataforma para que sirvan en Windows y Linux. Lo ideal sería que otros 'mods' de Mame adoptaran algunos de los parches, por ejemplo la nueva implementación de -syncrefresh y -triplebuffer son parches muy sencillos de portar. La parte más compleja es el generador de modelines, y aun así con algo de esfuerzo podría portarse.
Puedes poner una resolución de 512i líneas para el escritorio, yo lo tengo así, viene bien para trastear con menús y demás. No sé si será suficiente. De todos modos me interesa este tema, creo que instalaré el CCC para ver qué modifica exactamente en el registro para rotar el monitor, y quizá pueda implementarlo en Arcade_OSD para facilitar las cosas.
Respecto a GroovyMame, efectivamente permite que el juego cambie de modo de vídeo y regenera el modeline cada vez. Esto es necesario para muchos juegos de Sega (ga2, tantr, etc.) y otros sistemas. Ciertamente no cuenta con interfaz, salvo el menú que viene por defecto en las nuevas versiones de Mame. No obstante los parches podrían trasladarse a otros "mods" de Mame en un futuro. De todos modos me he acostumbrado a usar Mame desde línea de comandos y es una liberación, aunque lógicamente en la recreativa utilizo un frontend (AdvanceMenu).
La versión multisync que comentas, realmente hace referencia a la capacidad del generador de modelines VMMaker, para trabajar simultáneamente con varios rangos de frecuencia independientes. Esto es posible a partir de la versión 1.3.
En cuanto a los drivers en sí, son los mismos, es decir que lo que cambia es VMMaker, y si coges la versión 1.3 podrás usarla con los drivers anteriores sin problema. Tendré que aclarar todo este lío de las versiones en algún momento.
La capacidad de usar modos de 31 kHz está siempre presente de forma nativa en los drivers, y de hecho habría que desactivarla a propósito, cosa que ya no hago pese a que hay gente que lo preferiría. Por tanto siempre pueden usarse estos modos si tenemos conectado el monitor adecuado, lo que viene muy bien durante la instalación, etc.
No obtante, estos modos nativos vienen con sus márgenes y timing preestablecidos, por tanto no son muy útiles para la emulación. Lo interesante, y aquí es donde entra VMMaker 1.3, es generar modelines a distintas frecuencias, de forma que puedas disponer simultáneamente de modos a 15, 25 y 31 kHz. Pero estos modos generados por VMMaker, a diferencia de los nativos, aparecen en Arcade_OSD como modos "custom", que pueden ser editados por el usuario.
Lo que sigue no lo he probado, por las limitaciones de espacio y de hardware que tengo. Pero debe de ser perfectamente posible tener dos CRTs conectados simultáneamente, a cada una de las dos salidas VGA/DVI. En principio Mame permite utilizar indistintamente ambos monitores, por lo que podría configurarse para lanzase cada juego al monitor que queramos, activando modelines de 15/25/31 KHz según el caso. Otros emuladores no son tan versátiles y posiblemente haría falta trastear más. La única pega probablemente sea el engorro de activar cada vez la salida del monitor que no tenga EDID, pero éste es otro tema.
Respecto al panel de control, puedes instalarlo sin problemas, simplemente busca el de la versión 9.3 para que no tengas problemas de compatibilidad. Mientras sólo modifiques temas no relativos a las resoluciones personalizadas, no creo que tengas ningún problema. La descarga de la suite de ATI normalmente incluye drivers + CCC, yo lo que hago es ejecutar el archivo y cancelar la instalación. De esa forma en C:\ATI\Support deberían aparecer las carpetas para instalar cada cosa por separado.
Ya somos dos que nos hemos quedado sin monitor multifrecuencia, aunque no pierdo la esperanza.
Lovely. One thing you never find mentioned is that La Abadía is one of the few CPC games which didn't use the system's awful line-doubled presentation. They needed to sacrifice the number of possible on-screen colors, but still, it makes you lament that every other dev didn't take notes.
Yeah, they just used mode 0 (16 colors) for the intro screen, which was good, the rest of the game used colors but double resolution , so the detail was great... today it seems funny, but at the time those screenshots printed in game magazines were really impressive.
I suppose CPC game devs wanted to benefit from it's 16 colors mode at pixel level, compared to its direct competitor, the Spectrum's graphic mode, that had a slightly higher resolution with 15 colors but only selectable at character level, which led to the typical Spectrum-like graphics.
This brings to my mind that we don't know your gaming preferences, Calamity. Which are currently your favorite genres / titles, if you feel like sharing?
Actually I stopped playing games at all at early 90's, and just recently got an arcade cab and started getting back to it to make up for lost time. Actually my beloved gaming platform was the Sega Megadrive, being the ThunderForce saga the games I most enjoyed, and some other rare ones that I loved like Jewel Master and Ecco the Dolphin.
Today, my favourite games are 2D vertical shooters, the ones without pre-rendered 3D sprites which I mostly hate. But I'm kind of new to this and I'm planning to enjoy each individual title as if they were old bottles of wine. However, I still need to mount one of my two cabs monitor as vertical, which will do one of these days.
At the time of the Spanish 8-bits era, I specially enjoyed Opera games: La Abadía, Livingstone Supongo, Goody, by this order. I never liked Dynamic games too much, with some exceptions: Freddy Hardest, Phantis, Game Over. I didn't play Topo games at all.
From earlier Opera games I liked their originality and technical quality. Later, I think they tried to be more like Dynamic games, and they lacked their former originality and freshness. Specially when they started introducing horizontal scrolling. Scrolling in 8-bit games, even for 16-bit IBM-PC compatible systems conversions, was crap. Those machines weren't able to do a pixel by pixel scrolling at real-time, it had to be in blocks of 4-pixels, let alone do a full screen scrolling. So for me, it was much nicer to see Goody instatly switching from one screen to the next, with those big graphics, than Army Moves scrolling in a small box.
La Abadía del Crimen is a different case, if you compare it with other popular isometric games it's simply on another dimension. Someone said that the greatness of La Abadía is that they achieved the illusion of being in a real building. In most isometric games, each room looks independent, think of Batman. You memorize the map as a series of rooms in a squence. It's not like that in La Abadía, where you actually have the illusion of being in a real building, even despite its criticized system of "cameras" that switch their angle in each screen. So, characters that exit or are about to enter your current "screen", don't just pop in the view, you see them coming in as they move through the map, so sometimes you see a character that's walking its way through another screen in the map but that due to isometric representation it is indeed visible from your current view. And that is achieved even with non-scrolling graphics, unlike other isometric games like The Great Escape that implemented scrolling but their graphics have that "scenery look" compared to the solid and convincing architectural feel reached in La Abadía, that at some point when doing the remake made me believe there was actually a sort of 3D model of the building inside the game, which was an illusion of course.
Postback » Mensajes hechos por Calamity
Postback, 2005—2024