VSync en consolas clásicas

si te sirve de algo, yo no recuerdo haber notado nunca tearing ni nada parecido ni en la clónica, ni en megadrive ni en psx

eso empecé a verlo en pc en la época de los emuladores y creo que es por culpa de que el refresco del monitor no coincide con los fps del juego o algo asi pero puedo estar equivocado

tampoco soy ningún experto en ese tema

@magrosomohoso
Yo tampoco recuerdo tener tearing en aquella época, lo que no sé es si era porque tenían algún tipo de sincronización activada de serie o qué .

Quiero jugar lo mas fielmente posible en emuladores pero al quitar el Vsync tengo bastante tearing, y pensaba que eso no era posible en un CRT.

Como respuesta corta/resumen, sí, la mayoria de consolas clasicas se sincronizan con el vsync a la hora de actualizar gráficos, además el vsync es la manera principal de procesar frames a una velocidad constante y suele usarse en el bucle principal de los programas.

wave escribió:Como respuesta corta/resumen, sí, la mayoria de consolas clasicas se sincronizan con el vsync a la hora de actualizar gráficos, además el vsync es la manera principal de procesar frames a una velocidad constante y suele usarse en el bucle principal de los programas.

De hecho muchas máquinas podían saber incluso el momento entre líneas.

Saludos

Entonces, ¿en la época también sufríamos el input lag que genera el Vsync o había alguna diferencia en esto?

Gracias por las respuestas

Rebozamiento escribió:@magrosomohoso
Yo tampoco recuerdo tener tearing en aquella época, lo que no sé es si era porque tenían algún tipo de sincronización activada de serie o qué .

Quiero jugar lo mas fielmente posible en emuladores pero al quitar el Vsync tengo bastante tearing, y pensaba que eso no era posible en un CRT.

en un crt es totalmente posible tener tearing, yo mismo en pc lo suelo sufrir ya que tengo el monitor a 85hz y los juegos que emulo funcionan a 60hz, entonces si no activas el vsync tienes tearing si o si
el tearing también me pasa viendo videos, por lo mismo, por la frecuencia de refresco del crt distinta a la de lo que estás reproduciendo

una forma de solucionarlo es poner el monitor a 60hz, pero asi es mucho mas molesto para la vista ya que el parpadeo del barrido se hace mas evidente, y en un crt de pc que lo tienes mucho mas cerca de lo que tendrías una tv se nota mas

@magrosomohoso exacto, el tearing o el stuttering se produce cuando ocurre esa descompensación.

Por eso si el bolsillo lo permite y si juegas en PC es bueno invertir en un monitor con soporte VRR, te olvidas de esos cambios de refresco, fogonazos y por supuesto del tearing y el stuttering.

Es curioso como todo lo bueno que trajo la emulación (inmediatez, cantidad, etc), también nos trajo elementos que muchos no conocíamos como el tearing, el stuttering, sobre todo en rom PAL y para mi por ejemplo ya por un tema de hercios nos acostumbramos a resoluciones altas pero 60hz que en juegos de MSDOS los rompe por completo porque la mayoría van a 75hz y 72fps...

Si me hubiesen dicho en 2004 todos los problemas que podía presentar un TFT no habría cambiado ni de coña el CRT que tenía para diseño gráfico.

Ahora tenemos muchísima información y herramientas, es completamente diferente e incluso Retroarch es capaz de cambiar los hz cuando el juego lo requiere, pero son funciones muy recientes que ni si quiera existían hace un año.

En el siguiente video se explica muy bien la emulación que la mayoría hemos vivido.



Por otro lado reconozco que en 1993 ó en 2001 ni me fijaba en fps ni input lag ni nada de eso.

Por ejemplo un juego con un input lag brutal es Tomb Raider 1 de PSX o Saturn, incluso jugando en un CRT...

@gordon81 el tomb raider 1 no lo se, pero el 2 también tiene que tener tela de lag porque lo tuve en la época y el control era chunguísimo
otros que tuve en la época y que tenian un lag brutal fueron
el dragon ball z de megadrive: donde pasa 1 segundo desde que pulsas el botón hasta que el personaje ataca, intenta hacer los especiales, por mucho que nos guste dragon ball este juego era injugable
y el hercules de psx también tela con el lag que se gasta, este es mas jugable pero aun asi cuando vuelves a el.... es horrible

magrosomohoso escribió:@gordon81 el tomb raider 1 no lo se, pero el 2 también tiene que tener tela de lag porque lo tuve en la época y el control era chunguísimo
otros que tuve en la época y que tenian un lag brutal fueron
el dragon ball z de megadrive: donde pasa 1 segundo desde que pulsas el botón hasta que el personaje ataca, intenta hacer los especiales, por mucho que nos guste dragon ball este juego era injugable
y el hercules de psx también tela con el lag que se gasta, este es mas jugable pero aun asi cuando vuelves a el.... es horrible

Pues debes de tener un DBZ de MD diferente al mío porque el mío nunca ha tenido nada de lag.

De todas maneras uno de los mayores problemas que adolecimos los europeos fueron los malditos 50hz, eso es un problema de cara a experiencias mucho más satisfactorias que tenía por ejemplo poder jugar a 60hz con ntsc, aunque a menos resolución que en pal, pero el tiempo de respuesta no tiene ni comparación.

No me acuerdo muy bien de DBZ, sólo se que era espectacular y que en aquellos años que lo jugué prestado en megadrive y una tv saba tan ricamente y que lo único que sí notaba era esa especie de carga para algunas escenas, pero nada que objetar.

El tema de input lag en juegos como tomb raider, es más complicado, porque a priori no debería ser un problema per se sino más bien un factor de programación.

Coges tomb raider de msdos y le da mil patadas en cuanto a tiempos de reacción a cualquiera de las versiones consoleras, pero es curioso que no se cuidasen estos aspectos.

issus escribió:

wave escribió:Como respuesta corta/resumen, sí, la mayoria de consolas clasicas se sincronizan con el vsync a la hora de actualizar gráficos, además el vsync es la manera principal de procesar frames a una velocidad constante y suele usarse en el bucle principal de los programas.

De hecho muchas máquinas podían saber incluso el momento entre líneas.

Saludos

Si, son tecnicas mas avanzadas y muchos juegos de nes por ejemplo tienen pequeños glitches graficos precisamente por modificar entre lineas ya que hay que ser mucho mas preciso.
Pero la basica de casi todas es usar el vsync.

Rebozamiento escribió:Entonces, ¿en la época también sufríamos el input lag que genera el Vsync o había alguna diferencia en esto?

Gracias por las respuestas

Normalmente los controles se suelen leer 1 vez por frame, dependiendo de cuando se procese y cuando pulses, podrias perder 1 frame, si.

Muy interesante el tema, estaría bien ver una comparación entre un sistema original y un emulador con la sincronización desactivada para ver la diferencia real.

Aclarar que yo emulo con un PC conectado a un TV CRT y que por suerte o por desgracia padezco hiper sensibilidad al input lag por lo que el Vsync me fastidia en algunos juegos, ¿a vosotros os molesta mucho? En juegos como Alien Storm de MD no lo soporto

@Rebozamiento ¿Tienes bien configurado el emulador? Los cores de baja latencia y con el hard gpu sync activado no deberian tener lag.

@AxelStone
La verdad que no sé cuales son los cores de baja latencia, para MD estoy usando el Genesis Plus GX y la sincronía con la GPU la tengo activada con un valor de 2 que a pesar de notar que baja la latencia no tiene el mismo efecto que desactivar el Vsync.

Lo que noto que hace algo más es la reducción predictiva de latencia, pero cuando pongo un valor de 3 (el ideal para mí) veo saltos en algunas animaciones.

Pasaos al VRR de una vez, yo he estado AÑOS haciendo pruebas con el VSYNC desactivado y obviamente no había color, pero oohh sorpresa, el amigo tearing aparece.

La única forma de evitar que el VSYNC salte es utilizando GSYNC y limitar los fotogramas máximos según los hz de tu monitor para que tanto vsync como gsync no se activen.

Por ejemplo, si trabajas a 100hz, limitar los fps a 97, de esta forma evitas que vsync salte y eso incluye gsync.

@Rebozamiento Para que run ahead funcione sin esos problemas que dices, debes afinar mejor el frame delay para cada juego y de esa forma no notarás esos saltos.

También se puede usar vulkan con swap chain a 2 y que integra nativamente la sincronía CPU+GPU, hace que consuma menos recursos que opengl y seguramente ayude a tener menos latencia derivada el consumo de recursos menor.

También ayuda mucho bajar la latencia del audio a 30-35ms, siempre probando que no escuches chasquidos, entones tendrás que elevarla.

Yo es que a día de hoy, salvo que tengas un misterFPGA - batocera y un buen CRT, no le veo sentido a rebanarse los sesos intentando remar a contra marea.

Es imprescindible usar mandos con cable que tenga un input lag de 1-2ms, con eso no hay ningún sistema real que se acerque a la comodidad que aporta Retroarch bien configurado.

Tengo la mega drive, la snes y la nes, he hecho pruebas con un sony pvm, pues qué queréis que os diga, ni se acercan a la experiencia que supone emular estos sistemas que además permiten quitar ralentizaciones haciendo overclock, permitiendo widescreen y reduciendo o eliminando en algunos casos el flickering.

La solución a todos los problemas es el VRR, sobre todo en juegos PAL, sistemas como el AMIGA, Commodore... lo agradecen enormemente.

Sólo hay que poner el Sams Journey en Vice para ver que mal va a 60hz porque es un juego que no tiene versión NTSC.

Pero si no tenéis VRR utilizad ScanlineSync del rivaturner, que esa opción es para eliminar el tearing cuando desactivas el vsync y se nota mucho el cambio, ahora bien, requiere trabajo configurarlo para cada sistema y en retroarch a mi me costó que funcionase bien en todos los sistemas que emulo, al final me pasé al VRR.

@gordon81

VRR no puedo usar en mi CRT .

He estado trasteando lo que comentas del frame delay y no he conseguido solventar los tirones en las animaciones, también he tocado la latencia del audio y no he notado ningún cambio. Seguiré mirando las cosas que has comentado con más profundidad a ver que tal .

Entiendo que, ¿teniendo sistemas originales te decantas por la emulación no?

Prueba a cambiar la latencia del audio en retroarch, por defecto esta está puesta a 64ms para que funcione bien en la mayoría de sistemas.

Yo en NES la tengo puesta por defecto a 17ms y en algunos casos a 22ms.

En Mega Drive a 20ms.

Etc.

Y prueba la alternativa a runahead que han implementado que no tiene tantos problemas como el que comentas y además consume menos recursos.

Bajo mi experiencia actual, sí puedo decir que obtengo como mínimo la misma latencia que con un crt y el sistema real (probado con snes, mega drive y nes), grabas un video a alta velocidad con el móvil apuntando al mando mientras presionas un botón y que se vea la imagen. Es más, incluso tengo mucha menos latencia que en un sistema real.