Emulación: El LAG de entrada

Archivado
gaula88 está baneado por "saltarse baneo temporal con clon"
El otro día me puse a hacer un experimento que llevaba tiempo con ganas de hacer, y teniéndolo todo listo, procedí a ello.
--Preparé dos pantallacas, una tele LCD y un monitor LCD.
--En la tele conecté la MegaDrive, el conversor de Master System, y el WonderBoy III.
--En el monitor conecté mi Mac Mini Core2Duo con Nvidia, la bestia silenciosa. En esta cosa tengo instalados Mac OSX y Gentoo Linux con un kernel optimizado para mi máquina, soporte de OpenGL y toda la mandanga.
--Cargué el KEGA, el WonderBoy III (tanto en Linux como en OSX) y procedí al lío.

El experimento consitía en pulsar al mismo tiempo el botón de salto, tanto en un mando de PSX con adaptador simple a USB en el Mac Mini, como en la Mega DRive.
El resultado es desalentador: el pobre Wonderboy tarda como medio segundo más en saltar en el emulador que en la MegaDrive. Siempre.

Repetí el experimento con la Super Nintendo real y el BSNES sobre Mac y Linux. Lo mismo, la misma mierda de retardo.

¿Qué opinais? ¿Soluciones?

Como detalle curioso, mencionar que el emulador de Master System para DS, el Apprentice Minus, presenta CERO LAG, esto es, responde extactamente igual que una MegaDrive (corriendo un juego de Master System) real.
Pues creo que ese retardo se debe al adaptador, que tiene que hacer la conversión e interpretación de lo que pones a algo inteligible por el sistema operativo y el driver.

Has probado a hacerlo utilizando el teclado o un pad usb nativo?

Saludos
gaula88 está baneado por "saltarse baneo temporal con clon"
No, no he probado. Pero acabo de ver que el polling rate del USB que viene por defecto en Linux (en OSX no lo sé nime interesa mucho) es de 125Hz, lo que no debería añadir más que un lag de cuatro milisegundos o así.
Esta tarde pruebo, a ver. Es que me dio por hacer el experimento porque notaba yo la respuesta poco óptima en los emuladores...
Curioso experimento, no me había dado por hacerlo. Probaré esta tarde a ver si realmente ocurre, aunque soy jugador habitual del Streets of Rage 2 en mi Xbox (NeoGenesis v21) y no he notado nada raro, igual es problema del tiempo que hace que no juego al original...
gaula88 está baneado por "saltarse baneo temporal con clon"
Pues dale leña y postea resultados; es un tema que me interesa mucho.
¿Tienes el vsync activado?
gaula88 está baneado por "saltarse baneo temporal con clon"
@Wah_Wah: todos mis emuladores usan el backend OpenGL, y en OpenGL por supuesto tengo el vsync activado. Si lo desactivo, tearing al canto, que es peor que comer caca cruda.

En Linux no hay alternativa para que no haya tearing: OpenGL sí o sí. DGA ya no es una opción en el mundo Nvidia porque desapareció de los drivers tiempo ha, y DirectFB...en fin...que no. Que es OpenGL sí o sí, y que sin Vsync chungo cubata.
es sabido que hay adaptadores que dan mas o menos lag...la cuestión es encontrar el que menos de...pero siempre habrá.
Habria que ver como has configurado todo el experimento!

Ver los vsinc si estan activados, o que adaptador usas, incluso probar mas de un adaptador diferente a ver si pasa lo mismo en todos.

Es algo raro! en teoria un emulador de 16 bits lo muve un ordenador de hoy en dia con la punta de la uña!

Yo ando encantado con los emuladores, y el tema del lag no me ha afectado para nada en la jugabilidad.

Si puedes hazte tambien con otro adaptador a ver que pasa.
Hace ya bastante tiempo hicimos en la casa de un amigo el mismo experimento pero con el ZSNES y el Killer Instinct (rom de la versión PAL) en un monitor de pc normal y corriente y en una SNES PAL con su correspondiente cartucho PAL. En el pc teníamos conectado un mando por puerto de impresora (no se cómo se llama ese puerto), el Logic 3 Pc Intruder y lo cierto es que de retardo en la señal de entrada no notamos nada, iba igual en el emu que en la consola. Quizá se deba al adaptador de mandos que has utilizado.
Ciñedonos sólo al emulador:

Ese medio segundo de media es enormeeeeee. Si hay retardo este sólo puede ser por unos pocos milisegundos, imposible de detectar a ojo, se necesitaria equipo electrónico.

Además el retardo de entrada es justamente el menos probable. Existe retardo de salida en gráficos y sobretodo en sonido, pero de entrada es posible, pero poco probable.

Pq? pues pq los juegos sólo compruevan el estada de los pads cada vez que dibujan por pantalla, cada frame; a 50hz esto es cada 20ms. Así que si el retardo por usb (y toda la pesca...) es menor a 20ms (que sin duda lo es) no importa a menos que ambos eventos concidan en el mismo momento (poco probable).

Interesante tema, yo también incluiria los gráficos y el sonido.
gaula88 escribió:@Wah_Wah: todos mis emuladores usan el backend OpenGL, y en OpenGL por supuesto tengo el vsync activado. Si lo desactivo, tearing al canto, que es peor que comer caca cruda.

En Linux no hay alternativa para que no haya tearing: OpenGL sí o sí. DGA ya no es una opción en el mundo Nvidia porque desapareció de los drivers tiempo ha, y DirectFB...en fin...que no. Que es OpenGL sí o sí, y que sin Vsync chungo cubata.


Esta claro que vas a tener tearing sin el vsync ¿Pero tienes el mismo lag con el vsync activado?

¿Has probado el Mednafen para sms o el Gens en megadrive?

Te digo lo del vsync por que recuerdo tener un problema similar con el bsnes y era por el vsync.
gaula88 está baneado por "saltarse baneo temporal con clon"
Solucionado.
Por alguna extraña razón, el alargador USB que estaba usando (un cable de 3 metros) parece ser la causa del LAG, lo cuan en efecto no tiene sentido alguno. Ahora, pulsando el mismo botón al mismo tiempo en una MegaDRive y en el KEGA Fusion de Linux sobre OpenGL se obtiene respuesta al mismo tiempo. Gracias a todos, muchachos.

Ah! Por cierto: el Vsync no tiene por qué introducir retardos de entrada. Eso es cosa del Triple Buffer. El Vsync, si tienes definido y en uso un modo de vídeo exacto al de la máquina original, no tiene que esperar: simplemente hace el refresco al llegar la señal de vsync, son el mismo periodo que en la máquina original, na más, no pinta entre medias y ya, así no hay tearing ni mierdas.

Mednafen, por cierto, si alguien tiene las especificaciones de vídeo de la LYnx y la gameboy original, que me las diga. Se necesitan los modos de video exactos o la cosa va a tirones, como es lógico: este emulador es muy preciso con el timming. Gracias
gaula88 escribió:Solucionado.
Por alguna extraña razón, el alargador USB que estaba usando (un cable de 3 metros) parece ser la causa del LAG, lo cuan en efecto no tiene sentido alguno. Ahora, pulsando el mismo botón al mismo tiempo en una MegaDRive y en el KEGA Fusion de Linux sobre OpenGL se obtiene respuesta al mismo tiempo. Gracias a todos, muchachos.

Ah! Por cierto: el Vsync no tiene por qué introducir retardos de entrada. Eso es cosa del Triple Buffer. El Vsync, si tienes definido y en uso un modo de vídeo exacto al de la máquina original, no tiene que esperar: simplemente hace el refresco al llegar la señal de vsync, son el mismo periodo que en la máquina original, na más, no pinta entre medias y ya, así no hay tearing ni mierdas.

Mednafen, por cierto, si alguien tiene las especificaciones de vídeo de la LYnx y la gameboy original, que me las diga. Se necesitan los modos de video exactos o la cosa va a tirones, como es lógico: este emulador es muy preciso con el timming. Gracias


Si tiene sentido lo del usb, piensa que a más conductor mayor resistencia y más resistencia = retardo en la señal, si el prolongador era de 3 metros más lo que tuviera en si el pad, más el retardo del cable del adaptador más el retardo que introduzca el propio adaptador, el standar usb (no se si el 1.0/1.1 o el 2.0) creo que tenía 5 metros (Sin amplificadores intermedios) como tope para garantizar bien el envío de información.
wah_wah_69 escribió:Si tiene sentido lo del usb, piensa que a más conductor mayor resistencia y más resistencia = retardo en la señal



Eso no es así exactamente: la resistencia NUNCA aumenta el retardo de la señal, eso lo hace la capacidad, no la resistencia. El cable más largo hará que la resistencia aumente y por tanto, disminuye la corriente que da el puerto USB. Así que, pensando que esto pudiera ser la causa, al haber menos corriente, la carga de capacidades en el pad sería más lenta; aunque esto me parece rarísimo, porque para tener ese retardo tendrían que ser capacidades enormes.
El tiempo que tarda en cargarse un condensador es 1/(R*C), por lo que si la resistencia del cable no es muy grande, la capacidad ha de ser bestial para conseguir medio segundo...

No sé, un caso muy curioso, la verdad :D
gaula88 está baneado por "saltarse baneo temporal con clon"
Ayer estuve repitiendo las pruebas con el Nestopia sobre Gentoo, y la NES y va perfecto también.
Con el BSNES me da miedido, que por lo visto es un emulador con un arquitectura muy especial en que cada micro de la snes es un thread...es cycle-exact todo el conjunto... si este emulador da una respuesta exacta a la snes, creo que voy a empezar a convertirme más a la emulación :D
Me encanta ver que hay gente por aquí que se pregunta el por qué de las cosas, da explicaciones físicas (de las cuales no tenía idea)... Es lo que hace grande y diferente este foro :) Gracias chicos, en serio.
Pues yo a lo del cable si que le encuentro sentido. Existen muchos cables que por cualquier razón no dan la talla, por ejemplo seguro que muchos de vosotros habéis conectado algún dispositivo a vuestro pc y os han dicho que es un dispositivo usb 2.0 que correría mas rápido en un puerto 2.0. Estos problemas los suele crear el propio cable.

gaula88 creo que el nestopía es como el bsnes, que intenta ser lo más exacto posible, afortunadamente disponemos de emuladores de todas clases, los más correctos y exactos, pero que requieren de mucha cpu y de los que prescinden un poco de esa exactitud para permitir una perfecta experiencia jugable a todos los usuarios.

Un saludo
16 respuestas
Archivado
Volver a Consolas clásicas