wenn das aktuelle nightly nicht verwendet wird, sollte man beim reSID 8580 den Bias auf 0 stellen. Das ist der neue Default Wert, ansonsten klingt es verschieden zu VICE.
Ist klar, ändert aber nichts an der Tatsache, dass dieses Testfile von "Kickmaster64", in keinem der ganzen Emulatoren die ich testete (HOXS, Denise, VICE, CCS64, Z64K, Micro64) so klingt, wie auf meinen echten C64 Rechnern. Hab es gestern mal verglichen.
Das dir das klar ist, weiß ich. war als generelle info gedacht.
Endziel in Denise wird der 1200er mal sein, bzw. AGA-Fähigkeit?
ich hoffe doch.
Der Standard-Filter im Denise, der inzwischen ReSID heisst, in den aktuellen Versionen, ist genau derselbe Filter wie im aktuellen VICE
wenn das aktuelle nightly nicht verwendet wird, sollte man beim reSID 8580 den Bias auf 0 stellen. Das ist der neue Default Wert, ansonsten klingt es verschieden zu VICE.
"Vice 2.4": Schmiert im bestimmten Subbass Bereich total ab. Also klingt da total kaputt. (Wurde vor einiger Zeit gefixt)
für welchen Emu/Version wird noch was für den alten reSID 2.4 gefixt ?
Kleine Frage so am Rande. Wann baust du in die Amiga-Emulation die Unterstützung für Harddisk-Files ein?
im Oktober kommt die 2.4.
grober Zeitstrahl:
- C64 1581
- ...
- Amiga ECS Denise (A500+ / A600)
- Amiga HD
- ...
- Amiga 68020 CPU als Turbo Karte (noch kein A1200/AGA an der Stelle)
Problem: On screen Statusmeldungen in weis sind nicht immer zu Lesen, z.B. Amiga Workbench.
Unter Präsentation gibt es nun einen neuen Bereich "Bildschirmtext". Hier lassen sich die Status Meldungen anpassen.
Textfarbe, Hintergrundfarbe, Warnfarbe, Schriftgröße, Schriftart, Position der Meldungen, Innenabstand, Außenabstand
Es können auch weitere Schriftarten hinzugefügt werden, z.b. aus c:/Windows/Fonts oder unter Mac /Library/Fonts, Linux: /usr/share/fonts
Es können auch freie Schriftarten aus dem Netz verwendet werden.
Unterstützt werden TTF, OTF und TTC Dateien. Letzteres ist ein Container Format für TTF, welches eher unter Mac Verwendung findet.
Beim Hinzufügen eines TTC werden alle enthaltenen Fonts in Denise gelistet.
Hinweis: Will man wie in älteren Denise Versionen keinen Text Hintergrund haben, wird der rechte Slider für Alpha auf 0 gezogen. Zwischen Werte lassen die Text Box transparent erscheinen.
Der Emulator kann doch ein Minus im Namen ermitteln und findet er dort eines (egal wo im Namen), dann soll er in solchen Fällen, den Bezeichner einfach nicht abschneiden. In allen anderen Fällen aber schon. Was bringt das dann? Naja, dann schneidet er, bei derjenigen File-Benennung von Spiel-Serien, die sicherlich die allermeisten User momentan bei sich verwenden werden (wie etwa "Double Dragon", "Double Dragon 2", "Double Dragon 3" usw) bei Folge-Teilen den Bezeichner nicht mehr ab. Bei Multi-Disk Spielen täte er es aber noch, denn die wenigsten Nutzer werden doch bei dieser Art von Spielen, die Diskseiten-Zahl direkt hintendran stehen haben (da man sonst ja selbst nicht mehr wüsste, ob es nun Folgeteile von Spielen, oder weitere Diskseiten eines Spiels sind). Man kann sicherlich bei der großen Mehrzahl der User davon ausgehen, dass bei ihnen die beiden Diskseiten von "Double Dragon" eher "Double Dragon - 1" und "Double Dragon - 2" oder "Double Dragon - Seite 1" und "Double Dragon - Seite 2" oder so etwas in der Art heissen werden. Hier würde dann überall ein Minus gefunden und die Bezeichner dann abgeschnitten. Findet Denise keines, würde dies nicht passieren.
ich verstehe nur die Hälfte aber genug um zu merken, dass dies eine zu individuelle Lösung ist. Ich würde vorschlagen, dass jetzt hier nicht zu überstürzen, sonst fällt einem das ganz schnell wieder vor die Füße.
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.
------------------
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.
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.
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 ?
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.
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.
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.
Planst Du auch eine Version für den Apple-Store?
Nein, da ich keinen Bezahl Account bei Apple möchte.
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.
