Denise C64 + Amiga Emulator

Zitat von TestTheWest

Jobs tot... und schon machen die bei Apple Unsinn

Jobs, der Unfehlbare.

Können wir hier an dieser Stelle die nun völlig unnötige Apple/Jobs Diskussion beenden? Danke.

ja ist ein fullscreen stretch. Den integer scale erledige ich, wenn ich das shader system auf retroArch Level bringe.

Ich bin fast durch mit Dynamic Rate Control.

ja seine Aussage kann ich ehrlich nicht nachvollziehen, dabei ähneln sich doch seine Treiber mit denen von retroArch. ich will an der Stelle noch keine Versprechen machen, die ich nicht halten kann.
Möglicherweise hängt der Erfolg von DRC mehr von der verwendeten Hardware ab, als ich denke. Ich bekomme mit XAudio2 (neu in denise) ein tolles Ergebnis hin. DirectSound funktioniert nicht so gut mit DRC, zumindest bei geringen Latenzen.
Aktuell teste ich wasapi im exclusive Modus (ebenfalls neu). Der zeigt mir ne Minimal Latenz von 2,6 milli Sekunden an. Da kann kein anderer Treiber mithalten.

edit: retroArch: Treiber auf wasapi, dann unter audio auf exclusive und Latenz auf 3 milli runter schrauben. Neustart, Treiber Änderungen benötigen in retroArch Neustart.
Resultat mit vice core und 50 Hz in der Monitor Konfiguration: knacksen aller paar Sekunden.

1.0.4
------
added Dynamic Rate Control
- smooth audio + video at the same time
- rewrote all audio drivers
- added xaudio2, wasapi exclusive mode
- show audio buffer usage statistics
- added hotkey to enable/disable all sync options at once
disabled emulator input recognition when minimized
separated c64 and amiga sub menus from each other

https://sourceforge.net/projects/deniseemu/files/v%201.0.4/

Dynamic Rate Control (DRC)
--------------------------
Im Popup Menu unter Einstellungen kann DRC zugeschalten werden. Ebenso kann die Anzeige des audio Puffer Füllstandes zugeschalten werden.
Letzteres ist empfehlenswert um Driver Auswahl bzw. Einstellungen zu überprüfen. Danach kann die Puffer Anzeige natürlich wieder
deaktiviert werden. Über einen neuen hotkey können alle aktiven Sync Optionen schnell aktiviert/deaktiviert werden. Wenn z.b. schneller von Disk geladen werden soll,
muss nicht einzeln vsync, audio sync und rate control einzeln deaktviert und später wieder aktiviert werden. Das ist aber noch kein warp mode. Der kommt später.

Puffer Füllstandsanzeige in %
-----------------------------
Der erste Wert zeigt einen Momentanwert jeder Messreihe an. Es können nicht alle Werte einer Messreihe angezeigt werden, ansonsten wären die vielen Wechsel unlesbar.
Es schließen sich Minimum und Maximum Werte in eckigen Klammern an. Da der Momentanwert nicht alle Werte erfasst,
ist es gut möglich das die besonders wichtigen Extremwerte verschluckt werden. Die Extremwerte werden für jede Messreihe neu ermittelt.
Abschließend folgt der Durchschnittswert. Wie bei den Extremwerten fließen hier alle erhobenen Werte mit ein.
Ziel ist es den Puffer auf 50% Füllstand zuhalten, denn damit ist er optimal vom Überlauf bzw. Unterlauf entfernt.
Wenn Minimum- und Maximumwerte nie als Momentanwert erscheinen, ist das ein Hinweis darauf das diese nur sehr selten je Messreihe erreicht werden.
Unterlauf: audio Puffer wird zu langsam gefüllt. Anstatt neuer samples werden die alten erneut abgespielt. -> knacksen
Überlauf: durch "audio sync" wird zwar verhindert, dass der Puffer beschrieben wird, wenn kein freier Platz
vorhanden ist aber durch das Warten auf einen freien Platz kann es passieren, das ein vblank verpasst wird. -> micro Ruckler
Eine Tendenz in Richtung höheren Füllstand ist günstiger als in Richtung Unterlauf.

--------------------------
Emu -> Einstellungen/Video
--------------------------

vsync
-----
vsync muss für DRC aktiviert sein, denn anhand der vsync Verzögerung wird audio synchronisiert.
Es sollte im Emulator und im Treiber erlaubt werden.

Linux mit Geforce: (zusätzlich zur vsync Einstellung)
Nvidia Settings mit sudo öffnen sudo /usr/bin/nvidia-settings
Unter X Server Display Configuration -> Advanced
die Checkbox bei Force Compostion Pipeline aktivieren (*)
die Checkbox bei Force Full Compostion Pipeline deaktivieren. (**)

(*) Ansonsten gibt es dieses lästige Bild-Reißen an immer der gleichen Bildzeile.
Dies läßt sich gut beobachten wenn man auf youtube hoch und runter scrollt.
(**) Ansonsten gibt es Probleme mit openGL.
dann Save to X Configuration File (deswegen das sudo)
abschließend Neustarten (ohne Neustart lief das vsync nicht durchgehend stabil)

Hard Sync (nur OpenGL)
----------------------
Windows mit Geforce:
vsync kann in einem weiteren Render Thread ausgeführt werden.
Dies verhindert jedoch, das das Hauptprogramm wartet bis die Anzeigedauer eines Einzelbildes erreicht ist. DRC kann auf diese Weise audio
nicht mit video synchronisieren. Man sieht das auch gut an starken Schwankungen des audio Puffer. DRC wird zwar dafür sorgen, das es im
Mittel 50% erreicht. Jedoch bringt das wenig, wenn es ständig in einen Unterlauf bzw. Überlauf hinein läuft.
Hard Sync synchronisiert CPU mit GPU.
Dies kostet jedoch einige CPU Ressourcen.
Es gibt eine performance schonende Alternative.
In den nvidia Einstellungen gibt es eine Option 'Threaded-Optimierung'.
Das bezieht sich auf den extra Render Thread. Wird dies deaktiviert,
verbraucht Hard Sync nun deutlich weniger Cpu. (kann ich nur empfehlen)
Zudem kann ich Hard Sync in diesem Modus auch deaktivieren ohne die oben beschriebene Schwankung.

Grundsätzlich verbraucht Direct3D weniger Cpu Ressourcen als OpenGL.

Windows 7 mit Ati:
keine Auffälligkeiten, geht auch gut ohne Hard Sync

Windows 10 mit Ati: (kann ich nicht testen)
meine Karte ist zu alt (openGL + vsync = halbe Framerate)

Linux mit Geforce:
In den Nvidia X Server Settings kann ich über Application Profile 'Threaded-Optimierung' zwar deaktivieren, dennoch
bekomme ich ohne Hard Sync kein vernünftiges DRC hin. Im Gegensatz zu Windows läuft dies jedoch
Ressourcen schonender ab. (also hier klares vote für Hard Sync)

Linux mit Ati:
sorry ich habe keine Lust das mit meiner alten Karte zu testen.

OSX mit intel hd graphic:
unbedingt Hard Sync zuschalten. Performance wird hier, ähnlich Linux, nicht beeinträchtigt.

exclusive fullscreen (nur Direct3D)
-----------------------------------
Hierbei erhält man exclusiven Zugriff auf die Video Hardware.
Der DWM (Desktop Window Manager) wird umgangen. Ich hörte das wirkt sich neben der Video Latenz auch positiv auf die Input Latenz aus.

Frequenz Korrektur (Übergehe exakte Frequenz)
---------------------------------------------
Diese Option sollte nur für Free-Sync oder G-Sync Monitore deaktiviert werden, andernfalls aktiviert.

Bei den alten Röhren betriebenen Spielkonsolen / Computer gibt das System in einem gewissen Rahmen
die Bildwiederhol-Frequenz vor. z.B. läuft ein ntsc C64 mit 59.826 Hz. Ein Snes mit 60.09 Hz.
Bei normalen Pc Monitoren ist das umgekehrt. Das System richtet sich nach der Frequenz des Monitors.
Ausnahmen sind die Free-Sync, G-Sync Monitore.

Ist diese Option nicht aktiviert, werden audio samples für die original Bild Frequenz generiert.
Das macht nur Sinn, wenn der Monitor die original Frequenz auch darstellen kann. (c64 pal 50.1245 Hz)
(nennt sich 'sync to exact content framerate' in RetroArch)

Für Standard Monitore muss die Anzahl audio samples für die reale Bildwiederhol Frequenz, also 50.0/60.0 Hz ausgegeben werden.
Diese beiden 'Schätz' Frequenzen für pal/ntsc sollten nur in sehr kleinen Schritten (z.b. 50.01 oder 49.99) verändert werden, wenn kein zufriedenstellendes
Ergebnis erzielt wird. In diesem Fall ist der Schätzwert zu weit von der tatsächlichen Bildwiederholfrequenz entfernt und
DRC kann die Distanz nicht ausgleichen. Die im Monitor OSD angezeigten Frequenzen sind auch nur Schätzwerte.
Grundsätzlich gilt, umso näher die Schätz Frequenz an die Tatsächliche heran reicht, desto weniger muss DRC ausgleichen.
Sollte DRC nicht verwendet werden, ist diese Einstellung besonders wichtig.
Ist der Puffer Füllstand zuweit von 50% entfernt einfach mal in 0.01 Schritten erhöhen/senken. Es dauert dann ein paar
Sekunden bis sich der Füllstand verschiebt.

Brauche ich DRC überhaupt noch, wenn ich die genaue Bildwiederholfreuqnz meines Monitors herausgefunden habe?

Das hängt davon ab, ob (sehr wahrscheinlich) und wie stark die Frequenz im Laufe der Zeit schwankt. Monitore
verursachen durch Hitze Schwankungen in der Bildwiederholfrequenz. Zudem hängt es auch sehr vom verwendeten audio Treiber ab.
Wenn ich DRC bei xaudio z.B. abschalte, schaffe ich es nicht durch Frequenz Anpassungen den Puffer Stand dauerhaft in Balance
zu halten. Er kippt immer in eine Richtung ab. Durch eine optimale Schätz Frequenz kann man den Puffer Über/Unterlauf ohne DRC
auf jeden Fall verzögern.

Zum Test empfehle ich einen endlos scroller (Text, besser Bild) mit klarer Musik.

Muss ich für pal meinen Monitor auf 50 Hz umstellen?

DRC löst nicht den Umstand, das man für pal den Monitor auf 50 Hz umstellen muss.
Ati: im Catalyst Control Center unter 'Meine digitalen Flachbildschirme' -> Unterstützung für
HDTV ein Profil z.B.: 1920 * 1080 @ 50 Hz auswählen.
Geforce: nvidia einstellungen -> Auflösung ändern -> Aktualisierungsrate -> 50 Hz

Man kann im Rahmen der Frequenz Korrektur auch im pal Feld 60 Hz eintragen. In dem Fall läuft die pal emulation
auf 60 Hz getakteten Monitoren sauber. Das Spiel läuft dann jedoch spielbar und hörbar zu schnell. Ansonsten ist es eine
saubere pal emulation.

--------------------------
Emu -> Einstellungen/Audio
--------------------------

Frequenz
--------
Die meisten Soundkarten haben eine native Frequenz von 48000 Hz. Dies sollte man nur auf 44100
umstellen, wenn gewiß ist, das dies die native Frequenz ist. Anderfalls muss der audio Treiber
unnötigerweise auf die native Frequenz resamplen.

Latenz
------
Dies ist die Zeit, wie lange audio samples in einem Puffer verweilen, bis diese tatsächlich
abgespielt werden. Latenz und Frequenz bestimmen die Puffergröße. Ein zu kleiner Puffer wirkt sich
ungünstig auf DRC aus. 60 ms ist ein guter Richtwert. Einfach ausprobieren wie weit man runter kann.
Nach Auswahl eines Treibers ändert sich der Minimal Wert des Latenz Sliders. Der Minimalwert ist entweder
der Grenzwert inwieweit der Treiber ohne Absturz arbeitet oder es ist der vom Treiber abgefragte Wert.
Latenz Veränderungen stellen die effektivste Möglichkeit dar, DRC zu beeinflussen.

Reverb Effekt(neu):
*unabhängig von DRC* In der Natur sind sounds nicht sofort stumm, wenn deren Quellen keinen Ton mehr produzieren.
Durch Reflexionen klingen diese noch etwas nach.

Treiber
-------
Ich teile die Treiber in Bezug auf die verwendete Latenz (Größe des audio Puffer) in 2 Kategorien ein.

1. audio Puffer wird vom Emu Developer verwaltet. (directSound, xaudio2, openal)
Die im Slider aktivierte Latenz beschreibt hier nur die Maximal Latenz, nicht die Tatsächliche. (ist bei RetroArch nicht anders)
Die tatsächliche Latenz ist vom Pufferfüllstand abhängig. Liegt der Füllstand durch DRC auf durchschnittlich 50% bedeutet das
die halbe eingestellte Latenz. Die Latenz schwankt also je nach Füllstand.
Für diese Treiber kann und sollte die Latenz höher eingestellt werden.
2. audio Puffer wird vom Treiber verwaltet. (wasapi, coreaudio, pulseaudio)
Hier entspricht die Latenz auch dem im Slider eingestellten Wert.
Bei einigen Treibern kommt noch eine sogennate device Latenz (2 - 4 ms) hinzu.
Bei coreaudio z.b. kann ich die abfragen und die lag bei 3.67 ms.
Es würde jetzt den Rahmen sprengen die in der UI noch anzuzeigen oder drauf zu rechnen.

OpenAl [Windows, Linux, OSX]
-> Minimal Latenz: 40 ms
-> DRC erfolgreich 80 ms ( ~40 ms Latenz im Durchschnitt )
würde ich nur nehmen, wenn die nativen Treiber der jeweiligen OS'es failen

Direct Sound [ab Windows XP]
-> Minimal Latenz: 40 ms
-> DRC erfolgreich 100 ms ( ~50 ms Latenz im Durchschnitt )
DRC läuft nur mit hohen Latenzen.

XAudio 2.9 [Windows 10], 2.8 [Windows 8], 2.7 [Windows 7, Vista] -> Nachfolger von Direct Sound
-> Minimal Latenz: 20 ms
-> DRC erfolgreich 30 ms ( ~15 ms Latenz im Durchschnitt )
bevorzugter Treiber ab Windows 7

Wasapi Shared [ab Vista]
-> Minimal Latenz: 10 ms
-> DRC erfolgreich 10 ms
ich meine gelesen zu haben Xaudio2 wrappt ab Vista auf Wasapi Shared und davor auf Direct Sound

Wasapi Exclusive [ab Vista]
-> Minimal Latenz: 3 ms (abhängig von der Hardware)
-> DRC erfolgreich 3 ms
sehr geringe Latenz, kommt jedoch zu einem Preis. Der audio Mixer wird deaktiviert. Ein parallel laufendes youtube Video wird gestoppt und alle
weiteren sounds im System bleiben stumm während der Treiber aktiv ist. Die Frage ist ob man wirklich 3 ms Latenz braucht ?
im Gegensatz zu RetroArch verwende ich einen zusätzlichen Puffer, auf welchen Wasapi in einem extra Thread zugreift um die Daten in seinen eigenen
Puffer zu schaufeln. Auf diese Weise kann ich der geringen Latenz (kleiner Wasapi Puffer) besser Rechnung tragen.
Wasapi exclusiv muss in den Windows Einstellungen erlaubt sein. (sollte standard mässig der Fall sein)
Rechtsklick auf Lautsprecher unten rechts -> Geräteeigenschaften -> Erweitert -> Exclusiver Modus -> beide Checkboxen anhaken

Pulseaudio [Linux]
-> Minimal Latenz: 10 ms
-> DRC erfolgreich 35 ms (*) 70 ms (**)
(*) Linux Mint 19.1 Mate mit einer low budget nvidia geforce 1030 GT
(**) Linux Mint 19.1 Mate laptop mit intel hd graphics (vsync ist dauerhaft aktiv, nervig wenn der emu mal schnell was laden soll)

CoreAudio [OSX]
-> Minimal Latenz: 10 ms
-> DRC erfolgreich 40 ms (*), 20 ms (**)
(*) Mein MacBookAir(2014) mit intel hd graphic bekommt DRC mit ca. 40 ms Latenz hin. (Os: Siera, Hard Sync NICHT aktiviert)
Als OS habe ich Sierra verwendet. High Sierra verursacht aller paar Sekunden Frameraten Einbrüche mit vsync.
Dies ist ein bekanntes Problem bei OSX, wenn aktuelle Betriebssysteme mit vergleichsweise älterer Grafik-Hardware zusammenspielen.
(**) Bei High Sierra funktioniert es nur mit Hard Sync. Jedoch sind dann auch 20 ms problemlos möglich.

dynamische Korrektur
--------------------
Der default Wert dieser Konstante liegt bei 0.005 und sollte zwischen 0.003 und 0.005 liegen.
Ein unsichtbarer Filter (keine Eingabe Korrektur) begrenzt user Eingaben auf maximal 0.010.
Hierbei geht es darum wie stark einer Puffer Abweichung entgegen gesteuert wird. Liegt die geschätzte Bildwiederholfrequenz
sehr nahe der Tatsächlichen spielt diese Konstante eine geringe Rolle, da hier wenig ausgeglichen wird.
Sind Abweichungen auszugleichen und die Konstante ist zu niedrig, entfernt sich der Puffer Füllstand zu sehr von
den angestrebten 50 %. Das bringt uns gefährlich nahe an einen Über/Unterlauf.
Ein zu großer Wert würde zu stark ausgleichen und der Pitch wäre hörbar (subjektiv).

Es sollte nicht nötig sein, diesen Wert (0.005) anpassen zu müssen.

Hinweise
-----------
Alle Einstellungen in Denise, selbst Treiber Änderungen, werden ohne Neustart, während der Emu läuft, durchgeführt.
Ihr könnt also an den Werten rumschrauben und schauen ob es sich positiv oder negativ auswirkt.
Von Interesse sind Mikro Ruckler, Audio Knacksen (vorsicht bei manchen 8 bit games kann das auch normal sein )
und die Puffer Füllstands Anzeige.

Den wahrscheinlichsten Grund für Probleme stellen Dual Monitor Setups dar. Manchmal ist es notwendig das die app
auf dem als Primär eingestellten Monitor laufen muss.
Derartige Probleme kann ich im Rahmen meiner Programmierung nicht wirklich lösen. Das ist ne Treiber Geschichte.
Ältere Ati Grafikkarten können unter Windows 10 mit opengl + vsync Probleme verursachen.
Die Framerate wird hierbei gnadenlos halbiert. Unter Windows 7 hat das funktioniert.
Intel hd graphic chips sind ziemlich ungünstig für DRC, da die vsync Zeiten zwischen den Einzelbildern doch sehr schwanken.
Der audio Puffer schwankt dann ebenfalls. Dies ist nur mit höheren Latenzen + Hard Sync kompensierbar.

freut mich das es funktioniert.

das nächste release wird überschaubar.

1. drag'n'drop
2. command line support (als erster Schritt für die Vice Testbench)
3. c64 Farb Paletten (vorausgewählte Paletten, eigene Farbcodes)
4. Farbspektrum als Ergänzung zu den Farb Paletten oder Ersatz ?

Superb! Wohl endlich einer der es richtig macht.
Kurzer Test auf 60 Hz Bildschirm, LÄUFT! - natürlich zu schnell, trotzdem.
Der erste Emulator der flüssig läuft hier bei mir.

Das wird also jetzt mein neuer Emulator der Wahl für FLÜSSIGE C64 Emulation vor Vice und anderen!
Referenz: Gianna Sisters Titel Scroller - Das stimmt schonmal sehr gut

DANKE!!! DANKE!!!

Ein bisschen unsauber läuft es gefühlt noch ingame Gianna, Turrican... Auch ist die Latenz noch recht hoch? Alles subjektiv.
Weitere Tests stehen natürlich noch aus. Geht aber sicher in die richtige Richtung Dein Projekt.

-

Verbesserung bzw. meine Wünsche wären:

• Default Einstellungen für Keyboard... Rechte Shift 8 für * muss man erstmal drauf kommen. Find ich komisch, als default.
• Integer Scaling bitte (mit nearest)
• JiffyDOS/custom Firmware/ROMs
• Cartridge Kram, v.a. BASIC Erw., EF³ und Neo/GeoRAM, REU

Zitat von Retro-Nerd

Kann es sein, das DRC aus Versehen immer aktiv ist? Selbst wenn ich das im Menü deaktiviere bekomme ich DRC Pufferdaten in % angezeigt.

Das ist nicht der DRC audio Puffer sondern der audio Puffer im Allgemeinen. Durch Zuschalten von DRC kann man schauen, wie sich die Puffer Auslastung verändert. Wenn z.B. ohne DRC der Puffer bei 60%
im Durchschnitt gefüllt ist, bekommt man ein optimales Ergebnis auch ohne DRC hin. Das ist sehr abhängig von audio und video Hardware bzw. Software.
Selbst wenn die Puffer Auslastung ohne DRC stabil scheint, würde ich es dennoch aktivieren. Durch weitere parallel laufende Programme wie Browser kann jederzeit ne Spitze ausgelöst werden und der Puffer
könnte sich unglücklich verschieben. DRC würde das schnell wieder korrigieren.

Zitat von Ferkels Willem

Ein bisschen unsauber läuft es gefühlt noch ingame Gianna, Turrican... Auch ist die Latenz noch recht hoch? Alles subjektiv.

Du meinst mit unsauber die gefühlte Input Latenz ? oder Emulations Fehler ? Bei letzterem bitte vorher prüfen, welcher VIC-II emuliert wird. (65xx oder 85xx)
Emulations Fehler haben Prio, der Rest muss warten.

Zitat von Ferkels Willem

Default Einstellungen für Keyboard... Rechte Shift 8 für * muss man erstmal drauf kommen. Find ich komisch, als default.

* steht default auf Shift Rechts und + , Shift rechts und 8 ist (

Ja die firmware roms können gegen custom roms getauscht werden. Cool wußte ich gar nicht, das Jiffy DOS keine speziellen Umbauten braucht.
Ja ich komme aus der Amiga Welt. Das probiere ich aus.

ok ich sehe schon, das wird wieder nichts mit der Amiga Emulation dieses Jahr. Ich stecke das volle Jahr noch in den C64 und den Unterbau (wovon Amiga ja ebenso profitieren wird).
ich schreibe mal alle Punkte zusammen die von euch erwähnt wurden. (ohne Priorisierung). Bitte ergänzt/korrigiert die Liste.

C64:
- easy flash + write support
- REU, BASIC Erw., EF³ und Neo/GeoRAM
- warp Modus ( Teile vom Sid und Vic werden deaktiviert um sehr schnelle Ladezeiten zu ermöglichen. Aktuell kann man nur durch Abschalten der sync Optionen beschleunigen )
- alle Voraussetzungen für die Vice Testbench erfüllen (Screenshots, virtuelle cartdrige) Schließlich will ich auch die Genauigkeit des Emulators nachweisen.
- Farbpalette (vordefinierte + eigene Farbcodes) + Farbspektrum als Ergänzung
- Unterstützung von Modulen ohne Struktur Informationen (.bin files) Das sind reine Software Dumps. Man muss dem Emu mitteilen, ob es ein ocean, system 3, funplay, supergames, zaxxon usw. ist.

Unterbau:
- Command Line Support
- Drag'n'Drop

- video Treiber, ähnlich den audio Treibern, auf RetroArch Level bringen. Insbesondere ist der shader support gemeint. Das reverse engineering wird viel Zeit kosten.
Vielleicht sollte ich das Integer Scaling vorziehen.

- Beam Racing, für mich das ultimativste feature. Das muss ich unbedingt haben.
flüssige pal Emulation auf 60 Hz. Viele Nutzer wissen nicht, das man den Monitor für pal auf 50 Hz umstellen muss. Sie nutzen den Emu, es ruckelt natürlich und sind bedient.
kein vsync mehr nötig (Gedanke: hoffentlich kann ich das vernünftig mit DRC verheiraten, wird schon...) heißt spürbar bessere Input Latenz.

- RunAHead - Anti Mond-Springen (RetroArch feature) Ohne Zweifel die Jungs von RetroArch sind die Nummer 1 was Emulator Unterbau betrifft.
das ist die effektivste Möglichkeit Input Latenzen entgegen zuwirken. Der Emu Core läuft zweimal. Der erste Core produziert wie üblich audio + video.
Der 2. Core tut das nicht. Er ist für input verantwortlich. Beide Cores laufen im Abstand von x frames zueinander. Der Einfachheit halber sagen wir x = 1 frame.
Das bedeutet, die Input Erkennung findet ein frame früher statt als üblich. Der Input Core läuft ein frame in der Vergangenheit.
Ändert sich die user Eingabe wird diese vom Input Core ein frame früher einberechnet. Der input Core wird ein frame mit dem neuen Input ausgeführt, so dass er
an gleicher Stelle steht wie der audio/video Core. Dann wird ein Spielstand vom input Core generiert (user Input bereits verarbeitet) und anschließend wird der Spielstand
im audio/video Core geladen. (gleiche Position, nur mit bereits verarbeiteter Eingabe).
Das kann man auch mit 2 und mehr frames durchführen. Natürlich könnte es die Spiel Logik verwirren. 1 frame ist sicher für alle games ok. 2 oder mehr sollte mit dem entsprechenden Spiel
getestet werden. Das richtet sich maßgeblich danach, wieviele frames das game selber für Input Verarbeitung benötigt.

----------------------------------------------
c64 features nach der Basis Amiga 500 Emulation:
----------------------------------------------
- Super CPU (find ich geil)
- weitere Modul Typen
- userport: speed dos
- userport: 4 player adapter
- Dongles (auch Datasette dongles)
- Tape Inhalts Vorschau (besonders für Turbe Tape games)
- ...

Unterbau
- rewind support
- debug Monitor
- Vulkan support
- ...

Zitat

RetroArch Shader Level Niveau muß jetzt nicht in nächster Zeit sein. Der Quark Shader Support bietet scheinbar ganz gute Möglichkeiten vorhandene Mult-Shader zu portieren. Der guest.r hatte auf meinen Wunsch einen Sony Trintron Style Shader erstellt, der kaum Wünsche offen läßt.

Ok ich priorisiere das Integer Scaling hoch, direkt fürs nächste release. Dafür nehme ich RetroArch Shader support nach hinten.
Ich habe shader bisher nur zum Testen der glsl Programmierung eingesetzt, aber nicht aktiv zum Zocken (nur den bilinearen standard filter in allen emus).
Deswegen ist mir das mit dem Integer Scaling entgangen.
Kannst du mal bitte die shader, welche du als besonders sehenswert empfindest, an den thread hier hängen oder benennen... keine Ahnung: Trintron Style Shader usw.
Zum einem will ich auf den Geschmack kommen, zum anderen das integer scaling testen.
Dann packe ich noch die pixmaps (png overlays) mit rein.

Danke.
Trinitron Röhre. Den habe ich noch am Laufen mit PS2 und Gamecube.
Die Bildgröße für den shader habe ich jetzt solange angepasst bis es stimmig aussieht. Da kommt später das integer Scaling ins Spiel.
Das Retro Gefühl steigt definitiv durch derartige shader. Ich lasse den mal ne Weile aktiv.

JiffyDos ist definitiv eine Bereicherung. Angeblich nicht der Schnellste aber der Kompatibelste Schnell Lader.
Ich baue da mal noch eine Möglichkeit rein, zwischen standard firmware und custom firmware per Checkbox umzustellen.
Das erspart das lästige Neu Auswählen der einzelnen Dateien (so ne Art fallback switch)