Hallo Besucher, der Thread wurde 25k mal aufgerufen und enthält 165 Antworten

letzter Beitrag von AW182 am

Eingabe Latenzen in Emulatoren

    Zitat von pi64
    Zitat von Retro-Nerd

    Sind auf jeden Fall 20ms extra Lag, wenn der Vsync an ist. :D

    Jor, ich meinte in Bezug auf die FPS ^^


    Da kommt dann beides zusammen. Einmal 20ms mehr sowieso dann und dann bremst vsync auch in gewisser Weise die Emulation noch etwas aus zusätzlich, sodaß man nicht soviele Frames RunAhead einstellen kann.



    Wie ist das eigentlich wenn man auf einem CRT-Monitor einen 100Hz Bildmodus für PAL-Spiele verwendet und hier dann vsync anschaltet? Sind es da dann nur 10ms extra Lag, was dieses ausmacht?

    Zitat von AW182

    Da kommt dann beides zusammen. Einmal 20ms mehr sowieso dann und dann bremst vsync auch in gewisser Weise die Emulation noch etwas aus zusätzlich, sodaß man nicht soviele Frames RunAhead einstellen kann.

    Ja, wundert mich. Ich sehe null Unterschied was die Performance betrifft. Ich lass das an.

    Ich hab bei Blue Max@4 Frames Runahead schon den Effekt, dass der Flieger etwas "hüpft" wenn man lenkt. Vielleicht sind 3 Frames eh schon das Optimum was die Spielerfahrung angeht.

    Zitat von Retro-Nerd

    Rein theoretisch müsste es alles paar Minuten einen Mikroruckler geben, wenn Vsync nicht akiviert ist (Wegen der 50Hz vom Monitor und der 50.12Hz Ausgabe des C64.) Mit Vsync wird die C64 Geschwindigkeit im Emulator auf exakt 50.00 festgenagelt.

    Eben nochmal angetestet. Bei mir äussert es sich dann nicht unbedingt mit gleichbleibend starken Mikrorucklern, sondern es ruckelt manchmal etwas weniger und manchmal etwas mehr. Auf jedenfall nicht richtig weich und unerträglich für mich in scrollenden Spielen, um so dann mit Freude irgendetwas zu zocken, dazu muss sich für mich immer alles so butterweich über den Screen bewegen, wie ich es von den Originalmaschinen her kenne. Ist das nicht der Fall, dann lenkt mich das ab und ich kann mich nicht mehr richtig auf's Game selbst konzentrieren. Nur in Spielen die nicht scrollen, spielt es jetzt nicht so eine grosse Rolle, die kann man auch gut zocken, wenn FPS und Hz nicht übereinstimmen oder direkt teilbar sind.


    Also die "Video Synchronisation" abzuschalten ist für mich persönlich wirklich keine Option, dann lieber nur 1 Frame RunAhead aber dafür butterweich scrollend. Mehr schafft mein PC halt nicht, aber das ist okay, spielt sich auch so schon gut.


    Zitat von pi64

    Ja, wundert mich. Ich sehe null Unterschied was die Performance betrifft. Ich lass das an.

    Ich hab bei Blue Max@4 Frames Runahead schon den Effekt, dass der Flieger etwas "hüpft" wenn man lenkt. Vielleicht sind 3 Frames eh schon das Optimum was die Spielerfahrung angeht.

    Sind 4 Frames RunAhead nicht sogar schon zuviel, wenn man das mal zusammenrechnet, dann spart man damit 80ms Lag. Ist man dann nicht schneller in der Reaktion als auf dem Originalrechner? Kommt man überhaupt auf 80ms Lag in den Emu's? Das ist der Polling-Wert der alten USB Competition Pro Sticks und die waren unspielbar. Okay, da kam dann natürlich immer nochmal etwas Lag drauf durch den Emu selbst undsoweiter, aber ich glaube nichtmal, dass man 80ms Lag hat am PC in den Emus, wenn man dazu einen sehr schnell reagierenden Joystickadapter oder USB Controller nimmt. Oder was meint ihr?

    Mit WASAPI als Audiotreiber und 7ms Buffer habe ich keinerlei Probleme. Mit XAudio kommt mitunter schon mal ein leichtes Geruckel rein. Sowas ist aber immer Hardware-/Software (und da speziell die Treiber) abhängig.


    Zitat

    Sind 4 Frames RunAhead nicht sogar schon zuviel, wenn man das mal zusammenrechnet, dann spart man damit 80ms Lag. Ist man dann nicht schneller in der Reaktion als auf dem Originalrechner? Kommt man überhaupt auf 80ms Lag in den Emu's?


    Kommt auf das System an, auch auf den Monitor und den Eingabe Geräten. Und natürlich auf die einprogammierten Frames Lag in den Spielen selber (hatte Giana Sisters mal mit 3 Frames! in Retroarch gemessen). Vom Emulator und OS selber kommen immer so 30-40ms zusammen.

    Zitat von Retro-Nerd

    Kommt auf das System an, auch auf den Monitor und den Eingabe Geräten. Und natürlich auf die einprogammierten Frames Lag in den Spielen selber (hatte Giana Sisters mal mit 3 Frames! in Retroarch gemessen). Vom Emulator und OS selber kommen immer so 30-40ms zusammen.


    Ja, genau. Ich schätze auch, vielleicht um die 30ms Lag durch den Emu, dann kommen vielleicht nochmal zwischen 5ms und 15ms Lag drauf durch den Controller oder Controller-Adapter, dann ist man insgesamt bei irgendeinem Wert um die 50ms Lag bei den Emulatoren am PC, ist meine Vermutung.


    Am echten C64 wird man ja auch einen ganz kleinen Lag haben, denke ich. So kommt es mir zum Beispiel so vor, als wenn mein gemoddetes C64DTV, an dem nun auch zwei Joystickanschlüsse vorhanden sind, nochmal einen ganz kleinen Ticken schneller reagiert beim lenken als der echte C64. Da fühlt sich alles irgendwie super direkt an. Könnte eventuell Einbildung sein, glaube ich aber eigentlich nicht, denn bei "Microprose Soccer" gewinne ich komischerweise fast immer die WM, wenn ich das Game am gemoddeten DTV spiele. Also gehen wir mal von irgendwas um die 5 bis 10ms Lag am echten C64 aus und zieht man das dann von den oben erwähnten 50ms Lag bei den Emulatoren ab, dann blieben um die 40ms Unterschied im Lag zwischen der echten Hardware und den Emu's.


    Also natürlich jetzt alles nur geschätzt, aber ich glaube das liegt schon irgendwo in der Nähe der Realität. 40ms Lag-Unterschied würden dann 2 Frames RunAhead entsprechen oder vielleicht auch 3ms dann wäre man bei 60ms. Denke 2 oder 3 Frames RunAhead dürften circa dem Lag am Original-C64 entsprechen, höher gehen, glaube ich, wäre eigentlich nicht mehr notwendig. Aber natürlich auch irgendwie interessant, wenn man im Emu dann weniger Lag als auf der originalen Hardware einstellen kann. :)

    Bei scrollenden Spielen, wie Shadow of the Beast, merkt man relativ schnell, wenn man niedriger als das Original Lag kommt. Läuft man los, zuckt das Scrolling kurz, da das erste Scroll Frame durch runAhead verpasst wurde.


    Eine zeit lang ist das Scrolling auch ohne Vsync in Ordnung (schwankend). Ist audio Sync aktiv, wird der Emulator abhängig von der Einstellung 'übergehe exakte Frequenz' entweder zur Original PAL Frequenz des C64 (50.1245 Hz) oder zu der eingegebenen Frequenz (50 Hz in der Regel) die richtige Menge Audio Samples generieren. Das lässt sich jedoch nicht präzise genug steuern um komplett auf Vsync verzichten zu können.


    Die exakte Frequenz zu verwenden, ist jedoch nur bei G-Sync, Free-Sync Monitoren sinnvoll.

    Gibt noch eine potenzielle Stolperfalle.Man sollte darauf achten, das die Soundausgabe in KHz im OS mit der vom Emulator übereinstimmt. Also entweder 44KHz (CD Qualität), oder 48KHz (DVD Qualität). Das zu mixen führt oft nicht nur zum leiern, sondern auch zu performance Einbrüchen, kratzen etc (durchs resamplen nehme ich an).


    Ich habe einen Freesync Monitor, aber mitunter aktiviere ich trotzdem den Vsync in Denise. Selbst mit "übergehe exakte Frequenz" (mit dem korrekten Wert des Original C64) gibt es ohne in bestimmten Situtationen ganz leichter Ruckler oder Soundkratzer. Mit Vsync ist alles perfekt, auch nach 30 Minuten+ noch.

    Zitat von Retro-Nerd

    Ich habe einen Freesync Monitor, aber mitunter aktiviere ich trotzdem den Vsync in Denise. Selbst mit "übergehe exakte Frequenz" (mit dem korrekten Wert des Original C64) gibt es ohne in bestimmten Situtationen ganz leichter Ruckler oder Soundkratzer. Mit Vsync ist alles perfekt, auch nach 30 Minuten+ noch.

    Wenn du "übergehe exakte Frequenz" deaktivierst, arbeitet er mit der C64 PAL Frequenz. Es ist also nicht notwendig es zu aktivieren und 50.1245 Hz einzutragen.


    "übergehe exakte Frequenz" bezieht sich nur darauf wieviele audio samples für die eingestellte Bildwiederhol-Frequenz generiert werden müssen. Es synchronisiert Video also nur indirekt.

    Ehrlich gesagt weiß ich nicht, ob es für sauberes Scrolling üblich ist Vsync für einen Freesync Monitor aktivieren zu müssen und wenn nicht, was dafür von meiner Seite programmiert werden muss. Da müsste ich mir erst so ein Teil zu legen.

    In Bsnes gibt es eine 'Adaptive Sync' Option für G-Sync / FreeSync Monitore.

    Wenn du die aktivierst, hast du dann lang anhaltendes sauberes Scrolling ohne Vsync ? Wenn ja, werde ich mir mal den zugehörigen Programm Code anschauen.

    Das ist arg unterschiedlich. In Retrorach z.B. komme ich bei den meisten Cores perfekt ohne Vsync aus. Da ist es nur wichtig, die höchste Hz Einstellung des Monitors zu wählen. Manche sehr alte Emulatoren wie Kega Fusion kommen auch ohne Vsync zurecht, wenn ich Freesync aktiviere. Aber Bsnes bleibt problematisch (RetroArch und Standalone). Ohne Vsync habe ich, je nach Einstellungen, mal Tearing oder mal Sound Probleme. Keine Ahnung, aber vielleicht spielen die Grafik- und Soundtreiber da zusätzlich doch noch eine größere Rolle. Adaptive Sync in Bsnes selbst hilft hier nicht. Ich muß zwingend in 60Hz umschalten und Vsync aktivieren.


    Zusätzlich Enhanced Sync (das ist eine Zusatz Option, damit aktviert man nicht den Freesync), speziell im AMD Treiber aktiviert, hilft mir z.B. bei WinUAE. Da habe ich mit Beam Racing und aktivierten Shadern arge Probleme mit Tearing (Beam Racing ohne Shader ist fehlerfrei), obwohl Beam Racing ja eine Art von Vsync voraussetzt. Aber Toni meinte da auch, das es für ein 100% stabiles BR keine Garantie gibt, sofern sich irgenwelchen Einstellungen ändern.

    Zitat von Retro-Nerd

    Das ist arg unterschiedlich. In Retrorach z.B. komme ich bei den meisten Cores perfekt ohne Vsync aus. Da ist es nur wichtig, die höchste Hz Einstellung des Monitors zu wählen. Manche sehr alte Emulatoren wie Kega Fusion kommen auch ohne Vsync zurecht, wenn ich Freesync aktiviere. Aber Bsnes bleibt problematisch. Ohne Vsync habe ich, je nach Einstellungen, mal Tearing oder mal Sound Probleme. Keine Ahnung, aber vielleicht spielen die Grafik- und Soundtreiber da zusätzlich doch noch eine größere Rolle. Adaptive Sync in Bsnes selbt hilft hier nicht.

    gut zu wissen. Kannst du mir mal einen Beispiel Core für RetroArch nennen, wo du ohne aktiviertes Vsync auskommst ?

    Macht es in Bezug auf die Verwendung von Vsync einen Unterschied ob du einen Bsnes oder Higan Core in RetroArch verwendest, anstatt Bsnes / Higan direkt zu nutzen?

    Zitat

    Macht es in Bezug auf die Verwendung von Vsync einen Unterschied ob du einen Bsnes oder Higan Core in RetroArch verwendest, anstatt Bsnes / Higan direkt zu nutzen?


    Hatte ich ja schon erwähnt. Die Standalone Versionen verhalten sich bei mir ähnlich wie die Cores in RetroArch. Allerdings bin ich mir sicher, das Higan/Bsnes in älteren Versionen tatsächlich mal problemlos mit Freesync lief.

    Ja, genau. Bsnes v1.07 (vom 22.02.2019) läuft bei mir noch perfekt mit Freesync.

    Heute hab ich relativ viele Spiele durchprobiert mit aktiviertem RunAhead (manchmal auf 1 Frame eingestellt, manchmal auf 2 Frames, je nachdem, ob mein PC im jeweiligen Spiel dann die 50FPS schaffte) und es ist schon interessant, wie unterschiedlich sich das auch in den verschiedenen Games auswirkt. In "Dig Dug" etwa, merkt man so gut wie keinen Unterschied, das spielt sich mit 2 Frames RunAhead auch nicht anders als ohne diese Funktion, in anderen Spielen wiederum merkt man es schon deutlich, wie in "Giana Sisters" etwa.


    Das bestätigt auch diesen Satz hier

    Zitat von Retro-Nerd

    Kommt auf das System an, auch auf den Monitor und den Eingabe Geräten. Und natürlich auf die einprogammierten Frames Lag in den Spielen selber

    denn es ist wirklich auch sehr spielabhängig, wie ich heute nochmal erlebt habe.


    Schon eine interessante Sache das Ganze mit diesem RunAhead und auch wenn man bedenkt, wie der PC da im Hintergrund jetzt schuften muss, während man spielt, um das alles so zu ermöglichen. :) Jetzt haben die PC's mit Sachen wie der "Dynamik Rate Control" im Denise oder dem "Audio Clock Sync" im HOXS64 ja eh schon mehr im Hintergrund zutun, als es etwa früher bei den alten Emu's der Fall war und nun kommt das RunAhead dann noch mit drauf.


    Da ist jetzt schon einiges an Background-Arbeit nötig vom PC, um dem User das bestmögliche Retro-Spielvergnügen zu bescheren und der Spieler bekommt von der Schufterei im Hintergrund rein gar nichts mit, während er zockt, also zumindest wenn der User nicht soviele Frames RunAhead einstellt, dass sein PC den Fullspeed nicht mehr schafft, aber das macht dann ja keiner, nachdem man einmal herausgefunden hat, was der jeweilige PC im RunAhead noch schafft. Und dann läuft das so unbemerkt vom Spieler im Background und bringt das Spielgefühl noch ein Stück näher an den Originalrechner heran. Irgendwie cool das Ganze.

    Bsnes und Denise synchronisieren mittels 2 Verfahren. Sind diese beiden Verfahren deaktiviert, läuft der Emulator ungebremst.

    • Vsync: wie erwähnt, nicht im Emulator programmiert ... komplett über den Video Treiber gesteuert. Emulator wird vom Treiber gestoppt, bis Anzeige Dauer des aktuellen Bildes vorüber ist, abhängig von der Bildwiederholfrequenz.
    • Audio Sync: Audio Treiber weiß natürlich anhand der Sampling Frequenz die Spieldauer eines Samples. Der Emulator generiert im Abhängigkeit der Video Emulation die richtige Menge Samples, zu dem Zeitpunkt noch ungebremst. Der Audio Treiber blockiert dann, wenn zu viele Samples reinkommen und die aktuellen noch Spielen. Aus dem Grund bekommt man ohne Vsync ebenso die PAL/NTSC Geschwindigkeit hin, jedoch nicht präzise genug um dauerhaft Ruckel freies Video zu bekommen.

    RetroArch erledigt Audio Sync genau so. Ich habe es für DRC studiert.


    Meine Vermutung dafür warum einige Cores unter einem FreeSync Monitor ohne Vsync auskommen, könnte sein das diese nach jeder oder einer Gruppe von Bildzeilen zur PAL Frequenz synchronisiert werden und somit nicht ungebremst in RetroArch reinkommen. Eine Synchronisation nach einigen Bildzeilen stellt eine Art selbst gebautes Vsync dar und ist sicherlich präziser als audio Sync. Wird die Eingabe bei so einem selbst gebauten Vsync zwischendurch nicht gepollt, hat man jedoch die gleichen Nachteile wie mit dem Vsync der Grafikkarte. (unabhängig jetzt von runAhead)


    Ich las per Zufall in einem alten Changelog von Toni, das er vor ein paar Jahren LL-Vsync für Beam Racing wieder rausgeschmissen hat. Ich nehme an, das Beam Racing im Grunde das gleiche macht, nämlich nach einer Menge von Bildzeilen zur PAL/NTSC Frequenz zu synchronisieren um das Vsync am Ende des Bildes wieder loszuwerden.


    Nachtrag: Das soll jetzt nicht heißen Beam Racing und LL Vsync arbeiten identisch, nur das beide Verfahren nach einigen Zeilen synchronisieren.

    Zitat

    Ich las per Zufall in einem alten Changelog von Toni, das er vor ein paar Jahren LL-Vsync für Beam Racing wieder rausgeschmissen hat. Ich nehme an, das Beam Racing im Grunde das gleiche macht, nämlich nach einer Menge von Bildzeilen zur PAL/NTSC Frequenz zu synchronisieren um das Vsync am Ende des Bildes wieder loszuwerden.

    Beam Racing mit der Slice = 1 Einstellung ist vergleichbar mit dem älteren Low Latency Vsync. Schätze deshalb ist der in WinUAE rausgeflogen.


    Sorry, du wollest ja ein paar Cores wissen, die nur mit Freesync (und ohne Vsync) bei mir perfekt laufen. Dazu gehören z.B. Mednafen/Beetle PCE Fast, Genesis Plus GX, Vice, PUAE, SNES9x (und ältere Bsnes Cores wie die Mercury Versionen). Und das auch alles in Kombination mit Shadern und Runahead.


    Was mir da sonst noch aufgefallen ist, das viele Cores nicht gut mit Vulkan laufen (ruckelt und verschluckt mitunter mehrere Frames). Den braucht man aber eh nur zwingend für komplexere Emulationen wie den Low Level Emulator Parallel N64. Und da gibt es keine Probleme.

    Zitat von Retro-Nerd

    Beam Racing mit Slice =1 Setting ist vergleichbar mit dem Low Latency Vsync.

    ja. Bei mehr Slices ist der Unterschied, das Beam Racing nach jedem Slice (Gruppe von Bildzeilen) an die Grafikkarte übergibt. LL Vsync übergibt nur einmal wie normal auch.

    Was ich noch fragen wollte. Ist eigentlich mal eine Funktion im Denise angedacht zukünftig, bei der man eine Anzahl Bilder einstellen kann, die ausgelassen werden sollen? Etwa, wenn man den Emulator mal auf einem wirklich alten PC ausprobieren will, der bei voller Framezahl dann keinen Fullspeed mehr im Denise schafft? Es gibt ja scheinbar noch keine "automatic Frameskipping" Funktion im Denise und auch keinen Regler bislang, mit dem man eine Anzahl auszulassender Bilder einstellen kann.


    Bei höheren Frameskipping-Werten sind Games natürlich nicht mehr gut spielbar, aber einige Spiele, wie etwa viele Puzzlegames, lassen sich auch mit "skip every second frame" noch recht gut spielen. Da stört es dann nicht, wenn man auf dem ganz alten PC dann beispielsweise "Monster Buster" oder "Deflektor" mit konstant 25FPS spielt, Hauptsache man hat dann den Fullspeed im Denise.


    Ist sowas mal angedacht? Man könnte auch nur "automatic Frameskipping" anbieten, so ist es etwa im HOXS, aber viele Spiele zocken sich im Vergleich dazu, dann mit "skip every second frame" und dem damit verbundenen konstanten Frame-Wert (25 FPS) eigentlich besser, finde ich. Beides anzubieten, also automatisches Bilder-Auslassen und dazu noch einen Regler, mit dem man feste Skipping-Werte einstellen könnte, wäre ideal. Dann kann sich der User aussuchen, was er lieber verwenden will, falls es mal nötig sein sollte auf seinem PC um auf den Fullspeed zu kommen. Besteht da eine Chance, dass sowas in naher Zukunft kommt im Denise?


    Und noch eine Frage hinterher. Wie würde sich solch eine aktivierte Funktion dann eigentlich auf die RunAhead Funktion auswirken, wenn beides zugleich aktiviert wäre? Das kommt sich ja dann technisch wahrscheinlich in die Quere, oder? Aber selbst falls das so ist, wäre es ja sowieso eine aus und ein schaltbare Funktion, wie RunAhead es ja auch ist und somit dann unproblematisch, solange man es nicht zugleich nutzt.