Beiträge von PiCiJi

Zitat von AW182

Wäre nicht eigentlich, diese von dir zunächst angedachte Lösung (die mit dem "dann heißt der Bezeichner: "Turrican 2 Disk 1" usw) diejenige, mit dem kleinsten Übel, wenn man es gegenüberstellt?

Hierbei haben sich 2 Probleme ergeben:

1. Denise merkt sich die eingelegten Disks/Tapes wenn der Emu beendet wird. Hat man nun die 2. Disk eines Spieles eingelegt und beendet den Emu um später weiterzuspielen,

wird beim Neustart die aktuell eingelegte Disk 2 als Grundlage für den Spielstand-Bezeichner verwendet und man kann seine bisherigen Spielstände nicht mehr per Hotkey laden,

da diese ja auf den Bezeichner von Disk 1 aufgebaut sind. Man müsste also erst Disk 1 wieder einlegen.

2. Nachdem Reset wird die bereits oder jeden Moment eingelegte Disk/Tape 1 als Grundlage für den Spielstand-Bezeichner verwendet. Wird später eine Disk/Tape 2 eingelegt, ändert sich

dieser Bezeichner nicht mehr. Die Spielstände basieren auf dem Bezeichner von Disk/Tape 1, egal ob Disk/Tape 2 gerade eingelegt ist.

Legt man nun nach dem Reset ein Tape ein und schmeißt vorher die Disk raus, wird es kompliziert. (weitere Szenarien denkbar) Es soll der Bezeichner nach dem Reset bzw. der zuerst eingelegten Disk/Tape nicht mehr geändert werden, damit das funktioniert. Man müsste also sicher die Aufforderung der Software Disk/Tape 2 einzulegen erkennen. Das wird nervig.

Klar, der Mensch sieht auf einen Blick, dass der Basic Screen sichtbar ist oder allgemein keine Aufforderung der Software zum Wechseln der Disk ausgegeben wird. Für die Maschine wird es da schwieriger. Man könnte analysieren ob der Programmzähler im Kernal rum springt....

Man könnte die beiden Blau Töne im Basic.Screen erkennen usw. Das ist alles wenig zuverlässig.

Man könnte es auch rein aus dem Nutzer Verhalten ermitteln. Unterm Strich wird das nicht rund.

-------------------

Dann hatte ich überlegt den Spielstand-Bezeichner anhand der eingelegten Disk/Tape immer neu zu setzen, also egal ob Laden nach dem Reset oder Einlegen einer Folge-Disk.

Und wenn z.B. Disk 1 im Laufwerk ist und somit Grundlage des Spielstand-Bezeichner ist, aber ein Spielstand von z.B. Slot-1 geladen wird, welcher auf Disk 2 erstellt wurde.

Der Emu würde die zusammengebaute Datei nicht finden. Ok in dem Fall wird nicht gleich aufgegeben, sondern versucht dies aus dem Dateinamen für Disk 2 zu ermitteln und bei Auffinden dieser geladen.

Das Problem hierbei ist aber, das wenn man z.B. in Slot-1 einen Spielstand von Disk 1 erstellt und nach dem Wechsel auf Disk 2 den Slot nicht auf 2 erhöht und dort neu

speichert, hat man in Slot-1 2 Spielstände. Und je nachdem welche Disk eingelegt ist, wird mal der eine und mal der andere geladen. Wahrscheinlich nicht den, welchen man

gerade im Sinn hat.

------------------

Zitat von Retrofan

Es gibt im Unicode (und den sollte Windows langsam auch beherrschen) haufenweise echte Zählsymbole, die unabhängig von unseren bekannten, auf dem Keyboard liegenden, Zahlzeichen sind.

Ja, da gibt es viele Möglichkeiten sich seine files zu organisieren.

Die Multi Disk Programme anhand eines vorgegebenen Benennung-Schema zu ermitteln, empfinde ich als zu einseitig.

Z.b. habe ich nicht das Bedürfnis meine Programme nachdem Download umzubenennen. Selbst dann nicht, wenn der Emu mich freundlich darauf hinweist, welche Vorteile das hat.

Das kleinste Übel ist für mich also das Beispiel mit Hexenküche. Und wenn man Teil 1 und 2 nicht gerade durcheinander spielen will, hält sich der Ärger in Grenzen.

Zitat von AW182

Aber den hat man doch jetzt, wenn man die Option "An" benutzt und nicht "Folgedisketten im Bezeichner abschneiden"?

Ja bei der Option "An" hat man den vollen Bezeichner.

Bei der Bestands Option "Folge-Disketten im Bezeichner abschneiden" führte in alten Versionen die Erkennung mitunter dazu das mehr abgeschnitten wurde als notwendig und somit andere Spiele, welche Wortteile enthielten ebenso den gleichen Spielstand-Bezeichner bekamen.

Das löst natürlich nicht das Problem bei Hexenküche.

Bei der Benennung Hexenküche 1 und Hexenküche 2 gibt es keine Chance zu unterscheiden ob es zwei verschiedene Spiele oder Folge-Disketten eines Spieles sind.

Bennent man es so: "Hexenküche I" und "Hexenküche II" sollten nun 2 verschiedene Spiele erkannt werden.

Die neue Erkennung ermittelt Disks nur noch als Folge-Disk, wenn der Gesamt-Bezeichner in der Länge gleich bleibt.

Zitat von AW182

Damit meine ich, dass man die Files so benennen sollte, dass man unterscheiden kann, zwischen einem Multi-Disk-Spiel und einem Spiel welches nur eine Diskseite aber Folge-Teile hat, etwa indem man weitere Seiten eines Multi-Disk-Spiels im Filenamen mit einem Minus abtrennt,

welche Dateinamen funktionieren jetzt nach deiner Umbenennung nicht ?

Zitat von PiCiJi

Das ist nicht so einfach zu lösen, denn woher weiß man nun ob es Folgedisketten des selben Spieles sind oder verschiedene Spiele.

Vielleicht sollte man es so umbauen, dass der Spielstandbezeichner nur nach einem Reset gesetzt wird oder wenn die erste Disk/Tape eingelegt wird.

Dann heißt der Bezeichner: "Turrican 2 Disk 1". Dieser Name würde dann auch verwendet, wenn unter einer später eingelegten Disk 2 gespeichert wird.

Der Bezeichner ist dann weniger schön für multi disk games, aber es würde somit kein Problem mit Hexenküche geben.

Ich versuche hier mal was.

Jede Lösung hat immer irgendwelche Nachteile.

Ich habe die Funktion nochmal überarbeitet und die Erkennung zusammen gehöriger Dateien verbessert.

Zudem gibt es jetzt noch eine weitere Option:

Spielstand Bezeichner automatisch setzen: Aus , An (neue Option) , Folgedisketten im Bezeichner abschneiden

Diese neue Option "An" bewirkt, das der gesamte Dateiname als Spielstand Bezeichner verwendet wird. Dies ist eindeutig bei Spielen mit nur einer Disk Seite.

Bei mehrere Diskseiten liefert jede Seite einen anderen Spielstand Bezeichner. Per Hotkey lässt sich der Spielstand also nur laden, wenn die aktuell eingelegte Disk Seite zu jener passt, auf welcher der Spielstand generiert wurde.

Manuell lässt sich der Spielstand im User Interface allerdings wiederfinden und kann dann von einer beliebigen Disk Seite geladen werden, was auch dazu führt, das diese Disk eingelegt wird.

Die bisherige Option "Folgedisketten im Bezeichner abschneiden" wurde als nun verbessert und ist besonders für Spiele mit mehreren Disk Seiten gedacht, da soviel vom Dateinamen abgeschnitten wird, bis die Diskseite entfernt ist. (man also den gleichen Bezeichner für alle Disk Seiten eines Spieles erhält)

Die Erkennung ist genauer, was zu einem längeren Bezeichner führt. Dadurch verringert sich die Gefahr, dass verschiedene Spiele den gleichen Spielstand Bezeichner erhalten.

Zitat von reamigation

Ich habe festgestellt, dass, wenn man bei Spielen wo der Dateiname zwar gleich beginnt aber irgendwann voneinander abweicht (z.B. Hexenkueche I und Hexenkueche II) die Savestates oft nicht korrekt funktionieren. Z.B. wird wenn ich Hexenkueche II starte und dann ein Load State ausführe der Spielstand von Hexenkueche I geladen.

Problem:

Der Spielstand Bezeichner basiert auf dem Dateinamen der eingelegten Software.

Hat nun ein Spiel 2 oder mehr Disketten und man speichert ab während die 2. Disk eingelegt ist, ändert sich der Dateiname des Spielstandes im Vergleich zur ersten Disk.

Würde man das Spiel nun erneut von Disk 1 laden und dann irgendwann den Spielstand laden (welcher auf Disk 2 erstellt wurde), wird dieser nicht gefunden. Denn der aktuelle Spielstand Bezeichner basiert

ja auf der aktuell eingelegten Disk 1. Nur wenn man Disk 2 einlegt, könnte man den Spielstand wiederfinden.

Lösung: die Zahlen oder disk sides am Ende werden abgeschnitten:

Turrican 2 Disk 1

Turrican 2 Disk 2

würden dann beide zu "Turrican 2 Disk" (+ Zählung _1 _2 _50 usw. ). Das wäre dann der Spielstand Bezeichner.

Nun ist es egal ob der Spielstand auf Disk 1 oder 2 erstellt bzw. geladen wurde. Der Spielstand wird gefunden werden.

ungünstiger Nebeneffekt:

Genau das was du beschreibst. Hexenküche 1 und 2 sind verschiedene Spiele anstatt Folge Disketten des gleichen Spieles. Die oben beschriebene Logik unterscheidet nun nicht zwischen beiden Spielen.

Wenn unter Hexenküche 1 gespeichert wird und dann unter Hexenküche 2 geladen wird, läuft auf einmal wieder Hexenküche 1. oder wenn unter HK 2 gespeichert wird, überschreibt man sich den Spielstand von HK1.

Das ist nicht so einfach zu lösen, denn woher weiß man nun ob es Folgedisketten des selben Spieles sind oder verschiedene Spiele.

Vielleicht sollte man es so umbauen, dass der Spielstandbezeichner nur nach einem Reset gesetzt wird oder wenn die erste Disk/Tape eingelegt wird.

Dann heißt der Bezeichner: "Turrican 2 Disk 1". Dieser Name würde dann auch verwendet, wenn unter einer später eingelegten Disk 2 gespeichert wird.

Der Bezeichner ist dann weniger schön für multi disk games, aber es würde somit kein Problem mit Hexenküche geben.

Ich versuche hier mal was.

Es gibt aktuell noch die Möglichkeit den Spielstand Bezeichner manuell zu setzen.

Unter C64/Amiga -> Konfiguration -> Spielstände -> Checkbox: "Spielstand Bezeichner automatisch setzen" deaktivieren.

Jedoch muss dann selber dafür gesorgt werden, dass in dem Feld Bezeichnung ein Dateinamen eingeben wird. Die Zählung (Spielstandnummer) geschieht aber auch hier automatisch.

nightly

Unter macOS gibt es nun Cocoa als Eingabe Treiber (vorausgewählt). Damit fällt der System Dialog (Eingabeüberwachung) weg, welcher bei jeder neuen Version genervt hat.

Zitat von AW182

Frage noch hierzu. Wird dann empfohlen, die Schrittmotor-Suchzeit im Denise standardmäßig auf 9ms einzustellen, oder könnte das dann wieder in anderer Software Probleme bereiten und man sollte lieber bei 0ms bleiben?

schwer zu sagen. Da so gut wie keine Software bekannt ist, die davon abhängig ist, würde ich es nur bei Bedarf zuschalten. Normalerweise werden keine Daten beim Steppen gelesen und verarbeitet.

Die Emulation dieses Verhalten ist nicht vollständig. Wenn ein weiterer Step zu zeitig erfolgt, wird sofort zum nächsten Track gewechselt.

Hier gibt es sicherlich auch geringe Latenzen.

Also die im Slider eingestellte Zeit gilt nur nach dem letzten Step.

Zitat von AW182

Ja, ist jetzt im Nachhinein schwer nachzuvollziehen, wie es hier nun genau war damals? Ich mache PiCiJi, den Denise Entwickler, aber mal darauf aufmerksam, auf dieses Disk Inertia Testprogramm. Vielleicht weiß er das ja noch?

Damit der Test funktioniert, muss die Schritt Motor Suchzeit emuliert werden. Wenn du dort ca. 9 ms einstellst, wird es funktionieren.

Ein echtes Laufwerk braucht ein paar Millisekunden beim Track Wechsel, bis zuverlässig vom nächsten Track gelesen werden kann.

Zitat von 1570

Ich würde davon ausgehen, dass Denise und Co die Testbench selbst auch laufen haben und wissen was geht.

In der Anfangszeit war das richtig oft, jetzt nur aller paar Monate oder wenn was gefixt wurde.

nightly (baut gerade)

Metal Graphics Api ist fertig. Metal ist nun automatisch ausgewählt. Es kann jedoch wieder auf openGL zurück geschalten werden. Das macht bestenfalls Sinn für ältere Macs, welche nur Metal 1 schaffen.

Diese Macs bekommen mit openGL mehr Shader ans Laufen.

clarkkent: CRT-GEOM-DELUXE aus dem RetroArch Shader Set benötigt Metal 3. Alle Silicon Macs sollten Metal 3 fähig sein.

Für Intel Macs gilt, wenn Graka Metal 3 fähig ist, dann muss dennoch mindestens BigSur installiert sein. (nicht sicher). Es brauchen jedoch nur wenige Shader zwingend Metal 3.

Mein 2014 MacBook Air mit High Sierra bekommt komplexere Bezel Shader nicht mehr hin. ist ok, wäre eh viel zu langsam dafür.

Metal performt auch schneller als openGL. Das sieht man, wenn man den Threaded Renderer abschaltet und FPS auf maximal stellt.

Denise ist abwärtskompatibel bis Mavericks. Metal steht jedoch erst ab High Sierra zur Verfügung.

Zitat von He-Man1982

Planst Du auch eine Version für den Apple-Store?

Nein, da ich keinen Bezahl Account bei Apple möchte.

Zitat von clarkkent

Wenn ich Denise ganz normal mit dem App-Icon starte, ist der Shader aber sofort aktiv. Genauso, wenn ich ein PRG mit Doppelklick im Finder lade. Nur bei einem DiskImage wird der Shader erst aktiv, wenn das Programm vom DiskImage geladen ist. Lege ich ein DiskImage unter "Software" ein, gibt es auch kein Problem mit dem Shader.

Jetzt wird es klar. Bei aktivem Autowarp werden die Shader unsichtbar geschalten um den Warp nicht auszubremsen.

Autowarp gibt es (wenn erlaubt) nur bei Disk und Tape, also alles was einen Motor hat.

Man sieht es gut, wenn man manuell mal den Warp aktiviert und dann wieder deaktiviert. Der Shader wird in dieser Zeit inaktiv.

Das ist kein Bug.

Zitat von clarkkent

Ein kurzes Video, damit Du siehst, wie der Shader momentan reagiert, wenn man ein DiskImage im Finder zum Starten doppelklickt.

Wo ist das Problem ?

Der Shader sieht nicht korrekt aus oder der Shader ist erst nach ein paar Sekunden aktiv ?

Ist die Warte Animation (drehender Kreis oben rechts) schon durch und das Video wurde erst danach aufgenommen ?

Der Shader benötigt eine Weile bis er einsatzbereit ist. Leider steht unter macOS openGL der Shader Cache nicht zur Verfügung.

Zitat von clarkkent

Und was mir noch bei den neuen Shader-Technik aufgefallen ist: Wird Denise durch einen Doppelklick auf ein Diskimage gestartet, funktioniert der Shader nicht richtig - sobald das Spiel allerdings vom Diskimage geladen ist, erscheint dann der Shader so wie er soll. Also praktisch während des Ladens funktioniert er nicht richtig.

weiß nicht genau was du meinst. ... wenn der Emu über Doppelklick auf eine Disk im Datei System gestartet wird ? also der Emulator an sich frisch hochgefahren wird oder wenn er bereits läuft ?

Das könnte schon gelöst sein. Bitte mal das letzte nightly probieren.

Zudem funktionieren nun unter macOS + openGL ein paar Shader mehr. z.B. im Ordner: bezel

Habe festgestellt, das spirv cross mehr Shader unterstützt, wenn zu openGL 4.0 anstatt zur unter macOS letzt möglichen Version 4.1 konvertiert wird.

Zitat von clarkkent

Was halt ein M1 für eine Grafik im Chip hat. Mich wundert nur dass CRT GEOM DELUXE unter MAME hier funktioniert, am Denise nicht

nach einigen Tests: Stimmt leider, eine gewisse Anzahl Shader funktionieren auch auf meinem ARM MAC nicht mit openGL.

Dabei spielt es keine Rolle, wie komplex die Shader sind.

So wie es aussieht, ist die letzte von Apple unterstützte openGL Version 4.1. Nur auf Windows und Linux wird openGL aktuell gehalten.

Apple hat openGL schon seit einigen Jahren als "deprecated" erklärt und setzt auf seine eigene API Metal (ähnlich D3D unter Windows)

Problem: spirv cross wandelt bestimmte Shader Features nur in nativen GLSL Code um, welcher eine aktuellere openGL Version benötigt.

Es ist vorstellbar, dass die spirv cross library in neueren Versionen lauffähigen Code für ältere openGL Versionen zu erstellen vermag.

Lösung 1: die nativen GLSL Shader, welche RA ja noch bereit hält, verwenden. Das würde das Problem "vielleicht" lösen oder zumindest verbessern.

Jedoch zielen diese Shader auf openGL 2 ab. Möglichweise sind die Shader abgespeckt und dann ist noch die Frage, in wie weit die GLSL Shader überhaupt noch gewartet werden.

Ich halte das für eine Sackgasse.

Lösung 2: Apples native Grafik API (Metal) einbinden, welche seit 2014 (High Sierra) verfügbar ist. und genau das ist der nächste Punkt auf der Liste

Zitat von clarkkent

Ich hab einige der CRT Shader probiert. Aber auf meinem iMac bekomme ich bei doch einer gewissen Anzahl "Shader Fehler". Ist das ein Problem am Mac oder woran liegt das?

wahrscheinlich an der Grafikeinheit (intel on board ?) + openGL.

Ich bekomme nur unter meinem ARM Mac mit einer neueren Intel GPU auch die komplexeren Shader ans Laufen.

Das könnte sich unter der gleichen Hardware verbessern, wenn Denise Metal unterstützt.

Auf meinem alten PC mit einer ATI Grafikkarte (>10 Jahre) bekomme ich unter D3D11 mehr Shader ans Laufen als mit openGL.

Mit einer unteren Mittel Klasse Geforce bekomme ich unter Windows alle Shader unter openGL und D3D11 gleichermaßen zum Laufen.

Mein Eindruck ist also, das openGL bessere Grafikhardware benötigt als D3D11.

Ich beginne demnächst mit Metal support. Dann bin ich gespannt in wie weit dir das hilft.

Zitat von Retro-Nerd

Was genau wäre denn daran so aufwendig? Eigentlich macht man ja nur HDR über Windows an und Denise sollte dazu die passende SDR zu HDR Farbkonvertierung machen.

hab mich noch nicht wirklich damit beschäftigt.

brauch aber nen extra internen Shader für die Konvertierung, eine veränderte DXGI swap chain.

hängt überall im Code mit drin und openGL hat wohl keinen HDR support ? zumindest sehe ich hier nix in RA.

Zitat von Retro-Nerd

Wolltest du da was mit regelbaren Nits= Leuchtkraft einbauen?

ja

max nits, paper white nits, contrast, expand gamut

Zitat von Retro-Nerd

Baust du irgendwann noch HDR Support mit ein? Damit man der Abdunklung des Bildes durch die CRT Shader wieder entgegenwirken kann? Da macht einen Riesen Unterschied, besonders auf OLEDs. Ohne würde ich z.B. meine Video Scaler gar nicht mehr nutzen wollen.

ja wollte ich eigentlich gleich mit machen, war aber dann doch zu viel Aufwand.

Ich habe meinen Monitor mal umgestellt aber konnte mich an die extreme Helligkeit noch nicht gewöhnen.

Zitat von PiCiJi

"guest advanced" gibt es auch als internen Shader.

verwechselt: lottes und trinitron sind die internen Shader, welche von den alten Denise Versionen übernommen wurden.

Zitat von clarkkent

Allerdings hab ich nicht kapiert, warum dort in aufklappbaren Ordnern „Shader“ und „ Parameter“ steht. Wie stellt man dann jeden geladenen Shader separat ein?

Das Aufklapp Menu unter Shader ist für erfahrene Nutzer und Shader Entwickler gedacht.

Unter Parameter werden alle Parameter gelistet, welche zum Shader gehören. Diese kannst du dann anpassen und im Emu Fenster schauen, wie es sich verändert.

In der Regel sind die Shader schon brauchbar vor konfiguriert.

Änderst du Parameter muss der Shader gespeichert werden. Der Speichern button ist in der Shader UI vorhanden. Am Besten man speichert in eine neue Datei ab und überschreibt nicht die Originale.

Auf diese Weise kann man später wieder auf die Werkseinstellungen des Shader zurück greifen.

Der veränderte Shader unter einer neuen .slangp Datei kann dann mit "Hinzufügen" zu den Favoriten ergänzt werden.

Zitat von clarkkent

Ich hab mir die Shader von den Seiten, die Retro-Nerd empfohlen hat, angesehen. Zum Laufen hab ich nur die mit der Endung .slangp gebracht. Am besten hat mir immer ein Shader namens CRT-GEOM-DELUXE gefallen - wie bekomme ich den in Denise?

Zitat von Retro-Nerd

Ein das Libretro Shaderpack runterladen. Unzählige Retroarch Shader für jeden Geschmack.

http://www.emu-france.com/emul…com/3677-cg-shaders-pack/

Das ist ungünstig, denn hier sind ja auch CG und GLSL Shader, welche nicht (mehr) unterstützt werden mit dabei. Die sind Horn alt und es gibt ja für alles Wichtige einen modernen Ersatz.

Denise unterstützt nur Slang Shader (slang oder slangp Dateien).

Slang ist das Standard Format von der Vulkan Graphics API, so wie GLSL von openGL, HLSL von Direct3D oder MSL von Metal (macOS).

Der Vorteil von Slang ist, das dieses Format so aufgebaut ist, dass man es in HLSL, GLSL oder MSL konvertieren kann. Das klappt nicht automatisiert mit realistischen Aufwand, wenn man die anderen Formate als Quelle nimmt.

Mit Slang ist man erstmals vernünftig in der Lage NUR einen Shader für alle Treiber zu schreiben und diesen dann automatisch in die nativen Shader Systeme (GLSL, HLSL, MSL) zu konvertieren.

Die Kronos Group hat das erkannt und einen Konverter gebaut. Dieser nennt sich spirV cross. RA und Denise verwenden diesen.

Hier kommt der Link, von wo RetroArch seine Shader holt, wenn man in der RA UI "Shader aktualisieren" klickt.

slangp Shader

oder wie im Denise UI sichtbar auf das RA Symbol klicken. Das lädt die Shader von diesem link.

Updates der Shader Autoren werden dann dort enthalten sein.

RA unterstützt die Slang Shader, aber auch noch ältere GLSL Shader, welche deutlich weniger sind und kaum noch gewartet werden.

Sie benötigen die GLSL Shader für openGL 1 und 2 Treiber. Erst openGL 3 kann vernünftig über Slang betrieben werden.

openGL 1 und 2 wird nicht in Denise unterstützt und wird es auch nie. Das ist die Zeit vor 2006 glaube ich. Heutzutage kommt das noch auf leistungsschwächeren Geräten oder so zum Einsatz.

Keine Ahnung wer das noch braucht, denn RA läuft ja nicht nur auf Desktop Computer.

Zitat von clarkkent

zeig mal ein paar Screenshots, wie das mit der Kombination funktioniert

na warte mal. erstmal ist es vielleicht besser den Link ein paar Zeilen höher auszuprobieren und die Slang Shader durch probieren.

Wenn du einen CRT Shader findest, der dir zusagt und schnell genug auf deiner Hardware läuft, gehen wir den nächsten Schritt.

Die, die gefallen, kann man dann in die Favoritenliste aufnehmen. Damit man diese nicht immer im Dateisystem neu suchen muss.

Wenn du nur eine alte Intel onboard GPU hast, werden einige Shader mit vielen Durchgängen nicht funktionieren. Das ist normal.

Amiga:

Vor allem für Amiga gefällt mir "/shaders_slang/bezel/koko-aio/Presets-4.1/monitor-bloom.slangp" gut.

Zudem lohnt auch die erwähnte Kombination mit den Denise PAL Shadern beim Amiga kaum, da bei RGB keine PAL Besonderheiten gelten und der Amiga im Gegensatz zum C64 keine

Geräte spezifischen Anomalien aufweist.

optimal (subjektiv): nur einen RA CRT Shader verwenden.

C64:

CRT guest advanced z.B., hylian ist auch ganz nett.

"guest advanced" gibt es auch als internen Shader. Ich habe ihn behalten (wird nicht gewartet), obwohl es diesen in den RA Shadern (wird gewartet) mit mehr Einstell-Möglichkeiten und Features gibt.

Damit Leute, welche sich nicht mit RA Shadern beschäftigen wollen, die gewohnten Möglichkeiten haben.

Der heftigste ist wohl "/Mega_Bezel/Presets/MBZ__0__SMOOTH-ADV.slangp"

Hier ist ein Wort der Warnung angebracht: Dieser Shader hat um die 45 Durchläufe und baut sogar einen CRT Rahmen um das Bild (fancy). Eine Grafikkarte sollte der Rechner also schon haben. Ein 15 Jahre alter Rechner mit Intel onboard Grafik wird zu einem schlimmen Ende führen

Für den Anfang kannst du also die beiden internen Shader: C64 svideo light + guest advanced kombinieren. Dann bräuchtest du dich "noch" nicht mit RA Shadern beschäftigen.

Zitat von clarkkent

vorhanden scheinen sie schon zumsein, nur eingebunden ist nichts davon automatisch - somit weiß jemand, der davon keine Ahnung hat, nicht mal was von deren Existenz…

genau, denn die sollen ja selber probieren, welche Shader ihnen am Besten gefallen. Wenn ich die alten automatisch einbinde, probieren einige nix Neues aus und würden sich dann bei Kenntnis darüber vielleicht ärgern, dass sie da was verpasst haben.

Die alten Shader sind alle noch da und wurden in das RetroArch Shader System konvertiert, damit ich nur ein System warten muss.

Bei der Auswahl der Shader im Menu Präsentation -> Shader sind die alten Shader erreichbar, indem als Verzeichnis "Internal" eingestellt wird. "External" sind dann die RetroArch Shader.

Die "alten" Shader sind eher als PAL Shader gedacht. (zur Darstellung der Farbmischung benachbarter Zeilen in PAL (passiert nicht in NTSC oder RGB) )

Die RA Shader sind CRT Shader, welche sich nicht für die Besonderheiten der einzelnen Systeme interessieren, sondern die Röhre beschreiben. Möglicherweise sind unter den RA Shadern auch welche dabei, welche zumindest PAL Farbmischung durchführen, nicht jedoch die Besonderheiten welche im C64 passieren und ohne Shader zu viel Rechenzeit benötigen würden.

Shader heißt nicht perse CRT Kram. Man kann alles, wo viele Pixel parallel manipuliert werden müssen/könnern, als Shader abbilden um die CPU zu entlasten.

Aus dem Grund habe ich von den alten Shadern eine Light Variante mit eingefügt. Diese enthält keine Shader für CRT, wie Maske, Bloom oder Scanlines. Das können die RA Shader viel viel besser. Ich hatte damals um sowas wie Vollständigkeit zu schaffen, simple CRT Shader mit eingefügt.

Sinn dieser Light Variante ist es nun, die PAL Shader mit den RA CRT Shadern zu kombinieren. So kann man beide Welten bekommen.

Die PAL Shader (Light) steuern nur die Farbmischung und fügen die Anomalien, welche im C64 auftreten hinzu. Die RA CRT Shader kümmern sich dann um Maske, Bloom, Schalines usw.

Will man 2 Shader kombinieren, lädt man z.B. erst den internen PAL Shader in der Light Variante und verwendet dann "Preset anfügen" um einen RA Shader für CRT Effekte hinten dran zu hängen.

Oder

man lädt zuerst den RA Shader und wählt dann "Preset voranstellen" um den PAL Shader davor zu schalten.

Wichtig ist das der CRT Shader zuletzt in der Kette steht.

Diese selbst zusammen gestrickten Ketten kann man dann auch speichern um sie unter Favoriten abzulegen.