¿Qué da menos input lag?

No creo que GroovyMAME, por mucha magia que haga, te quite el tearing si no usas vsync.
alder-s escribió:@jigar hola me puedes decir como retroarch cambia la resolucion y refresco en un crt ???
yo lo uso y eso no pasa en mame osea que opcion se debe poner ???

A mí también me interesa la respuesta a esto
alder-s escribió:@jigar hola me puedes decir como retroarch cambia la resolucion y refresco en un crt ???
yo lo uso y eso no pasa en mame osea que opcion se debe poner ???

Con switchres activado, al menos en linux se crea el modo de video correspondiente (resolución y hz)
@Tomax_Payne gracias aprovechando tu conocimiento yo lo he probado en linux con un monitor crt pero con eso de los switchres una radeon 6450 por vga siempre me sale fuera de rango algo asi y se va la imagen

podrias ayudarme un poco que opcion exacta es del switchres


creo que salen estas opciones

CRTSwitchRes Options
Option Available Values
CRT SwitchRes off, 15KHz, 31KHZ Standard, 31KHZ- 120Hz, INI
CRT Super resolution Native, Dynamic, 1920, 2560, 3840
X Centering Currently not in use
Porch Adjust Currently not in use
Use Custom refresh rate Currently not in use
Como dice Tomax, poniendo la opción crt switchres a 15khz en settings > video. ¿El monitor soporta desde 15khz de refresco de frecuencia horizontal? Si soporta desde 30khz se te irá de rango frecuencias más bajas
Las soluciones CRT siempre te van a garantizar un input lag muy bajo por una sencilla razón: no hay post procesado de imagen. Piensa que todo lo que sea aplicar filtros de imagen es un post procesado, léase frames de retraso. Lo puedes compensar con el run-ahead pero no creo que sea una solución perfecta y en algunos cores puede dar fallos. A mi por ejemplo con el MegaCD me ripeaba el audio, igual ahora está resuelto el problema.

Al final solución CRT tipo GroovyMame, imagen directa a pantalla sin postprocesado, y si usas un mando USB que el polling esté al máximo.
La configuración por defecto de run-ahead no es válida para todos los juegos y cores. Partiendo de esa premisa, es obligatorio concienciarse de que hay una labor por parte del usuario que requiere probar cuál es la mejor configuración para X juego incluso en un mismo core hay juegos que no soportan la misma configuración.

Hace tiempo que resolvieron todos los problemas derivados de run-ahead, como no poder hacer overlock al core, los fallos en el sonido, etc.

Diría que es una locura activar por defecto run-ahead en la configuración principal de retroarch, hay que hacerlo por juego sí ó sí.

Automatic frame delay + run-ahead ó usar la alternativa a este último "preventive frames", es la auténtica salud.

Genesis Plus GX Wide, mano de santo.

Sobre el post procesado no entiendo, el shader se compila y aplica antes de arrancar el juego, de modo que no hay postprocesado ahí.

Lo digo principalmente, porque ayer haciendo pruebas con la cámara de mi teléfono móvil, el mando y las opciones que indico activas, en pulling me marcaba unos irrisorios 2ms y hablo en windows, que no he probado en modo focus de linux que estoy seguro que en usuarios de amd tiene que ser una gozada por ser más compatibles en linux con freesync.

En cuanto a vsync, lo tengo puesto en automático dentro de retroarch y en el panel de nvidia tengo puesto que use la configuración de retroarch para el vsync y activado "sync excact frame (freesync, vrr, gsync).

Para mi es la mejor experiencia posible, seguro que podría bajas más la latencia con un CRT, pero ya me limitaría en otras muchas cosas.
Elaphe escribió:No creo que GroovyMAME, por mucha magia que haga, te quite el tearing si no usas vsync.


En un crt no te vas a encontrar apenas con tearing, por su manera de "pintar" la imagen, siendo prácticamente instantánea, difícilmente se van a producir los desgarros de pérdida de sincronización que provoca el procesado de imagen de otras tecnologías de visualización más modernas. Yo lo tengo claro, mientras existan tubos y no me los iguale el mercado actual, ni se me pasa por la cabeza el cambiar de pantallas para pasar el rato con algo retro.
@alder-s
Danos algo más de info.
La hd 6450 funciona a resolución nativa.
tú monitor crt es de pc/vga? O un TV crt?
Usas una distro específica para 15khz (rgbuntu, mk4, R5, batocera+script)?
Conforme me digas te indico, es muy fácil, pero si no tienes el kernel parcheado, tendrás menús en 31khz y juegos en 15 y tendrás que ir cambiando cables o usar un switch.
@Tomax_Payne hola gracias

el monitor es uno de pc hp 7500 la radeon conectada a vga y uso linux mint 22 sin nada de parches osea como viene la distro de fabrica

no se que otra info es importante ?
Elaphe escribió:No creo que GroovyMAME, por mucha magia que haga, te quite el tearing si no usas vsync.


Pues deberías. Utilizando GroovyMAME junto con una tele de tubo obtendrás los refrescos originales. En consecuencia el tearing desaparece. Hace unos años hice la prueba y funcionaba estupendamente.
alder-s escribió:@Tomax_Payne hola gracias

el monitor es uno de pc hp 7500 la radeon conectada a vga y uso linux mint 22 sin nada de parches osea como viene la distro de fabrica

no se que otra info es importante ?


Perdona, creí que había enviado el mensaje, pero no.
Si es monitor, no te arrancará nada a 15khz (aunque si se está ejecutando, no verás nada).
En mi monitor de pc crt, yo uso:
CRT SwitchRes 31KHZ- 120Hz
CRT Super resolution 2560

En principio, estos dos ajustes, sacarán a relucir las scanlines que tiene tú monitor. Son muy bestias, pero te cargas el pixel raw de una vez. También te oscurecerá la imagen del monitor, pero será impresionantemente nítida.
Falta probar el scroll, por si hay que toquetear en el vsync.
Switchres debe ajustarte la res a 31khz y los hz de refresco al doble justo para una correcta conversión de 15 a 31. El menú de retroarch seguirá a 31 normal como hasta ahora.
También, cambiaría el menú a rgui, pues como tengas que ajustar la imagen por software, no verás bien las letras.
@Tomax_Payne hola pues me fue mal

te cuento con esas opciones la imagen se mira estirada en medio asi tipo una regla de estudiante ?

no se si me doy a entender

no se estira a todo el monitor

solo estirada enmedio y asi tipo regla

el menu si se mira correcto
alder-s escribió:@Tomax_Payne hola pues me fue mal

te cuento con esas opciones la imagen se mira estirada en medio asi tipo una regla de estudiante ?

no se si me doy a entender

no se estira a todo el monitor

solo estirada enmedio y asi tipo regla

el menu si se mira correcto


Pon en scale->core provided

Igual es mucho 2560 para según que gráficas, cambia por 1920
AxelStone escribió:Las soluciones CRT siempre te van a garantizar un input lag muy bajo por una sencilla razón: no hay post procesado de imagen. Piensa que todo lo que sea aplicar filtros de imagen es un post procesado, léase frames de retraso. Lo puedes compensar con el run-ahead pero no creo que sea una solución perfecta y en algunos cores puede dar fallos. A mi por ejemplo con el MegaCD me ripeaba el audio, igual ahora está resuelto el problema.

Al final solución CRT tipo GroovyMame, imagen directa a pantalla sin postprocesado, y si usas un mando USB que el polling esté al máximo.



Te tengo que corregir, esto NO es cierto, utilizar shaders en RetroArch no introduce input lag. El post procesado de los shaders se hace en el mismo periodo de tiempo que se tiene para renderizar la imagen sin ellos.
Te lo explico de otro modo: cuando usas OpenGL o Vulkan para presentar un frame de NES por pantalla, normalmente se usa una textura aplicada a un par de triángulos. Ahora imagina que en vez de usar un fixed pipeline para renderizar esa textura, usas un pipeline programable, que es lo que son los shaders. Siempre que el hardware llegue a tiempo, eso no significa que vayas a tener mas lag que con el fixed pipeline, ya que la presentación del frame al final se hace a través del sistema de gestión de buffers de pantalla del sistema operativo, que va a hacer lo mismo con shaders que sin shaders.

Si configuras bien el sistema de gestión de buffers (por ejemplo usando freesync si tienes equipo para ello, o si no lo tienes usando un modo de 120Hz y poniendo el Swap Period a 2 o Auto para de ese modo evitar el lag inducido por el VSYNC) no hay lag.

Estás cosas son una ciencia exacta, no sensaciones subjetivas. No es opinable, los hechos son esos: conozco RetroArch y SDL2 por dentro en esos aspectos porque programé varios de sus sistemas gráficos de nivel cercano a la máquina.

Lo que mete input lag son las TV de los cojones, que son una puta mierda y a pesar de eso millones de tarugos se las compran para ver "eh júrgol" en grande sin informarse y luego se quejan de que hay lag.
Usando un monitor de ultra baja latencia eso no pasa. Pero todo eso ya pasa fuera de la máquina, no tiene nada que ver con el uso de shaders.
@MrNutz Pues puede que sea el monitor, yo solo se que en esa sensación subjetiva hice una comparativa a 3 bandas con el mismo juego y los resultados fueron muy diferentes. Se trata de un juego muy sencillo, Storm Rescue de MSX, el ganador del concurso MSX Basic de hace un par de años. Simple pero adictivo a tope.

Se trata de un juego donde la precisión es milimétrica, debes despegar y aterrizar tu helicóptero para rescatar personas de un barco que se hunde. Para probar input lag es ideal, ya que cualquier mínimo retraso en la entrada te jode la partida. Niveles de lag que tuve:
  • FPGA usando teclado PS2. Ausencia total de lag, el juego iba perfecto. Cogí tal destreza que me acabo el juego prácticamente en un speed run.
  • Emulación CRT con teclado USB. Bastante bien, cercano a la FPGA pero un paso por detrás, lo justo para no poder hacer ese speed run y tener que maniobrar más.
  • Emulación LCD en pantalla 32" FHD. Mira que puse el modo juego, ni por esas. Es frustrante porque de repente pareces más torpe que un octogenario y siempre nos escudamos en el "es que mis reflejos no son los que eran". Ni reflejos ni leches, es que no responde bien.
Dicho lo cuál, me has animado a que mi próximo monitor de PC sea uno de alta frecuencia y probar algunos emuladores a ver si por fin me puedo emancipar del CRT [beer] . No es que tenga prisa, adoro el CRT, pero sé que antes o después morirá.
AxelStone escribió:@MrNutz Pues puede que sea el monitor, yo solo se que en esa sensación subjetiva hice una comparativa a 3 bandas con el mismo juego y los resultados fueron muy diferentes. Se trata de un juego muy sencillo, Storm Rescue de MSX, el ganador del concurso MSX Basic de hace un par de años. Simple pero adictivo a tope.

Se trata de un juego donde la precisión es milimétrica, debes despegar y aterrizar tu helicóptero para rescatar personas de un barco que se hunde. Para probar input lag es ideal, ya que cualquier mínimo retraso en la entrada te jode la partida. Niveles de lag que tuve:
  • FPGA usando teclado PS2. Ausencia total de lag, el juego iba perfecto. Cogí tal destreza que me acabo el juego prácticamente en un speed run.
  • Emulación CRT con teclado USB. Bastante bien, cercano a la FPGA pero un paso por detrás, lo justo para no poder hacer ese speed run y tener que maniobrar más.
  • Emulación LCD en pantalla 32" FHD. Mira que puse el modo juego, ni por esas. Es frustrante porque de repente pareces más torpe que un octogenario y siempre nos escudamos en el "es que mis reflejos no son los que eran". Ni reflejos ni leches, es que no responde bien.
Dicho lo cuál, me has animado a que mi próximo monitor de PC sea uno de alta frecuencia y probar algunos emuladores a ver si por fin me puedo emancipar del CRT [beer] . No es que tenga prisa, adoro el CRT, pero sé que antes o después morirá.


Es que en el peor de los escenarios posibles, que es emulación + LCD, hay mucha tela que cortar.
En primer lugar, los emuladores sobre SDL2 son un caso perdido: puedes poner un modo de 120Hz pero luego no tienes manera de controlar que el Swap Period sea 2. Eso sólo lo puedes hacer en RetroArch.
Para emular MSX en RetroArch puedes usar FBNeo que sorprendentemente soporta MSX1, los demás cores (bluemsx, fmsx) son un asco por distintas razones. Quizá MAME pero no lo he probado.
Luego está el lag de la pantalla en sí. Pero por ejemplo los monitores ViewSonic tienen una opción de baja latencia que, si configuras bien la parte del ordenador, queda como un CRT.

Por aclararlo aún más, el input lag del lado del ordenador viene sobre todo del vsync.
Por eso con freesync no hay lag (ojo que una cosa es activarlo y otra que funcione en tu combinación de gráfica + cable + monitor), y si metes 120Hz con vsync tampoco hay lag (tienes el doble de vblanks por segundo así que no hay que andar esperando para meter el cambio de buffers).

También puede haber cierto input lag debido a la lectura de mandos y teclados USB, pero eso en Linux se corta de raíz poniendo el polling a 1000Hz. Es físicamente imposible tener lag por ahí sí se hace.

Y además añadir que todas mis consideraciones al respecto son aplicables a Linux usando Wayland puro.
En Windows o Mac, pues mierda en bote como ha sido siempre, hez de mono diarreico, lentitud, dolor, absurdez, imposibilidad de saber cómo se gestionan los buffers en una pila de mierda formada por un kernel cerrado, unos drivers cerrados y unas APIs cerradas.
Hodor escribió:
Elaphe escribió:No creo que GroovyMAME, por mucha magia que haga, te quite el tearing si no usas vsync.


Pues deberías. Utilizando GroovyMAME junto con una tele de tubo obtendrás los refrescos originales. En consecuencia el tearing desaparece. Hace unos años hice la prueba y funcionaba estupendamente.


He consultado este asunto y te cito las palabras textuales de Calamity en sus respuesta:

"Vsync is always needed. It doesn't matter how close the refresh is. In fact, if you could achieve a 100% perfect match on the refresh you would still see tearing without vsync."

También el otro día dijo que:

"MAME + lowlatency + no vsync + freesync -> sub-frame latency
GroovyMAME + lowlatency + vsync + frame delay -> sub-frame latency
GroovyMAME + lowlatency + vsync + no frame delay -> a bit over 1 frame latency"

Así, concluyo que usar MAME con lowlatency, sin vsync y con un monitor moderno que soporte freesync consigue un input lag que no se puede lograr con GroovyMAME y un CRT sin recurrir al invento del frame delay.

Ahora también se podría decir que un monitor TFT añade retardo, mientras que un CRT no, pero entiendo que hablando de monitores y teles modernas, la latencia puede ser de 1 ms o menos, así que es despreciable. Corregidme en este punto si me equivoco, porque no soy ningún experto en monitores.
68 respuestas
1, 2