Beiträge 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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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

    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.

    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.


    Wolltest du da was mit regelbaren Nits= Leuchtkraft einbauen?

    ja

    max nits, paper white nits, contrast, expand gamut

    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.

    "guest advanced" gibt es auch als internen Shader.

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

    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.

    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?

    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.

    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.

    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.

    In Denise 2.3 unter MacOS ist das Menü "Shader" plötzlich ein Ghostmenü und läßt sich nicht öffnen. Mit 2.2.1 ging das noch wunderbar, CRT-Trinitron finde ich einfach genial.

    Das wurde umgebaut. Dieses Menu enthält nun die Favoriten, welche erst unter Präsentation -> Shader hinzugefügt werden können.