Na, ein Ryzen 5 macht schon deutlich mehr Fahrt als ein i5 von 2011 
Eingabe Latenzen in Emulatoren
- PiCiJi
- Thread is Unresolved
-
-
Hmm, habs mal ausprobiert. Mein i5 4690k@3,9Ghz (auch schon länger nicht mehr das modernste) macht die 4 Frames auch recht locker mit um die 32% CPU Last.
Aber ehrlich gesagt würde ich mich auch über 2 Frames Runahead bei Denise sehr freuen, das fühlt sich ja in der Tat brutal viel direkter an.
Edit: Und ich hab ja auch keine Ahnung von Emulatorenentwicklung, kann ja durchaus sein dass da von System zu System große Unterschiede bestehen was die Umsetzung angeht.
-
Ich denke auch, das 4 Frames für fast jedes System dicke ausreichen wird. Schon ab 2 merkt man einen deutlichen Unterschied zu vorher.
-
Ok, ich bin irritiert. Wollte mal sehen wie das so ist ohne Run-Ahead bei dem selben Emulator und es gibt vielleicht 1-2% unterschied bei der CPU Last, falls man das überhaupt so genau sagen kann.
Hab ich mir da nur nen Unterschied eingebildet oder macht der Emu das tatsächlich nur mit minimalem Performancehit? Das liegt ja fast noch innerhalb der Messtoleranz.
-
Fordert die 100% cycle exakte Emulation soviel Power in Verbindung mit Runahead?
klares ja. Denise verwendet aktuell nur die Pixel für Pixel Methode.
Welchen Core verwendest du bei bsnes? Nur der accuracy core verwendet die Pixel genaue Emulation. Performance und Balanced haben einen Scanline Renderer.
Beim SNES gibt es wohl nur 2 Spiele, welche eine Pixel genaue Emulation der Grafikhardware benötigen. Ich hoffe beim C64 ist das ähnlich, glaube ich aber nicht, da hier viel intensiver die Hardware ausgereizt wird.
Ich bin gespannt, was du mit dem Ryzen rausholst. Davon abhängig werde ich mir neue Hardware zulegen.
Naja, wenn Spiele eh nicht die komplett 100% Zyklus exakte Emulation brauchen könnte man die doch nur für Demos zuschaltbar machen. Und Demos brauchen dann eh keine Runahead Funktion.
sehe ich genau so. Ich habe jedoch keine Vorstellung wieviele Spiele mit einem Scanline basierten Renderer Probleme haben. Es ist unschön, das der user das rausfinden muss. Aus dem Grund wollte ich sowas gar nicht anbieten. RunAhead zwingt mich dazu, denn auf dieses Feature will ich nicht verzichten. An der Stelle will ich dem user mehrere Möglichkeiten an die Hand legen.
1. RunAhead mit VIC-II cycle accuracy über alle Frames (kompromisslos, schonungslos )
2. RunAhead mit VIC-II cycle accuracy, jedoch nur das sichtbare Frame
3. RunAhead mit VIC-II scanline accuracy über alle Frames
4. RunAhead mit VIC-II scanline accuracy, jedoch nur das sichtbare Frame
Wobei die Scanline Option nicht an RunAhead gebunden sein wird.
-
Und ich hab ja auch keine Ahnung von Emulatorenentwicklung, kann ja durchaus sein dass da von System zu System große Unterschiede bestehen was die Umsetzung angeht.
Das Problem beim C64 im Gegensatz zum SNES z.B. ist der das der VIC den Hauptprozessor stoppen kann. Aus diesem Grund kann man die Emulation der Grafikhardware nicht komplett vom Netz nehmen.
-
An der Stelle will ich dem user mehrere Möglichkeiten an die Hand legen.
Du erstellst doch gerade einen neuen Emulator, der exakter als andere sein und noch nie dagewesene Funktionen bei C64-Emulatoren bieten soll.
Da stellt sich mir die Frage, warum überhaupt noch "alte" Emulations-Techniken verwenden? Das erzeugt zahlreiche Varianten, die alle geschrieben, getestet und gepflegt werden müssen. Und das alles "nur", um auch ältere Rechner zu untersützen.
Den Aufwand könntest Du stattdessen auch in neue Feature stecken. Das wäre aus meiner Sicht lohnenswerter. Du hast doch auch selbst gesagt, dass Du sicherlich noch einige Zeit brauchen wirst, bis der Emulator so ist, wie Du ihn Dir vorgestellt hast. In dieser Zeit werden die PCs entsprechen im Schnitt nochmal deutlich schneller werden, so dass Du am Ende ein Problem löst, welches evtl. nur noch recht wenige Benutzer betrifft. Und die hätten mit anderen Emulatoren ja auch bereits für Sie gute Alternativen.
Ein Gedanke noch: Du könntest ja beim ersten Ausführen einen Systemtest machen und dann die Einstellungen entsprechend vorkonfigurieren.
-
Da stellt sich mir die Frage, warum überhaupt noch "alte" Emulations-Techniken verwenden? Das erzeugt zahlreiche Varianten, die alle geschrieben, getestet und gepflegt werden müssen. Und das alles "nur", um auch ältere Rechner zu untersützen.
Die Frage muss noch geklärt werden, ob es nicht auch bei aktuellen Rechnern zu langsam wird. Die Antwort bekomme ich erst, wenn ein paar Leute das nächste nightly auf besserer Hardware, als ich sie habe, testen.
Ein Grund warum ich mir noch keine aktuellere CPU gekauft habe, liegt darin das ich den Eindruck habe, die Geschwindigkeit einzelner Kerne erhöht sich gar nicht mehr so arg. Emulatoren lassen sich nicht gut auf mehrere Kerne skalieren. In der Regel verbraucht die Synchronisation mehr Performance, als die verteilte Arbeit auf mehreren Kernen einbringt.
Ich warte hier einfach mal auf die Ergebnisse. Ich bekomme mit Denise im Basic Screen ohne RunAhead ca. 180 fps. Ein user meinte mal hier auf über 300 fps zu kommen, das lässt hoffen.
-
Wenn ich alles ausschalte (Video/Audio Sync, CRT etc.) bekomme ich knapp 220fps im Basic Schirm, 450fps mit dem aggressiven vorspulen.
-
Ok, ich bin irritiert. Wollte mal sehen wie das so ist ohne Run-Ahead bei dem selben Emulator und es gibt vielleicht 1-2% unterschied bei der CPU Last, falls man das überhaupt so genau sagen kann.
Hab ich mir da nur nen Unterschied eingebildet oder macht der Emu das tatsächlich nur mit minimalem Performancehit? Das liegt ja fast noch innerhalb der Messtoleranz.
Der Autor meint er hat pro Frame ca. 40 % overhead, da die Grafikeinheit des SNES in den unsichtbaren Frames abgeschalten wird.
Für Vergleiche ist der Taskmanager ungünstig, wenn der Emu auf PAL gedrosselt läuft.
Am Besten ist es die syncing Optionen, wie audio und video sync abzuschalten, fps Anzeige direkt im Emulator anschalten. Dann versuchen bsnes und denise den Emulator so schnell wie möglich laufen zu lassen.
Hier kann man dann schön sehen wie stark runAhead den Emulator belastet.
Ok habe mir die letzte bsnes 115 angeschaut. Vergiss die Frage mit dem Core. Das ist ja in bsnes jetzt anders. Ich habe mich zu lange nicht mehr mit dem SNES beschäftigt.
So nun habe ich mich auf den neusten Stand gebracht.
In bsnes gibt es die Option Fast PPU. Ist diese aktiviert, wird der Scanline basierte Renderer verwendet, andernfalls der Zyklen genaue. Die Option lässt sich zwar im laufenden Betrieb umschalten, wird jedoch erst angewandt, wenn das Spiel neu geladen wird.
bsnes: meine Resultate
Fast PPU: an, RunAhead: 0(aus) = 280 fps, 1 = 165 fps, 2 = 124 fps, 3 = 99 fps, 4 = 82 fps
Fast PPU: aus, RunAhead: 0(aus) = 80 fps ... weiter brauch ich gar nicht probieren, dann schaffe ich die 60 fps nicht mehr
Zyklen genaue Emulation der Grafikhardware
bsnes schafft bei mir 80 fps und denise 180 fps im Basic Screen und ca. 155 fps in Spielen. Das SNES muss über 100 unabhängige Sprites berechnen. Das erklärt den Unterschied.
-
Wenn ich alles ausschalte (Video/Audio Sync, CRT etc.) bekomme ich knapp 220fps im Basic Schirm, 450fps mit dem aggressiven vorspulen.
soviel ist das nicht schneller, als meine 180 fps. Ich denke RunAhead und Zyklen genaue Emulation der Grafikeinheit werden keine Freunde.
-
Wahrscheinlich, aber wie gesagt: Demos brauchen Runahead ja nicht. Und ich kann mir auch kaum Spiele vorstellen, die diese Pixel für Pixel Methode wirklich benötigen. Letztlich interessieren sich 95% der Leute eh nicht für Input Lag verringernde Maßnahmen, und optional ist das ja eh, bzw. per Default ausgestellt.
-
Da stellt sich mir die Frage, warum überhaupt noch "alte" Emulations-Techniken verwenden? [...] Und das alles "nur", um auch ältere Rechner zu untersützen.
Ich finde es löblich, auch ältere Hardware zu unterstützen. Ich fand es schade, dass das VICE-Team bei den aktuellen Versionen die "normale" Variante durch die rechenaufwändigere SC-Variante ersetzt (und erstere gecancelt) hat. (ein weiterer Grund für mich, auf ältere Versionen zu setzen). Für mich als reiner Spiele-Nutzer bringt die SC-Version keinerlei Vorteile, nur der Notebook-Lüfter dreht früher hoch. Aus akademischer Sicht macht die möglichst genaue Emulation sicherlich den Entwicklern mehr Spaß – ich als User beziehe aber durchaus mit ein, wie "gut" ein Emu auf meiner Hardware läuft. Von daher bin ich immer dafür, wenn ich Möglichkeiten in der Emulation vorfinde, die Performance zu steigern bzw. die CPU-Last zu reduzieren.
-
Okay, mal testen.
Testsetup:
bsnes
Frameskip bei fast forward: 0
Mute while fast forwarding: off
Video und audio synchronize: off (das meintest du, oder?)
ROM: Donkey Kong Country, erstes Level direkt am Start
PPU Fast mode: off
Run-ahead disabled
FPS: 95
Run-ahead 1 Frame
53 fps. Also schon verkackt.
PPU Fast mode: on
Run-ahead off
FPS: 315
Run-ahead 1 Frame
FPS: 198
Run-ahead 2 Frames
FPS: 154
Run-ahead 3 Frames
FPS: 124
Run-ahead 4 Frames
FPS: 104
Die aktuelle Denise Nightly hat noch keinen Run-Ahead, sehe ich das richtig?
-
Video und audio synchronize: off (das meintest du, oder?)
ja
Die aktuelle Denise Nightly hat noch keinen Run-Ahead, sehe ich das richtig?
in ein paar Tagen kommt die erste Test Version von runAhead, jedoch in Verbindung mit einem Zyklen akkuraten Renderer. Scanline Variante folgt danach.
Run-ahead 1 Frame
53 fps. Also schon verkackt.
Hier sieht man gut, das selbst auf besseren CPU's eine Zyklen akkurate Emulation der Grafikeinheit zu teuer für ein Feature wie RunAhead ist. Die CPU steht so arg unter Last, das weitere zugeschaltete Features wie Shader, DRC usw. das Fass schnell zum Überlaufen bringen.
-
Ui, in ein paar Tagen schon. Bin gespannt und teste natürlich alles aus, was du an Infos brauchst.
-
Ich habe jedoch keine Vorstellung wieviele Spiele mit einem Scanline basierten Renderer Probleme haben. Es ist unschön, das der user das rausfinden muss.
Sollte nicht so schlimm sein, es selbst herausfinden zu müssen, da der User ja auch immer die Möglichkeit hat, Funktionen wie Runahead aus oder ein schalten zu können. Wenn dies dann beispielsweise auch noch per Hotkey erledigt werden kann, sollte es kein grosses Problem mehr sein. Etwas ärgerlich wäre nur, wenn ein Spiel damit Probleme hätte und sich diese aber nicht gleich von Anfang an zeigen, sondern erst irgendwann später im Spielverlauf, schlimmstenfalls wenn man im Spiel schon recht weit ist. Solche Sachen könnten dann, bis man einmal herausgefunden hat, welche Spiele damit Probleme haben, vielleicht ein paar Nerven kosten. Zeigt sich ein Problem gleich von Anfang an, ist es nicht wirklich schlimm, schaltet man einfach kurz per Hotkey die Runahead Funktion aus oder auf einen anderen Renderer um und gut ist es.
-
Hier sieht man gut, das selbst auf besseren CPU's eine Zyklen akkurate Emulation der Grafikeinheit zu teuer für ein Feature wie RunAhead ist. Die CPU steht so arg unter Last, das weitere zugeschaltete Features wie Shader, DRC usw. das Fass schnell zum Überlaufen bringen.
Shader usw hatte ich eh an. Bringt ja nix wenns flüssig läuft aber nur im Winzfenster ohne alles.
-
Das sieht doch schon mal sehr gut aus!
Im akkuraten Modus kann ich auf bis zu 3 Frames und im performanten auf bis zu 7 Frames gehen bei voller Framerate. Absolut brauchbar! Getestet mit Giana Sisters, erstes Level.
Nachtrag: Der Emulator ist mir jetzt allerdings bereits 2 mal abgeschmiert. Emulation bleibt hängen, in der Kopfzeile des Fensters steht (Keine Rückmeldung).
Einmal bei Giana Sisters, einmal bei Blue Max. Beide Male 3 Frames im akkuraten Modus.
