¿Cuánta latencia de entrada es mucha latencia para emulación?

Responder
Pues, digamos que tenía un dinero en AliExpress muerto de risa y he hecho la tontería de comprarme un GameSir Nova Lite para emulación en PC y juego general. Parecía un bueno-bonito-barato y no había leído nada extraño, pero recién recibido, he visto que esta es su latencia y estoy con el culo bien apretado, especialmente en modo inalámbrico.

Imagen

¿Esto es medianamente gestionable o como me parece a mí una auténtica salvajada sin cable? Lo poco que he probado por dongle no parece TERRIBLE, pero no he tenido tiempo de ponerlo a prueba con algo exigente como un Ikaruga o algo de lucha.
Pues mira si juegas a 60fps 16ms de input lag es un frame, por lo que 40ms son casi tres frames de lag.

40ms en mi opinión ya se empieza a notar en juegos precisos.

Aunque 5ms de minimo en cable, tampoco es una maravilla, hay mandos que alcanzan el 1ms pelao de input lag.
@Alejo I depende mucho de factores como los hz pero también hay que empezar a mentalizarse de lo que comenta también @Notarioh , a veces no asumimos que en los 90 jugábamos a 50hz y que eso ya añadía un pico de lag a juegos que en vez de ir a 60fps iban a 50fps, es como el mortal kombat de recreativa, va a 50fps, da igual lo que le enchufes que no vas a notar grandes cambios. Sin embargo yo soy de los que opina lo siguiente... siempre ten a mano tanto dispositivos de baja latencia como la mejor configuración posible optimizada para reducir la latencia residual que producen los propios equipos de windows mal configurados.

No quiero tirarme el moco, pero 8bido ha lanzado el ultimate wireless de 0.3ms de latencia, el tacto es sublime con una cruceta que es el paso intermedio perfecto entre mecánica y membrana, en todo momento sabes qué estás pulsando y por qué hablo de esto, porque muchos mandos de baja latencia fallan luego en la ergonomía y las horas de uso frente a la pantalla.

Lo más importante es que se evite ese estigma de que 8ms es una catástrofe cuando en los 90 jugábamos con picos de 18ms de media.

Eso sí, lo que no se puede hacer lo que vende nintendo con sus mandos pro de 18ms... conectas eso a un equipo y a parte de la pantalla, el equipo no optimizado, etc, vas a notar la latencia sí o sí.

Retroarch + monitor gsync 120hz + un mando de 0.3ms unido al uso de runahead, vulkan (sincronía cpu+gpu nativa) y se mea en cualquier sistema retro nativo.
(mensaje borrado)
Yo uso ese mando tan ricamente en Switch. Aclaro que no soy para nada pro.
salvaplva escribió:@gordon81 hola me podrias orientar cual es la diferencia en vulkan max swapchain images

se puede poner en 2 , 3 , 4

pero cual es la mas adecuada ?


No te sale la descripción de la función en el menú de RetroArch? Yo por lo menos que lo uso en inglés si sale y es un factor que depende de los HZ que tenga tu pantalla si mal no recuerdo.
Échale un vistazo al gulikit es / es pro. Parece que tiene menos lag y es más barato, lo están poniendo muy bien en las reviews: https://gamepadla.com/gulikit-es-pro.html

Y un mando aún más barato con una latencia de risa, el gamesir tegenaria lite, aunque solo es de cable: https://gamepadla.com/gamesir-tegenaria-lite.html

Personalmente en un mando busco que tenga menos de un frame de lag a 60 hz (16,6 ms), aunque sé que quizá no notaría la diferencia con uno que tenga algo más.

Saludos.
@Alejo I es un gamepad, no es ninguna burrada.
Si fueras a jugar a FPS online con el, quizás te recomendaría pillar otro, pero para juegos retro es mas que adecuado.
Los de lucha, si haces una prueba siendo honesto contigo mismo (sin sugestionarte, vamos) y ves que sin cable es inviable, juega con cable.
Sobre shmups tipo Ikaruga, vuelvo a lo de que es un gamepad, el lag sería el menor de los problemas. Un arcade stick de recorrido corto (nada de Sanwa JLF) es lo suyo.
Tengo dos GameSir Nova Lite (me compré el segundo tras probar el primero), lo uso siempre en modo inalambrico (dongle) y no he tenido ningún problema con ellos. Eso si, estoy lejos de ser una putita de los altos fps o un negacionista de los emuladores por software. Tampoco compito online por inflarme el ego por matar muchos moñecos mientras grito por un micro (y menos con mando) :p

En definitiva, sinceramente, si alguien "normal" siente problemas de latencia con uno de estos creo que es mas problema de ser un tiquismikis (AKA androide con ojos de jamescameron) que del mando.

Para mi es un mando cojonudo, sus multiples modos de conexion, sus modos turbo, sus stick Hall, su chulisima funda rígida y todo ello por ese precio (menos de 20€ en mi caso). Cojonudo es quedarse corto.
Gracias a todos por vuestras respuestas :)

dlabo escribió:@Alejo I es un gamepad, no es ninguna burrada.
Si fueras a jugar a FPS online con el, quizás te recomendaría pillar otro, pero para juegos retro es mas que adecuado.
Los de lucha, si haces una prueba siendo honesto contigo mismo (sin sugestionarte, vamos) y ves que sin cable es inviable, juega con cable.
Sobre shmups tipo Ikaruga, vuelvo a lo de que es un gamepad, el lag sería el menor de los problemas. Un arcade stick de recorrido corto (nada de Sanwa JLF) es lo suyo.

Para sticks tengo cero problemas porque hace tiempo un fabricante chino quiso comprarme una review o algo así enviándome gratis una caja llena de Arduinos Micro, los tengo por castigo [+risas]
Desconozco el dispositivo, pero esa latencia es una salvajada para un mando. Hasta 10ms es bien. De 10 a 20 es aceptable. Más de 20 es para prenderle fuego.
Si haces speed runs de juegos y metes un mando de más de 20 ahí canta la latencia que no veas, eso de que no se nota... falso. No se nota si no tienes con que compararlo, como todo. Para el que siempre juega con latencia va "bien".
Edito: Nada, creía que era lo de la tabla. Lo que ponen en la web, la peor es de 21. A ver, no es bien, pero tampoco terrible. Se debería poder jugar sin problemas, pero como tengas latencia también por otro lado, se va a empezar a notar.
gordon81 escribió:
Retroarch + monitor gsync 120hz + un mando de 0.3ms unido al uso de runahead, vulkan (sincronía cpu+gpu nativa) y se mea en cualquier sistema retro nativo.


Esto es así. Da gusto ver que la gente va entendiendo que el input lag no es magia sino que detrás está la gestión de buffers, el backend gráfico, la frecuencia de refresco del monitor...
Y si, un monitor a 120 con VRR/Gsync va a tener muchísimo menos lag que a 60hz con vsync. Pero MUCHO menos.
De hecho, cuantos más HZ mejor, incluso sin VRR/GSync, usando VSYNC a 120Hz o incluso mejor a 240Hz, el lag se va a la mierda al fin, aunque el juego vaya a 60fps.
Y esto es así porque el problema del lag cuando se activa VSYNC viene de que hay que esperar al VSYNC para cambiar un buffer por otro: en un monitor a 120hz eso pasa el doble de veces que en uno a 60Hz, y en uno de 240hz pasa cuatro veces más por unidad de tiempo que en uno de 60, etc

RetroArch es la polla porque precisamente permite que juegos a 60fps vayan perfectamente suaves en un monitor a 240Hz ya que permite especificar que el cambio de buffer se haga cada cuatro VBlanks. De hecho, sin que le digas nada, ya lo hace solo él por defecto.
Y así podemos tener 60FPS suaves perfectos en un modo de 240Hz... Y adiós lag.
@MrNutz mi monitor es de 270hz, tenía entendido que Retroarch se entiende mejor con múltiplos pares a la hora de hacer el VRR, pero creo que lo entendí mal porque al final... joder para eso es el VRR-GSYNC para trabajar al máximo de hz y cuando los fps lo requieren bajar esa tasa a 60 por ejemplo.

Entiendo que la limitación a 120hz sería lógico si no tuvieses gsync-vrr para que el divisor de Retroarch baje a 60 y no tengas problemas si por ejemplo trabajas a 75hz, ya que el divisor no funcionaría.

Esta tarde quito la limitación y pruebo.
Bueno, el retardo añadido habría que compararlo con el sistema original. Las consolas clásicas dónde los gamepada iban conectados directamente por cable, el input lag es de 0, así que cualquier cosa mayor a 0 ya añade lag... Calcular si es mucho o poco, un buen razonamiento puede ser calcular que probabilidad hay de que la pulsación se procese justo en el siguiente frame o no. Por ejemplo, si tenemos en cuenta que el mando tiene 5 ms de retraso, y el juego procesa un frame en 16 milisegundos (60hz), la probabilidad de que la pulsación no pueda ser procesada en el siguiente frame (con lo que perderiamos un frame) es de 5/16 = 0.3125 , un 31% de las pulsaciones tendrian ese frame de latencia mas que en el sistema original.... Creo que así te puedes hacer una buena idea.

Por otro lado, si un frame mas o menos es perceptible o no, dependerá mucho del tipo de juego, juegos mas clásicos donde el control es 1 a 1 y se necesita habilidad pues será mas notable, en contra de juegos mas nuevos donde por ejemplo el personaje que controlamos se mueve de manera menos reactiva (como por ejemplo en GTA que el personaje tiene que ir mezclado las animaciones etc cuando cambiamos la direccion de control....)

Según mi experiencia, como menor sea la latencia mejor, aunque la latencia normal de un usb stick, que es de pocos ms no suele notarse tanto, normalmente suele ser bastante mas perceptible la latencia que añade el emulador que se use mas que el mando de control... Pero esto ya es otra historia, entiendo que solo preguntabas por el tema del stick.
Si se quiere hacer una prueba de input lag, lo mejor es enchufarse el Ninja Gaiden 2 de NES, la dificultad de ese juego pone a prueba hasta el mando con menos ms.

Pero muchos habáis de 60fps cuando en los 90 todos nos comimos juegos de 50fps ó incluso menos por la dichosa región pal... hablar ahora mismo de 60hz y opinar de input lag comparándolo con sistemas originales, creo que al menos en Europa es bastante relativo.

Lo dicho Retroarch, monitor con VRR-Gsync 120hz, runahead, vulkan y un linux se folla la burbuja especuladora de los sistemas retro.
gordon81 escribió:Si se quiere hacer una prueba de input lag, lo mejor es enchufarse el Ninja Gaiden 2 de NES, la dificultad de ese juego pone a prueba hasta el mando con menos ms.

Pero muchos habáis de 60fps cuando en los 90 todos nos comimos juegos de 50fps ó incluso menos por la dichosa región pal... hablar ahora mismo de 60hz y opinar de input lag comparándolo con sistemas originales, creo que al menos en Europa es bastante relativo.

Lo dicho Retroarch, monitor con VRR-Gsync 120hz, runahead, vulkan y un linux se folla la burbuja especuladora de los sistemas retro.


La tasa de refresco del juego no tiene que ver con el input lag más que lo que he comentado en el mensaje anterior. Los juegos en España/Europa iban mas lentos, pero el input lag era el mismo (con lo que era mas facil el juego), en el caso de las arcade era lo mismo.
El tema de VRR-Gsync y tecnologias similares solo se aplica a LCD's y tecnologias similares, en los monitores CRT esto no es un problema ya que el refresco es el mismo que en el HW original. Además, tener mas tasa de frames en un LCD o similar ayuda a no tener tearing, o a poder correr el juego a una velocidad mas parecida a la original, sin tener frames duplicados y cosas similares, pero poco ayuda a la latencia del control, es mas a la (fluidez de la ) imagen. El runahead si que ayuda en ese sentido, y se puede hasta poder tener latencias inferiores al juego original,( con lo que tambien pierde la gracia ya que no se juega como fue diseñado por los programadoes.), además se necesita mucha potencia de cálculo para que funcione correctamente, ya que hay que simular simultaneamente todos los frames con todas las combinaciones de botones "N" veces, en el tiempo de un solo frame.
@werewolf ponte el super mario world pal de SNES y luego te pones el de ntsc... vas a comprobar las limitaciones de las vesiones pal frente a las americanas y por qué los speedrunners utilizan la versión pal de super mario world pal que está ligeramente "acelerado" para compensar las diferencias de región entre ambas versiones y cómo lo están empleando para usar el hack región ntsc junto a la versión pal de super mario world para tener el juego más fluidao y rápido que existe de super mario world.

Una cosa son los fps internos y otra muy distinta los que demanda por región el cartucho, por eso luego se rompen músicas y sonidos cuando cambias de región de pal a ntfs (música más rápida).

En los 90 nos comimos más input lag del que te estás comiendo ahora mismo con una buena configuración del sistema.

A lo que ya no entro es a un windows de mierda con toda la morralla usando un pad de esos chinurris y esperar tener la mejor respuesta posible.

El ejemplo más claro es MS-DOS, casi todos los juegos no superaban los 15 fps pero el reloj no les metas un monitor de 60hz que rompen el motor de sonido, stuttering, tearing, etc, porque el 95% de los casos trabajan a 70hz.
gordon81 escribió:@werewolf ponte el super mario world pal de SNES y luego te pones el de ntsc... vas a comprobar las limitaciones de las vesiones pal frente a las americanas y por qué los speedrunners utilizan la versión pal de super mario world pal que está ligeramente "acelerado" para compensar las diferencias de región entre ambas versiones y cómo lo están empleando para usar el hack región ntsc junto a la versión pal de super mario world para tener el juego más fluidao y rápido que existe de super mario world.

Una cosa son los fps internos y otra muy distinta los que demanda por región el cartucho, por eso luego se rompen músicas y sonidos cuando cambias de región de pal a ntfs (música más rápida).

En los 90 nos comimos más input lag del que te estás comiendo ahora mismo con una buena configuración del sistema.

A lo que ya no entro es a un windows de mierda con toda la morralla usando un pad de esos chinurris y esperar tener la mejor respuesta posible.

El ejemplo más claro es MS-DOS, casi todos los juegos no superaban los 15 fps pero el reloj no les metas un monitor de 60hz que rompen el motor de sonido, stuttering, tearing, etc, porque el 95% de los casos trabajan a 70hz.


Ni idea de qué versión usan los speedrunners, pero teoricamente debería de ser al revés, la versión NTSC debería de ser mas rápida que la PAL, con lo que tendría mas lógica que usaran la NTSC, ¿no?

Con lo del input lag, en los juegos antiguos, que sincronizaban por frame, el input lag es el mismo, es de 0 ms, el juego procesa ese input en el siguiente frame, en el caso de PAL como el juego va a menos imagenes por segundo el juego es mas lento, con lo que es mas facil pq tienes mas tiempo de reaccionar por frame. Eso de que en europa teniamos mas input lag no es así en los juegos antiguos como el super mario, lo sería en juegos mas modernos que si sincronizan la lógica con el diferencial de tiempo de un frame a otro. ( y bueno, en esa época, las teles europeas ya podian ponerse a 60 HZ)

De todos modos, la pregunta del hilo es cual tiene que ser el input lag que añade un gamepad para que no afecte al gameplay, en mi primera respuesta intento razonar como poder evaluarlo de una manera objetiva.
Bueno @Alejo I , no te has pronunciado al final. Cuéntanos tus impresiones XD
Aún no me he puesto con lucha. He probado Sonic Origins y no he notado nada raro (al margen de que configurar el Bluetooth es muy poco intuitivo).
Alejo I escribió:Aún no me he puesto con lucha. He probado Sonic Origins y no he notado nada raro (al margen de que configurar el Bluetooth es muy poco intuitivo).


Pues depende del juego, uno de lucha o uno de naves o plataformero si que importa el lag, aunque también el tipo de tv, el dispositivo, el emulador etc... pero si ves que no te convence y viendo que te ha salido por 2 perras y tienes arduinos pues no le des muchas vueltas, lo canibalizas y usa un arduino con gp2040 y listo, eso es la creme de la creme.

Yo tengo varios y hace poco pillé un hori fighting stick de ps3 inalámbrico jodido, pillé un zero delay BT que aunque no es la panacea pues cumple y corté las pistas de los botones y todo puenteado al zero y bien, no va mal pero para juegos que no requieran un input lag rapido. Si quiero jugar a uno de estos saco un Krome al que sustituí el pcb por una raspberry pico con GP2040 y perfectisimo. Además de ser compatible con varios sistemas (pc, switch, xbox, ps4/5) etc,,,
Pues tengo un par de mandos chinorris marranos que igual acaban así...

¿Cuál sería el proyecto Arduino más adecuado para sticks analógicos en lugar de gamepads?
21 respuestas
Responder
Volver a Arcade y emulación