Hello, Guest the thread was called4.3k times and contains 165 replays

last post from AW182 at the

Eingabe Latenzen in Emulatoren

  • Was mir da sonst noch aufgefallen ist, das viele Cores nicht gut mit Vulkan laufen (ruckelt und verschluckt mitunter mehrere Frames).

    hmm, möglicherweise auch ein RetroArch Bug. Schwer vorzustellen, das der openGL Nachfolger das nicht hinbekommt.


    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 mal testen will, der bei voller Framezahl dann keinen Fullspeed mehr schafft. Es gibt ja scheinbar noch keine "automatic Frameskipping" Funktion und auch keinen Regler mit dem man eine Anzahl auszulassender Bilder einstellen kann.

    da müsste ich mich schon sehr überwinden. Als ich 1998 oder 1999 meine ersten Snes Spiele emuliert habe, musste ich immer jedes 2. Bild auslassen um auf damaligen PC's sowas wie Fullspeed hinzubekommen.

    Wird der Spieler getroffen, blinkt er ne zeitlang. Wenn du Pech hattest und das 2. Frame auf den unsichtbar Zustand fiel, konntest du deinen Haupt Character ne Zeit lang nicht sehen. Ich bin da ein Bisschen vorbelastet.

  • da müsste ich mich schon sehr überwinden. Als ich 1998 oder 1999 meine ersten Snes Spiele emuliert habe, musste ich immer jedes 2. Bild auslassen um auf damaligen PC's sowas wie Fullspeed hinzubekommen.

    Wird der Spieler getroffen, blinkt er ne zeitlang. Wenn du Pech hattest und das 2. Frame auf den unsichtbar Zustand fiel, konntest du deinen Haupt Character ne Zeit lang nicht sehen. Ich bin da ein Bisschen vorbelastet.


    Für schnelle Actionspiele kann man das natürlich vergessen, ist klar, da leidet die Spielbarkeit dann logischerweise merklich darunter, aber bei vielen der schon erwähnten Puzzlespielen, macht ein "skip every 2nd frame" im Gameplay eigentlich nicht viel aus. Und bei Strategiespielen, Brettspielen und sonstigen rundenbasierten Games schon gar nicht, aber man hätte dafür dann auf alten Rechnern, immer den Fullspeed in solcherlei Spielen im Denise.


    Auf meinem Dingoo A320 Handhelds zocke ich beispielsweise öfter mal die Gameboy-Advance Version von "Dr. Mario" per GBA-Emulator und dazu muss ich, um im Spiel konstant den NTSC-Fullspeed zu haben, ebenfalls jedes zweite Bild auslassen. Das Game spielt sich dann aber noch nahezu genausogut wie ohne Frameskip und ich bin froh, dass ich zumindest auf diese Art, dann den Fullspeed erreichen kann und das Spiel dann recht gut auf diesem Handheld unterwegs zocken kann.


    Da bin ich am Dingoo mehreren der dortigen Emulatoren dankbar, dass sie eine Frameskipping-Funktion anbieten und deshalb denke ich, es könnte auch am Denise einen gewissen Sinn machen, weil der Emu dann auch auf solchen Rechnern noch in einigen Spielen recht gut nutzbar wäre, auf denen er sonst nie den Fullspeed schaffen würde und diese Spiele dann viel zu langsam laufen würden. Wenn es also technisch gesehen keinen riesigen Aufwand darstellt, sollte man eventuell nochmal über solch eine Funktion nachdenken. Für Strategie-, Puzzle-, Brett- und sonstige rundenbasierte Games, wäre das eine tolle Sache, wenn man einen alten Zweit-PC hat, auf dem der Denise sonst zu langsam laufen würde.

  • Eine Sache kam mir eben noch in den Sinn, die ich fragen beziehungsweise erwähnen wollte und zwar kann ich beim HOXS64 gut beobachten, dass ich diesen Emu um einiges schneller bekomme im Warp-Modus, wenn ich, etwa beim zocken eines Onefilers, die "1541 Emulation" nach dem Laden von diesem ausschalte (oder wenn ich den Onefiler als einzelnes prg lade). Ebenso muss ich auf meinem alten PC (Pentium3, 800MHz), wenn ich im HOXS64 überhaupt Fullspeed ohne Frameskipping haben will, ebenfalls die 1541 Emulation abschalten, sonst komme ich dort gar nicht auf die vollen 50 FPS. Also Onefiler kann ich dann am alten PC damit in Fullspeed spielen, bei Nachladern sieht es eher schlecht aus (aber ich hab Fullspeed im CCS64 dort).


    Nun aber die Frage in Verbindung mit der neuen RunAhead Funktion, bei der etwas mehr Speed ja nie schaden kann. Könnte man eine zuschaltbare Funktion im HOXS64 entwickeln, die immer dann die 1541-Emulation komplett abschaltet, wenn das Floppy gerade nicht benötigt wird und die es dann immer wieder automatisch in den Momenten zuschaltet, wenn ein Programm das 1541 benötigt? Sodaß die Emulation des 1541 nicht die ganze Zeit mitlaufen und die CPU belasten muss, wenn das Floppy oftmals gar nicht benötigt wird? Denn ich nehme mal an, die läuft ja momentan permanent mit, oder?


    Das ist als Vorschlag gedacht, noch mehr Speed herauszuholen, damit man auch 2 Frames RunAhead auf schon etwas älteren PC's nutzen kann. Mein PC ist nah dran, dies mit 50 FPS Fullspeed zu schaffen im performanten Modus, aber viele Spiele laufen dann bei irgendwas um die 45 bis 48 FPS. Gäbe es da die Möglichkeit die 1541 Emulation abzuschalten, würde das mit Sicherheit die paar noch fehlenden FPS mehr bringen um permanent die 50 FPS halten zu können.


    Sollte es nicht möglich sein, solch eine Funktion mit automatischem Mechanismus zu integrieren, dann wäre es schon von Vorteil, eine anklickbare Funktion zu haben, um die "1541 Emulation" einzeln abschalten zu können. Für Onefiler würde auch das schon genügen und viele Spiele sind ja Onefiler, bei Nachlade-Spielen wäre natürlich eine Automatik von Vorteil, denn sonst verpasst man vielleicht am Ende eines Levels wenn der nächste geladen werden soll, die Floppy-Emulation vorher schnell manuell wieder einzuschalten und dann hängt sich das Game auf. :)


    Die Floppy-Emulation abzuschalten bei Onefilern, bei denen man das Floppy eh nicht braucht, oder bei Nachladern in den Momenten in denen man das 1541 gerade nicht braucht, wäre auf jedenfall besser, um mehr Speed für RunAhead rauszuholen, als den vsync immer abzuschalten, weil es sich überhaupt nicht bemerkbar machen würde, solange das Floppy nicht vom Spiel wieder benötigt wird. Ich weiss jetzt nicht genau, wieviel Geschwindigkeit man da dann rausholen kann, wenn das 1541 nicht mehr emuliert wird, richtig viel wird es nicht sein, aber etwas bestimmt. Was meinst du PiCiJi?

  • Die Floppy-Emulation abzuschalten bei Onefilern, bei denen man das Floppy eh nicht braucht, oder bei Nachladern in den Momenten in denen man das 1541 gerade nicht braucht, wäre auf jedenfall besser, um mehr Speed für RunAhead rauszuholen, als den vsync immer abzuschalten, weil es sich überhaupt nicht bemerkbar machen würde, solange das Floppy nicht vom Spiel wieder benötigt wird. Ich weiss jetzt nicht genau, wieviel Geschwindigkeit man da dann rausholen kann, wenn das 1541 nicht mehr emuliert wird, richtig viel wird es nicht sein, aber etwas bestimmt. Was meinst du PiCiJi?

    Die Floppy Emulation verbraucht schon einiges in der C64 Emulation. Das liegt daran, das der Floppy ein eigener Computer ist, nur ohne Sound -und Grafikkarte. Beim Amiga ist der Hauptprozessor schnell genug und somit muss hier keine extra Floppy CPU + 2 VIA Chips emuliert werden. Ich überlege mir hier mal was.

  • Die Floppy Emulation verbraucht schon einiges in der C64 Emulation. Das liegt daran, das der Floppy ein eigener Computer ist, nur ohne Sound -und Grafikkarte. Beim Amiga ist der Hauptprozessor schnell genug und somit muss hier keine extra Floppy CPU + 2 VIA Chips emuliert werden. Ich überlege mir hier mal was.


    Dann bestätigt sich mein Verdacht, den ich wegen dem HOXS hier gewinnen konnte, dass es doch einiges ausmacht. Super, dann könnte ich auf meinem PC hier durch diese Art wahrscheinlich die fehlenden paar Frames zum 50FPS Fullspeed noch rauskratzen, wenn 2 Frames RunAhead eingeschaltet sind. :)


    Bei Onefilern auf einer Disk, wird das Floppy nach dem Start des Programms ja eh nicht mehr benötigt, da ist es gar kein Problem. Hier würde selbst eine manuell bedienbare Klickfunktion namens "Turn off 1541-Emulation" schon ausreichen, wenn es um solche Onefiler geht. Andere Medien würde von solch einer Klickfunktion natürlich auch profitieren, denn während etwa ein Cartridge oder ein Tape läuft oder ein prg-File (Onefiler der nicht auf einer Disk ist), braucht man die 1541 ja ebenfalls nicht.


    Und falls es technisch irgendwie machbar wäre, dass sich die 1541-Emulation bei Disk-Nachladern in den Momenten in denen nicht geladen wird, automatisch vollständig abschaltet, dann wäre das auch eine super Sache um noch Speed für die RunAhead Funktion aus den ganzen User-PC's rauszuholen. Ich weiss nur nicht, wie es dann technisch gut umsetzbar ist, dass sich die 1541-Emulation jedesmal wieder automatisch einschaltet, wenn ein Nachlader das Floppy innerhalb des Spielverlaufs dann irgendwann wieder benötigt. Nicht dass in solchen Momenten das Floppy dann irgendwie "zu spät dran" ist jedesmal, weil es sich vor dem lesen oder schreiben ja zunächst immer erstmal wieder automatisch einschalten müsste. Keine Ahnung ob das nicht irgendwelche Timing-Probleme verursachen könnte, oder wie tolerant da dann Lese- und Schreibvorgänge auf die Diskimages sind? Aber einen Versuch wär's wert.

  • Ich finde in den Nightlies Link kein ausführbares Binary - muss ich mir das selbst kompilieren, wenn ich es auch geren mal Testen würde?

    nein die binaries sind ein Bisschen versteckt. Hier das Windows binary

    Win64 Binary

    Dann bestätigt sich mein Verdacht, den ich wegen dem HOXS hier gewinnen konnte, dass es doch einiges ausmacht. Super, dann könnte ich auf meinem PC hier durch diese Art wahrscheinlich die fehlenden paar Frames zum 50FPS Fullspeed noch rauskratzen, wenn 2 Frames RunAhead eingeschaltet sind.

    Bald kommt der scanline basierte Renderer. Das sollte dann nochmal einiges bringen.


    Schon jetzt kannst du schauen, wieviel extra FPS dir eine ausgeschaltete Laufwerks Emulation einbringen würde. Dazu einfach alle Diskettenlaufwerke abschalten und das PRG des ONE Filers mit einem Tool wie DIR Master extrahieren und starten.

  • Schon jetzt kannst du schauen, wieviel extra FPS dir eine ausgeschaltete Laufwerks Emulation einbringen würde. Dazu einfach alle Diskettenlaufwerke abschalten ...

    Tatsächlich, das geht ja bereits. 8\| Oh man, das war mir nicht klar bislang. Zwar hatte ich diese "Diskettenlaufwerke" Funktion in der Systemverwaltung schon zuvor gesehen, aber noch nie benutzt und immer gedacht, man könne damit nur zwischen 1 und 4 emulierte Floppies umstellen. Dass man dort aber auch 0 Floppies einstellen und damit dann die 1541 abschalten kann, wusste ich nicht. Da hätte ich wohl doch mal einen Blick reinwerfen sollen in diese Funktion, dann wäre es zu sehen gewesen.


    Und tatsächlich bringt das Abschalten der 1541 bei mir am PC, etwa im Spiel "Microprose Soccer", dann auch die bislang noch fehlenden 4 bis 5 Frames und ich habe dann in diesem Spiel konstant 50 FPS mit 2Frames RunAhead im performanten Modus (der performante Modus bedeutet bei diesem Spiel auch keinen Nachteil, da die Spritekollisionen Spieler-Ball-Gegner auch damit noch funktionieren). Im akkuraten Modus schaffe ich auch mit ausgeschalteter 1541 keine 50FPS mit 2Frames RunAhead, aber immerhin mit 1 Frame RunAhead.


    Und im Warp Modus hab ich mir den Unterschied, mit und ohne emulierter Floppy, auch nochmal angesehen und verglichen:


    - vorspulen aggressiv im BASIC Screen mit eingeschalteter 1541 = um die 270 FPS auf meinem PC

    - vorspulen aggressiv im BASIC Screen mit ausgeschalteter 1541 = um die 330 FPS dann bei mir hier


    Macht also schon ein bisschen was aus, wie man sieht, und wenn man das Floppy eh nicht braucht, kann man es auch abschalten.


    Eine Frage noch hierzu. Bislang kann man die Anzahl der Floppies im Denise ja nur ändern, wenn der C64 ausgeschaltet ist, also wie beim echten C64. Aber wäre es auch möglich, eine Funktion namens "turn off 1541" in die Hotkeys mit aufzunehmen, die quasi das gleiche macht wie in der Systemverwaltung auf 0 Floppies umzustellen, dies aber auch on-the-fly hinbekommen würde? Dann könnte man in Onefiler-Spielen, bei denen man, wenn sie gerade laufen, bemerkt, dass man einen kleinen Geschwindigkeits-Boost für den RunAhead brauchen könnte, auf die Schnelle immer per Hotkey das 1541 abschalten. Ginge das umzusetzen während der C64 läuft, oder ist dafür ein Reset zwingend notwendig?


    Gruß,

    Andreas

  • Eine Frage noch hierzu. Bislang kann man die Anzahl der Floppies im Denise ja nur ändern, wenn der C64 ausgeschaltet ist, also wie beim echten C64. Aber wäre es auch möglich, eine Funktion namens "turn off 1541" in die Hotkeys mit aufzunehmen, die quasi das gleiche macht wie in der Systemverwaltung auf 0 Floppies umzustellen, dies aber auch on-the-fly hinbekommen würde?

    nur wenn die optionale automatische Abschaltfunktion nicht zuverlässig funktioniert. Ich werde die vergangene Zeit seit der letzten Kommunikation zwischen C64 und Laufwerken tracken. Ist diese größer als X, wird die Laufwerks Emulation deaktiviert und sofort wieder aktiviert bei erneutem Kommunikationsversuch. Möglicherweise machen das Spiele mit komplexen Loadern nicht mit. One Filer sollten damit aber kein Problem haben.

    Zuerst jedoch der Scanline basierte Renderer. Die ersten Tests mit dem Scanline basierten Renderer bringen mir 4 RunAhead Frames im akkuraten Modus ein. Das macht Hoffnung.


    Zudem werde ich alle Performance vs Accuracy Optionen in eine eigene Rubrik packen.

    • Scanline Renderer
      • nicht akkurat genug für etliche DEMO's
    • Scanline Renderer in extra thread (*)
      • kitzelt bei mir noch mal 20 fps raus, CPU Last steigt aber deutlich an
    • Disk Emulation (ehemals Disk Core 100%) in extra thread
      • aktiviert oder deaktiviert
        • die Disk Emulation läuft nur parallel zum C64 in einem extra thread, wenn keine Kommunikation zwischen beiden vorliegt.
      • deaktiviert
        • läuft unsynchronisiert parallel für 1000 Zyklen oder bis Kommunikation einsetzt
        • thread steht nicht unter Volllast, kann also kurz einschlafen und wieder aufwachen
      • aktiviert (*)
        • läuft unsynchronisiert parallel für 100 Zyklen oder bis Kommunikation einsetzt
        • thread steht unter Volllast
        • nur sinnvoll, wenn mehr als 2 Laufwerke emuliert werden
    • Disk Emulation bei Nicht Verwendung temporär deaktivieren (neu)
    • Echtzeit Audio Filter in extra thread (ehemals SID Hazard)
      • deaktiviert
        • der RESID arbeitet mit vorberechneten Werten. Es lassen sich jedoch nicht alle Werte vorberechnen. Also werden die zugrunde liegenden physikalischen Modelle etwas vereinfacht.
      • aktivert (*)
        • die aufgrund ihrer Varianz nicht vorberechenbaren Werte werden in Echtzeit in einem parallelen thread berechnet, welcher jeden verdammten Zyklus synchronisieren muss.
        • deutlich langsamer trotz extra thread, Verbesserung liegt möglicherweise im nicht hörbaren Bereich
        • wenn ich wieder Zeit für den SID habe, geht das Thema in die nächste Runde. Deswegen im Moment nur der Vollständigkeit halber erwähnt.


    (*) jeweils ein extra CPU Kern auf 100% Last. Wenn parallele Abarbeitung in der Emulation einen Geschwindigkeits-Vorteil bringen soll, darf der extra thread nicht einschlafen, wenn er gerade nix zu tun hat. Das spätere Aufwachen dauert viel zu lange. Leider ist dann ein CPU Kern auf 100%.

    Aus dem Grund gibt es die vielen Optionen um sich abhängig der Anzahl Kerne, Laptop Betrieb und den eigenen Erwartungen das Geeignetste einzustellen.

  • Ich werde die vergangene Zeit seit der letzten Kommunikation zwischen C64 und Laufwerken tracken. Ist diese größer als X, wird die Laufwerks Emulation deaktiviert und sofort wieder aktiviert bei erneutem Kommunikationsversuch. Möglicherweise machen das Spiele mit komplexen Loadern nicht mit. One Filer sollten damit aber kein Problem haben.

    Hört sich sehr gut an und bei Demos die ja häufiger komplexere Loader als die meisten Spiele haben, weil in Demos ja zumeist immer Musik und Grafikeffekte nebenher weiterlaufen müssen während im Hintergrund schon der nächste Part gleichzeitig geladen wird, braucht man den Geschwindigkeitsboost ja eigentlich eh nicht, weil ein aktivierter RunAhead in Demos ja eh keinen Sinn macht. Bietet sich also echt an für Spiele, was du vorhast, denn ich denke das wird dann auch mit den meisten der dortigen Loader funktionieren.


    Zuerst jedoch der Scanline basierte Renderer. Die ersten Tests mit dem Scanline basierten Renderer bringen mir 4 RunAhead Frames im akkuraten Modus ein. Das macht Hoffnung.

    Da bin ich auch gespannt drauf, mal sehen wie das wird und vor allem, wie das dann aussieht?


    Zudem werde ich alle Performance vs Accuracy Optionen in eine eigene Rubrik packen.

    Auch das ist eine gute Idee. Wenn es dann zusätzlich dazu nämlich demnächst auch noch die Möglichkeit gibt, eigene Settings in Files mit eigens dafür vergebenem Namen abspeichern zu können (sowas wie "save settings to specified file"), dann kann sich jeder User eine kleine Liste mit verschiedenartig vorkonfigurierten Geschwindigkeitseinstellungen als verschiedene Settings ini-Files abspeichern, die genau zu seinem PC passen und dann bei Bedarf immer ganz schnell wieder in den Emu hineingeladen werden können, wenn man sie benötigt.


    • Scanline Renderer
      • nicht akkurat genug für etliche DEMO's

    Was jetzt nicht so schlimm wäre, denn während Demos laufen, braucht man den RunAhead, beziehungsweise den dafür nötigen Speed-Boost, dann ja eh nicht, wie schonmal angesprochen.


    • Echtzeit Audio Filter in extra thread (ehemals SID Hazard) ...

    Genau, bei der Audio-Emulation kann man dann vielleicht auch noch das ein oder andere Prozent Geschwindigkeit rauskratzen, denn die Sound-Emulation kann man ja bislang im Denise noch gar nicht auf "weniger akkurat" stellen, wie etwa im WinVICE bei dem man auf "FastSID" umschalten kann oder im HOXS, bei dem ein Umschalten auf "Downsample" dann noch etwas Speed rausholt.


    Da wäre in Hinsicht "auf einen schlechteren Filter switchen zu können" wahrscheinlich auch noch Spielraum im Denise vorhanden, etwas Speed rauszuholen für die RunAhead Funktion? Leute die einen ganz modernen Rechner haben, die haben es dann natürlich am besten, die müssen für mehrere Frames RunAhead im akkuraten Modus, rein gar nichts der anderen Settings zurückdrehen oder umstellen. :) Aber es ist schonmal sehr gut, dass man diese Möglichkeiten dann zukünftig überhaupt hat, für PC's die schon ein bisschen älter sind. Ich hoffe damit dann auf meinem Rechner dauerhaft 2 Frames RunAhead im akkuraten Modus rausholen zu können in so gut wie allen Games, das fühlt sich für mich hier dann wie am echten C64 an und wäre perfekt zum zocken.

  • neues nightly:


    Unter System Verwaltung steht die neue Rubrik "Akkuratheit und Leistung" bereit. Einige bereits vorhandene Optionen wurden aus dem Feature Bereich in diesen neuen Bereich verschoben. Dieser Aufräum Vorgang mündet später darin, das die Bereiche Region, Chipset und Feature zu einer Rubrik 'Model' verschmelzen werden.


    Akkuratheit & Leistung

    Diese Optionen beschreiben nun das Verhältnis zwischen Akkuratheit und Performance. Mit Ausnahme des Scanline basierten Renderers sind diese Einstellungen nicht Teil des Spielstandes. Der geladene Spielstand übernimmt also die aktuell eingestellten Werte.


    Zyklus akkurates Video (NEU)

    Dies wechselt zwischen dem Zyklen und Scanline basierten Renderer. Wird während der Emulation umgeschaltet, erscheint eine Frage zum Reset des Emulators.

    Bitte für den neuen Scanline basierten Renderer keine BUG Reports für Demos übermitteln. Ansonsten passiert das wovor Sokrates gewarnt hat und ich vergeude viel Zeit damit Hacks zu produzieren.


    Bildzeilen Thread (*) (NEU)

    Lastet einen CPU Kern zu 100% aus und beschleunigt den Scanline basierten Renderer zusätzlich. Dies ist in erster Linie sinnvoll für RunAhead.


    Disk Thread (*)

    Lastet den Thread ( somit einen CPU Kern) für die Disk Emulation zu 100% aus anstatt diesen zeitweise in den Sleep Modus zu versetzen. Dies ist besonders effektiv, wenn der Thread mehr zu tun hat, z.B. beim Emulieren von 3 oder 4 Laufwerken.


    Disk Emulation bei Bedarf (NEU)

    Wird die Leitung zu den Floppy ca. 60 Bilder nicht angesprochen, schaltet nun die Disk Emulation komplett ab bis eine neue Kommunikation einsetzt. Einige Loader könnten eventuell Probleme bekommen.

    Ich empfehle dennoch, diese Option zu benutzen. Es entlastet den Emulator ziemlich.


    Audio Thread (*)

    Die physikalischen Modelle für die Filter werden in Echtzeit berechnet, wenn eine Vorberechnung nicht möglich ist. Diese Option kostet richtig viel und die Verbesserung ist für mich nicht hörbar. Ich empfehle diese Option daher nicht.


    (*) Diese Optionen lasten jeweils einen CPU Kern zu 100% aus. Für Geräte die aufgrund ihre Energie Einstellungen in solchen Situation drosseln, ist dies kontra produktiv. Ebenso auf Single oder Dual Core Prozessoren würde ich dies vermeiden.


    Im globalen Bereich des Emulators unter Video befindet sich noch eine weitere Performance Option, welche ich hier nur der Vollständigkeit halber erwähne. Video / CRT Emulation / extra Thread.

    Diese Option bezieht sich ausschließlich auf die PAL Emulation mittels CPU anstatt GPU. Diese Option ist für directX Nutzer, wo die PAL Shader nicht zur Verfügung stehen. Die PAL Emulation wird über die CPU berechnet. Dies ist sehr langsam und kann deswegen in einem extra Thread berechnet werden.

    Geschwindigket des Scanline basierten Renderer

    Wer die Geschwindigkeit des Scanline basierten Renderer's un-gedrosselt sehen möchte, sollte folgendes berücksichtigen:

    - externe Shader abschalten und unter Präsentation 'CRT aus' um PAL Shader zu deaktivieren ... wenn Grafikkarte zu schwach. Meine Grafikkarte schafft es nicht für 300 fps Shader darüber zu rechnen. Das kostet mich 30 FPS Abzug. Das ist nicht schlimm da der Emulator ja so schnell nicht laufen soll, nur für den Test.

    - Disk Laufwerke deaktivieren oder die neue Option 'Disk Emulation bei Bedarf' zuschalten.

    - eventuell Bildzeilen Thread zuschalten


    Ich bekomme im Basic Screen 350 FPS und in Shadow of the Beast 303 FPS. Ich schaffe 5 RunAhead Frames im akkuraten Modus. Der Geschwindigkeits Unterschied beim Scanline basierten Renderer zwischen akkuraten und performanten RunAhead Modus ist deutlich geringer als beim Zyklus akkuraten Renderer.


    Der Zyklen akkurate Renderer ist im RunAhead nun auch etwas schneller durch Abschalten der 'Disk Emulation bei Bedarf' und durch Deaktivieren des SID Filter ab 2 runAhead Frames. Der Filter arbeitet nur im Letzten, also dem Anzeige Bild, und dem vorletzten (natürlich ohne Ausgabe) um sich zu synchronisieren.

  • Hat das Einfluss auf den Sound?

    Ich hoffe nicht. Ein Frame sollte zum Synchronisieren reichen. Wenn was verdächtig klingt, runAhead deaktivieren und schauen ob es anders klingt. Der Filter wird nur ab 2 runAhead Frames deaktiviert.


    Beispiel: runAhead 2

    Frame 1: Filter aus, Audio aus

    Frame 2: Filter an, Audio aus

    Frame 3: Filter an, Audio an


    Beispiel: runAhead 4

    Frame 1: Filter aus, Audio aus

    Frame 2: Filter aus, Audio aus

    Frame 3: Filter aus, Audio aus

    Frame 4: Filter an, Audio aus

    Frame 5: Filter an, Audio an

  • Wow, soviel neues Zeug auf einmal, da wird ja echt mit Hocheifer dran gearbeitet. Echt cool. Werde ich heute abend rumtesten damit.


    Besonders neugierig bin ich auf diese "Disk Emulation auf Bedarf" Funktion um zu sehenk, wie gut das klappt und auch auf das mit dem SID-Filter abschalten. Mal sehen, was ich noch an Speed für RunAhead rausholen kann auf meinem Rechner mit diesen ganzen neuen Sachen und ob es dann geschwindigkeitsmäßig klappt, 2 Frames RunAhead im akkuraten Modus permanent laufenzulassen auf meinem Rechner und dazu konstant noch die 50FPS zu haben.


    Kleiner, kosmetischer Vorschlag noch am Rande, "Akkuratheit" klingt ein bisschen komisch, "Akkuratesse" ebenfalls. Vielleicht sollte man hier einfach das Wort "Genauigkeit" nehmen? Nur ein Vorschlag.

  • So mal getestet. Die Häkchen bei "Bildzeilen Thread" und "Disk Emulation bei Bedarf" sind gesetzt, bei "Zyklus akkurates Video" nicht gesetzt. Dazu nutze ich noch die PAL CRT Emulation und einen externen Shader via Reshade. Damit komme ich mit meinem Ryzen 5 3500 auf 8 Frames Runahead im akkuraten Modus. Das ist das doppelte von dem was ich vorher einstellen konnte. Natürlich nur für den Performance Test sinnvoll. Spielbar sind ab 4-5 Frames bei mir keine Spiele mehr. Da sind da zuviele abrupte Sprünge in den Animationen. Denke damit kommen auch alle schwächeren Rechner jetzt noch gut klar, sofern die Gurke nicht älter als 10 Jahre ist. :)

  • So mal getestet. Die Häkchen bei "Bildzeilen Thread" und "Disk Emulation bei Bedarf" sind gesetzt, bei "Zyklus akkurates Video" nicht gesetzt. Dazu nutze ich noch die PAL CRT Emulation und einen externen Shader via Reshade. Damit komme ich mit meinem Ryzen 5 3500 auf 8 Frames Runahead. Das ist das doppelte, was ich vorher hatte. Natürlich nur für den Performance Test sinnvoll. Spielbar sind ab 4-5 Frames bei mir keine Spiele mehr. Da sind da zuviele abrupte Sprünge in den Animationen. Denke damit kommen auch alle schwächeren Rechner jetzt noch gut klar, sofern die Gurke nicht älter als 10 Jahre ist. :)

    Jor, nachdem ich gesehen hab wie schnell der Emu nun im Leerlauf rennt habe ich gar nicht mehr genauer nachgemessen. Das ist fantastisch :)

  • Und ich wollte auch noch was melden und zwar noch eine kleine kosmetische Sache, die in Verbindung mit dem 125% Scale, bei mir hier nun auftritt in der neuen Version, da einiges im Menue umgestaltet wurde. Und zwar ist hier das hinterste Wort nun nicht mehr voll innerhalb des Menues.



    Ist jetzt nicht schlimm, aber sieht halt ein bisschen blöd aus. Wäre ja recht einfach behebbar, schätze ich.


    Und noch zwei Sachen hinterher.


    Der scanlinebasierte Renderer bringt einen extremen Speed-Boost, auch auf meinem PC hier, damit kann ich dann sogar 4 Frames RunAhead im akkuraten Modus machen und hab immernoch konstant 50FPS. In ein paar Spielen sieht man damit kleinere Grafikunstimmigkeiten, auch in Microprose Soccer kam mir damit nicht alles astrein vor. Trotzdem gut, bei Bedarf auf diesen Filter nun zurückgreifen zu können. Ich versuche nun noch durch andere Einstellungen, auch im zyklusakkuraten Renderer (also dem bisherigen) noch auf konstant 50FPS mit 2 Frames RunAhead zu kommen. Momentan bin ich da bei circa 40FPS konstant wenn diese neue Floppy-Automatik-Abschaltfunktion aktiviert ist. Die scheint recht gut zu funktionieren, auch in denjenigen Nachladern die ich bislang damit ausprobiert habe.


    Nun versuche ich also erstmal, auch mit dem zyklenakkuraten Renderer, der einfach in vielerlei Software besser aussieht, die 50FPS noch irgendwie zu schaffen. Und zwei Fragen hab ich dazu jetzt noch:


    (1) diese neue "Audio Thread" Funktion führt bei mir zu einer allgemeinen Verlangsamung (was ja auch im Beschreibungs-Text dazu so erläutert wird). ist zukünftig auch eine Funktion geplant, um zwischen dem akkuraten SID-Filter, der ja im DENISE permanent läuft, und einem weniger akkuraten (nach der Art vom "Downsample" Filter im HOXS und dem "FastSID" im VICE) umschalten zu können. das könnte ja auch nochmal einiges rausholen, im WinVICE macht es sich beispielsweise deutlich bemerkbar in Sachen Speed wenn man auf "FastSID" geht. In einigen Spielen, vor allem in denen eh keine Musik permanent im Spielverlauf mitläuft, durchaus verkraftbar, wenn die Sound-FX dann nicht mehr ganz so toll klingen, Hauptsache man hat noch etwas mehr Speed für den RunAhead.


    (2) der "performante Modus" im RunAhead läuft ja, vor allem wenn man den zyklenakkuraten Renderer verwendet, schon deutlich schneller als der akkurate Modus. Wenn der performante Modus dann in einem Spiel "scheitert" (wenn man es denn so nennen will), dann ist das, von dem was ich bislang so beobachten konnte, eigentlich fast immer irgendein Sprite-Sprite-Playfield Kollisionsproblem gewesen bisher, obwohl bei diesem Modus ja noch weitaus mehr Sachen reduziert wurden, die sich hier aber weniger bemerkbar machen. Probleme gibts fast immer nur bei Kollisionssachen, die dann nicht mehr richtig funktionieren. Könnte man hier beim "RunAhead" vielleicht noch so etwas wie einen Zwischenmodus zwischen dem bisherigen performanten und akkuraten Modus mit einfügen, der ähnlich wie der bisherige performante Modus arbeitet, jedoch in Sachen "Sprite-Sprite-Playfield Kollisionen" etwas genauer arbeitet. Der wäre zwar dann wieder etwas langsamer als der bisherige performante Modus, aber immernoch einiges schneller als der akkurate und er würde vielleicht viele Kollisions-Probleme in Spielen beseitigen, die es im performanten Modus momentan gibt. Dann hätte man noch einen Alternativmodus, der bestimmt bei einigen Spielen dann die bessere Wahl wäre, auf Rechnern welche solch ein Spiel nicht im akkuraten Modus schaffen. Man kann ja bislang manuell in Sachen "Sprite-Sprite-Playfield Kollisionen" nichts weiter umstellen, könnte dies aber koppeln an einen schon fertig vorkonfigurierten, neuen Alternativmodus, der sich geschwindigkeitsmäßig zwischen den bisherigen beiden Modi bewegt.


    Der Vorschlag kommt auch deswegen, weil ich auf meinem PC hier beispielsweise bemerkt habe, dass ich im performanten Modus in einigen Spielen, sogar 3 Frames RunAhead schaffe (mit dem zyklenakkuraten Renderer) und der Rechner dann immernoch die 50FPS konstant halten kann, während er im akkuraten Modus nichtmal 2 Frames RunAhead schafft. Da der Speed-Unterschied zwischen den bisherigen beiden Modi performant und akkurat wirklich gross ist, wäre eventuell noch Platz für einen Zwischenkandidaten inmitten der beiden, der akkurater ist als der bisherige performante, aber halt nicht so wie der akkurate Modus selbst. Namen müsste man sich halt dann einen überlegen für diesen Zwischen-Modus. Für meinen PC könnte der performante Modus eigentlich auch etwas langsamer sein und er würde dann sicherlich immernoch die 2 Frames RunAhead schaffen, Hauptsache die Spritekollisionen würden dann passen in einigen Spielen, bei denen es bisher nicht damit klappt.