Hello, Guest the thread was called11k times and contains 239 replays

last post from angryking at the

Denise 1.0.x Emulator

  • Quote from angryking

    Nö, es ist so, dass ich im gesamten Emu gar nichts schreiben kann, auch in keinem Dialog Feld. Meine Tastatur ist nirgends verfügbar. Alles tot.

    der direct input Treiber gilt nur als initialisiert wenn Maus und Keyboard ok sind. Möglicherweise lag es bei dem Rechner an der Maus und nicht am Keyboard. Ich habe es derart umgebaut, dass er auch als initialisiert gilt, wenn eines der beiden Geräte nicht erkannt wurde. Außerdem loggt er an kritischen Stellen. Könntest du bitte die Version aus dem Anhang dieses Postings mit dem Treiber Direct Input 8 nochmal testen. und mir den Eintrag im log file zukommen lassen. Es befindet sich unter user/AppData/Roaming/denise/log.txt.
    Anhang: musste zip in 3 parts splitten und umbenennen, da der uploader zip als suffix erwartet. zum Entpacken alle 3 Dateien derart umbenennen: Denise.001.zip in Denise.zip.001


    Quote from pastors

    Mir ist noch aufgefallen, wenn Denise minimiert in der Taskleiste ausgeführt wird, dann stockt der Sound.

    Mit Stocken meinst du stoppen oder klingt verzehrt? Unter Einstellungen gibt es eine Option "pausiere Emulator bei Fokus Verlust". Damit sollte er minimiert schweigen.


    zum Thema Cpu Nutzung schreibe ich gleich was. (wird mehr)

  • Quote from angryking

    "Sid Hazard" ist ja standardmäßig deaktiviert, aber auch ohne und mit neuem Build läuft 1 Core hier einfach immer auf 100% (Gesamt 25%). Ohne Fokus 12.5%
    Aktiviere ich "Sid Hazard", geht die Gesamt CPU Nutzung hoch (auf 37.5%) , also auf einem weiteren Kern. Ohne Fokus 25%

    ja gut bemerkt. Der Emulator spawnt 2 extra threads, der erste für "Sid Hazard" und der zweite für die floppy emulation (also ein thread für alle emulierten floppy).
    Der neue Build verhindert, das bei Aktivierung von Sid Hazard bei ausgeschalteter Emulation (nur User Interface aktiv) der Thread den idle Modus verlässt und einen Core komplett frisst.
    Ich vermute du meinst mit Leerlauf, wenn die emulation zwar läuft aber nur der Basic Screen zu sehen ist.


    Wird die Emulation gestartet, verlassen beide threads jeweils den idle Modus wenn Sid Hazard aktiviert ist/wird bzw. wenn bei Anzahl Disketten Laufwerke mindestens eins ausgewählt ist.
    Beide threads laufen dann unter Voll Last, bedeutet 2 cores auf 100% und der eigentliche emulations core kommt auch noch hinzu. (dieser verursacht jedoch keine Vollast bei pal/ntsc Geschwindigkeit)


    Du hast Recht, das muss nicht sein. Das hatte ich nicht mehr auf dem Schirm. Die threads warten mit maximaler Leistung auf Anweisungen vom Haupt thread.
    Ich baue das so um, das die benötigten threads in den idle Modus wechseln, wenn der Haupt thread das Kommando an das User Interface zurück gibt.
    Das passiert nach jedem frame um die inzwischen aufgelaufenen User Eingaben abzuarbeiten. Alternativ kann der idle Modus auch aktiviert werden, wenn die Kommunikation zwischen c64 und floppy aufhört.
    Letzteres könnte aber die Gesamt Geschwindigkeit reduzieren, wenn zu oft von bzw. in den idle Modus gewechselt wird.
    zurück ans Reißbrett :-)

  • Ich vermute du meinst mit Leerlauf, wenn die emulation zwar läuft aber nur der Basic Screen zu sehen ist.

    Richtig, Leerlauf ist natürlich keine korrekte Beschreibung, besser währe wohl "ready prompt".




    Wegen der CPU Nutzung... Auf meinem Notebook merke ich das ganz gut, wenn da der Lüfter hoch schraubt.
    Aber vor allem stellt sich mir die Frage, ob der Emu überhaupt noch "Reserve" hat um z.B. eine komplexe Demo laufen zu lassen, wenn er im "ready prompt" den Kern schon voll auslastet. Muss ich halt mal testen. :D


    Bei VICE ist es halt so, der läuft im "ready prompt" mit ganz wenig CPU Nutzung, die wird dann aber größer je mehr Emulation man startet (2. SID usw) und auch eben Komplexität des Programms.




    /edit:
    Log.txt von Anhang in #41


    Quote

    base init ok
    keyboard ok
    mouse ok

    Schaut gut aus, geht aber trotzdem nicht an meinem Acer NB. :P

  • Quote



    Mit Stocken meinst du stoppen oder klingt verzehrt? Unter Einstellungen
    gibt es eine Option "pausiere Emulator bei Fokus Verlust". Damit sollte
    er minimiert schweigen.

    Eigentlich hätte ich erwartet, dass minimiert die Anwendung normal weiterläuft. Ist halt beim Musik hören störend :)
    Ansonsten läuft die Software bei mir sehr gut.

  • Quote

    Aber vor allem stellt sich mir die Frage, ob der Emu überhaupt noch "Reserve" hat um z.B. eine komplexe Demo laufen zu lassen, wenn er im "ready prompt" den Kern schon voll auslastet. Muss ich halt mal testen.

    der Leistungs Unterschied zwischen prompt und komplexen Demo ist überschaubar. Der Emulator synchronisiert jeden Halbzyklus, egal ob die Anwendung komplex ist oder nicht. ;-)
    Ich habe auf meinem alten Core I5 von 2011 je nach Software zwischen 120 - 140 fps mit einem emulierten Diskettenlaufwerk.
    Ja der Emulator hat ein Grundumsatz wie ein Body Builder beim Nichts tun :-) Das ist hauptsächlich meiner Motivation für dieses Projekt geschuldet, nämlich übertrieben hoher Genauigkeit und gut lesbarer Quellcode. Mir ist bewusst, das es nicht für jedes notebook in Hinsicht auf Leistung geeignet ist.


    Quote

    base init ok
    keyboard ok
    mouse ok

    hmm, das habe ich nicht erwartet. Wie zum Geier geht das dann? Eigentlich sollte es bei dem Log laufen. Ich melde mich diesbezüglich, wenn mir was neues einfällt.


    Quote

    Eigentlich hätte ich erwartet, dass minimiert die Anwendung normal weiterläuft. Ist halt beim Musik hören störend
    Ansonsten läuft die Software bei mir sehr gut.

    kannst du ja umstellen.

  • 1.0.3.1
    -------
    reduced drive thread cpu usage greatly (a extra core has consumed permanently 100%)
    - some system settings, which consumes additional cpu power, are highlighted
    improved user input capture process
    - it's now easier to assign multiple inputs at once (i.e. Alt + Shift + S)
    - it's now selectable to overwrite (default) or append an existing mapping
    added kernal, basic, char and 1541 bios files
    - can be replaced by custom versions


    Dieses schnelle release sollte zum einem den sinnlos hohen Cpu Verbrauch reduzieren und zum anderen die Bedienung verbessern.
    Wollte man vorher 2 oder mehr Tasten zugleich mappen, musste man diese schon ziemlich zum gleichen Zeitpunkt erwischen.
    Das ist jetzt nicht mehr so streng. Zudem werden bestehende Zuweisungen nicht mehr ergänzt sondern ersetzt.
    Dies lässt sich jedoch per radio button in das alte Verhalten zurück ändern.
    Ich habe jetzt die bios files hinzugefügt. Diese werden verwendet, sollte unter der jeweiligen firmware keine Zuweisung existieren.

  • Beobachte das schon einige Zeit und dieses KILLERfeature interessiert mich am meisten. Den Kosmetikfirlefanz kann man später machen ^^

  • Stört mich nicht, bei mir scrollt alles dauerhaft superflüssig. Freesync sei Dank. :D


    Für mich ist das Killerfeature Input Lag Minimierung. Erst gestern mal wieder Giana Sisters per Emulator gezockt (ok, aber leicht mondartig) und dann per EasyFlash am echten C64+Röhre (alles superfluffig).

  • Quote from Retro-Nerd

    Die Gesamtlast sinkt bei mir auf 27%, ein wirklich annehmbarer Wert.
    Stört mich nicht, bei mir scrollt alles dauerhaft superflüssig. Freesync sei Dank.

    ich habe ca. 11 % auf meinem 4 Kern System.
    Ich nehme an, du hast nur "audio sync" aktviert, da vsync durch dein freesysnc scharf ist.
    audio sync kostet aktuell einiges an Cpu Ressourcen, da ich damit die pal/ntsc Geschwindigkeit reguliere. Der Emulator wartet im audio Treiber, wenn er zu schnell ist.
    Die Kontrolle wird jedoch nicht an das OS dabei zurück gegeben und somit nicht für andere Prozesse zur Verfügung gestellt.
    video sync ist deutlich schonender. Wenn ich vsync mit oder ohne audio sync aktiviere, komme ich auf die 11 %. Aktiviere ich nur audio sync komme ich auf 25 %.


    Du schriebst bereits, dass du perfektes scrolling hast. Wie sieht es mit audio aus (audio sync aktiv), irgendwelche auffälligen Ton Störungen wenn der emu mindestens eine Minute läuft ?
    Wenn dies nicht der Fall ist, hast du in der Tat mit freesync / gsync keinen weiteren Vorteil durch 'dynamic rate control'.


    Mit einem normalen Monitor sollte der Effekt wie folgt sein: (für pal muss der Monitor auf 50Hz im Vorfeld eingestellt werden)
    1. audio sync: keine sound Verzehrungen aber scrolling hoppelt aller paar Sekunden, fängt sich dann wieder und so weiter.
    2. vsync: perfektes scrolling, aber nach kurzer Zeit, können 20 oder 30 Sekunden sein, verzehrt der sound einige Sekunden. fängt sich dann wieder und so weiter
    3. vsync + audio sync: genau wie 2. aber weniger schlimm.


    Grund: der Emulator liefert audio samples wie das Original für pal 50.12 Hz und ntsc 59.94 Hz. Der TFT liefert aber 50 bzw. 60 Hz glatt oder zumindest nicht genau wie die Röhre.
    4. dynamic rate control: die geringe Gegenläufigkeit zwischen vsync und audio sync wird durch eine geringfügige, dynamische (also ständige) Anpassung der sample rate neutralisiert.
    Nachteil: emu läuft 1 - 2 % langsamer (pal) / schneller (ntsc) als das original. Dies sollte aber für einen Menschen nicht spürbar sein.


    Quote from Ferkels Willem

    Beobachte das schon einige Zeit und dieses KILLERfeature interessiert mich am meisten

    ich überarbeite aktuell die audio Treiber, weil:
    1. dynamic rate control (killer feature)
    2. weniger CPU Last wenn nur audio sync aktiv, siehe Erklärung oben.

    Quote from Retro-Nerd

    Für mich ist das Killerfeature Input Lag Minimierung.
    Wirst du irgendwann Drag & Drop PRG/D64 Start mit einbauen? Wenn man einen Dateimanager offen hat ist das manchmal recht nützlich um schnell was zu testen.

    auf der Liste

  • Quote

    ich habe ca. 11 % auf meinem 4 Kern System. Ich nehme an, du hast nur "audio sync" aktviert, da vsync durch dein freesysnc scharf ist. audio sync kostet aktuell einiges an Cpu Ressourcen, da ich damit diepal/ntsc Geschwindigkeit reguliere. Der Emulator wartet im audio Treiber, wenn er zu schnell ist. Die Kontrolle wird jedoch nicht an das OS dabei zurück gegeben und somit nicht für andere Prozesse zur Verfügung gestellt. video sync ist deutlich schonender. Wenn ich vsync mit oder ohne audio sync aktiviere, komme ich auf die 11 %. Aktiviere ich nur audio sync komme ich auf 25 %.


    Sieht bei mir ähnlich aus. Mit Vsync allein (oder in Kombination mit Audio Sync) komme ich auf ca. 15% Auslastung.



    Quote

    Du schriebst bereits, dass du perfektes scrolling hast. Wie sieht es mit audio aus (audio sync aktiv), irgendwelche auffälligen Ton Störungen wenn der emu mindestens eine Minute läuft ? Wenn dies nicht der Fall ist, hast du in der Tat mit freesync / gsync keinen weiteren Vorteil durch 'dynamic rate control'.

    Nur mit Audio Sync habe ich keine Probleme. Problematisch wird es bei mir mit Open GL (Direct3D is stabil) und nur Vsync an, dann gibt es FPS Schwankungen, mit Soundkratzern, stockendens Bild für einen Bruchteil einer Sekunde. Wasapi ist da noch besser als DirectSound, klingt aber trotzdem nicht schön.

  • Ich vermute aktiviertes vsync bei einem freesync / gsync Monitor beißt sich. Direct3D schaltet möglicherweise vsync dann nicht durch.
    Im Gegensatz zu audio sync ist vsync kein vom emu Autor programmiertes feature.
    Gerade für Leute mit freesync/gsync ist es wichtig das audio sync ohne vsync den Cpu Kern nicht blockiert um die Geschwindigkeit zu regulieren.

  • Nein, hast du falsch gelesen. D3D ist generell Ok. Freesync war im Treiber und Monitor deaktiviert. Das Gestottere passiert nur bei OpenGL in Vsync. Aber nur Audio Sync ist mit OpenGL+Freesync ja völlig ok. Nutze derzeit halt OpenGL in Denise, weil die interessantesten Shader nur als OpenGL Higan Shader vorliegen.


    Nunja, sinnvoll ist die Dynamic Rate Control schon. Denn mein 4K Panasonic TV hat eh keine Freesync/G-Sync Technik (haben neuere Samsung TVs z.B.). :D

  • Die meisten Emulatoren haben eine schlechte GUI. Selten sieht man etwas aufgeräumtes und reduziertes.


    So auch hier. Die Kunst ist es... möglichst alles wegzulassen. Man startet die App, und es läuft.


    Bei diesem Emu läuft leider nichts. Das schlimmste ist derzeit die Firmware files festzulegen. Wenn man den C64 starten will meckert er über die nicht vorhandenen Kernal, Basic, Dateien... die aber unter App/Resources vorhanden sind. Man kann auch keine selber hinzufügen, weil das komplette Fenster dazu ausgegraut ist. Löscht man die Dateien unter App/Resources, kann man endlich die gelöschten Dateien wieder hinzufügen. Aber auch das ist spartanisch. Das erste File "muss" man per drag&drop platzieren, die anderen per "open". Startet man die App neu, kann man wieder nichts ändern, bis man alle Files wieder unter App/Resources löscht.


    Die Menüs: Schlecht. Ich weiß ich klinge miesepeterich, aber es ist wie es ist, ärgerlich. Und das muss man zum Ausdruck bringen.
    Da ist alles unlogisch. Die 3 Menüpunkte, sowie de Submenüs, und die Icons.


    Wenn der Emu startet, dann blinkt der Cursor wie verrückt (sogar schneller als 60hz). Da stimmt also irgendwas nicht.



    Im Allgemeinen: wenn ich einen C64 Emu schreiben würde, dann würde nach dem Start es nur folgende Einstellungen geben:


    Joystick: Switch
    Status: Running/Pause
    Snapshot: Load/Save
    SID: 6581/8580, Filter.
    VIDEO: 50/60 Hz
    Keyboard Auto Layout (nach dem Start wird man aufgefordert die C64 Tasten nach wunsch zu drücken [,.- ...] )


    Load Prg, D64, CRT inkl. Diskchange würde ich rausschmeissen und alles per Drag & Drop machen. Das ist am einfachsten.
    Zieht man ein D64 File auf die C64 Emualtion, dann öffnet sich ein File Auswahl-Fenster mit dem Inhalt der D64 Disk, und man kann ein File das man starten möchte anklicken (jeweils mit ,8 und ,8,1 option rechts daneben).


    Ich würde noch nicht mal eine CRT-Emulation Option anbieten, sondern eine die immer aktiv ist, und perfekt aussieht, so das man überhaupt nicht wechseln will. Und ohne CRT-Emulation sehen die Spiele alle häßlich aus, weil zu viele Ecken. Und Kernal, Basic usw. ist schon im Code eingebaut (keine externen Files), so wie bei Frodo.


    All den anderen Schnickschnack kann man sich sparen, bzw. so wie Apple es tut, verstecken.


    Denn all diese Optionen brauchen nur Programmierer.


    Die Idee C64 und Amiga in einem Emu zu mixen... keine gute Idee, man ärgert sich nur über das aufgeblähte Menü, weil alles 2x vorhanden ist.


    Ansonsten, ... mach ihn perfekt.

  • Puh, ne. Kann ich vieles nicht nachvollziehen. Das ist meines Erachtens auch wenig konstruktive Kritik.


    1. Die Firmware Files kannst du immer auswählen, und zwar wenn der Powerbutton aus ist. Im laufenden Betrieb ist es ausgeraut. Was auch Sinn macht.


    2. Die Menüs selbst sind sehr aufgeräumt. Mitunter kann man das Layout bestimmter Optionen noch verbessern, und Doppelbelegungen über andere Menüpunkte vermeiden. Da stimme ich zu.


    3. Die Emulation läuft nur schneller, wenn der Monitor mehr als 50Hz anzeigt und dabei Vsync aktiviert ist. Oder wenn generell überhaupt kein Sync (weder Video noch Audio). Dann läuft es scheinbar auf Fullspeed, also was die PC Host CPU so hergibt.


    4. "Load Prg, D64, CRT inkl. Diskchange würde ich rausschmeissen und alles per Drag & Drop machen. Das ist am einfachsten." Darüber könnte man reden. Wirkt etwas steif. Aber per Hotkeys ist alles leicht zu erreichen.


    5. Das mit der standardmäßigen CRT Emulation/Shader Filter kann man nicht machen. Sowas muß immer optional sein. Ich kann auch ohne CRT Shader nichts mehr emulieren. Aber es gibt viele Leute, die den klaren und verpixelten Look mögen.



    PiCiJi :


    ich muß mich korrigieren. Die FPS Schwankung samt Audio Probleme bei Vsync (in 50Hz)+OpenGL liegt eindeutig am Dual Monitor Setup (der Panasonic TV als erweiterter Desktop in einer anderen Hz Rate als der PC Monitor). Es gibt also derzeit kein Problem, wenn nur 1 Bildschirm aktiv ist. Läuft alles bestens. :thumbsup:

  • Quote

    Nein, hast du falsch gelesen. D3D ist generell Ok. Freesync war im Treiber und Monitor deaktiviert.

    ja ein Missverständnis, ich dachte free sync war noch an.

    Quote

    Die FPS Schwankung samt Audio Probleme bei Vsync (in 50Hz)+OpenGL liegt eindeutig am Dual Monitor Setup (der Panasonic TV als erweiterter Desktop in einer anderen Hz Rate als der PC Monitor).

    ja ich habe auch diverse Probleme mit opengl unter Windows. Unter Windows 7 läuft es. Bei gleicher Hardware unter Windows 10, jedoch mit anderem Graka Treiber beschränkt opengl bei vsync auf 30 fps.
    Mein Dual Monitor Setup stellt aber kein Problem für opengl dar. (beide haben aber ähnliche Daten)
    vsync Probleme sind leider meistens Treiber Probleme. Meine Graka ist von 2011. Ich hatte jetzt nur noch keine Lust einen älteren Treiber zu testen.
    Das ist alles ein guter Grund für die cg shader, welche auch unter D3D funktionieren.

    Quote

    So auch hier. Die Kunst ist es... möglichst alles wegzulassen. Man startet die App, und es läuft.

    das funktioniert vielleicht bei Spielkonsolen. Für Computer sind zahlreiche verschiedene Herangehensweisen zu berücksichtigen.

    Quote

    Wenn man den C64 starten will meckert er über die nicht vorhandenen Kernal, Basic, Dateien... die aber unter App/Resources vorhanden sind. Man kann auch keine selber hinzufügen, weil das komplette Fenster dazu ausgegraut ist. Löscht man die Dateien unter App/Resources, kann man endlich die gelöschten Dateien wieder hinzufügen. Aber auch das ist spartanisch. Das erste File "muss" man per drag&drop platzieren, die anderen per "open". Startet man die App neu, kann man wieder nichts ändern, bis man alle Files wieder unter App/Resources löscht.

    Im C64 kannst du die firmware ja auch nicht wechseln, wenn er an ist. (erst System -> Ausschalten drücken)
    Du kannst im firmware Tab drag'n'drop nutzen oder den open Dialog. Das nur das erste per drag'n'drop geht und die anderen zwingend mit 'open' kann ich nicht nachvollziehen.
    Das Löschen der Dateien unter App/Ressources hat nichts damit zu tun eigene Pfade zu setzen.
    Das funktioniert so. Zuerst versucht der emu die manuell zugewiesene firmware zu laden. Sind die Felder leer oder die Pfade outdated, versucht er die mitgebrachte firmware zu laden.


    Ich vermute mal das lief ungefähr so ab:
    - emulator meckert über fehlende firmware
    - die Fehlermeldung spuckt die Pfade aus dem App Container aus
    - du hast gesehen, das die Pfade im firmware Tab leer waren und wolltest diese setzen.
    - ging aber nicht, weil ausgegraut. du hast heftig geflucht. :-)
    - du hast den emu komplett ausgeschalten und die firmware manuell im app Container gelöscht
    - emu an, aber c64 emulation erstmal noch nicht mit power gestartet. du hattest den Eindruck das durch das Löschen die Pfade jetzt zuweisbar sind.


    Wenn die firmware Felder bei dir leer waren, hätte die mitgebrachte firmware eigentlich geladen werden sollen. Das könnte ein bug sein. Kannst du die manuell im firmware Tab zugewiesene nochmal entfernen (Auswerfen button), dann die c64 emulation starten und mir den Fehlerpfad posten.

    Quote

    Die Menüs: Schlecht. Ich weiß ich klinge miesepeterich, aber es ist wie es ist, ärgerlich. Und das muss man zum Ausdruck bringen.
    Da ist alles unlogisch. Die 3 Menüpunkte, sowie de Submenüs, und die Icons.
    Im Allgemeinen: wenn ich einen C64 Emu schreiben würde, dann würde nach dem Start es nur folgende Einstellungen geben: ...

    Ich glaube wenn ich es an der Stelle jedem Recht machen will, drehe ich mich im Kreis.
    Zudem habe ich das Gefühl, dass alle Optionen die du nicht brauchst wahrscheinlich auch kein anderer brauch.

    Quote

    Wenn der Emu startet, dann blinkt der Cursor wie verrückt (sogar schneller als 60hz). Da stimmt also irgendwas nicht.

    hier gebe ich dir Recht. Das macht den falschen Eindruck. Ich werde als "default", also wenn der emu das erste Mal verwendet wird, audio sync setzen. (pal/ntsc Geschwindigkeit)
    Im Moment läuft der emu beim Erst Start so schnell wie er kann. Das ist Quatsch.

    Quote

    Zieht man ein D64 File auf die C64 Emualtion, dann öffnet sich ein File Auswahl-Fenster mit dem Inhalt der D64 Disk, und man kann ein File das man starten möchte anklicken (jeweils mit ,8 und ,8,1 option rechts daneben).

    habe ich vor. ich würde nach so einer drag'n'drop Aktion für prg / crt sofort starten und für disc / tape in den entsprechenden emu Tab wechseln.
    Dort kann man per Doppelklick auf ein Listing, wie bereits jetzt schon möglich, den Ladeprozess starten.
    der disk change/swapper Bereich ist eher für Amiga gedacht. Der c64 kann ja immer nur eine Seite der disk lesen. Andernfalls muss man diese drehen.
    Da man die Rückseite der disk nicht parallel in einem anderen Laufwerk betreiben kann, unterstützen nur wenige Spiele ein 2. Laufwerk.

    Quote

    Load Prg, D64, CRT inkl. Diskchange würde ich rausschmeissen und alles per Drag & Drop machen. Das ist am einfachsten.

    ich persönlich mag es, wenn nach einem Start des emu die letzten eingelegten Medien sofort verwendbar sind. Dann drücke ich nur noch power.
    Bei einem richtigen System springen die discs / tapes ja auch nicht von alleine aus den Laufwerken, wenn der Computer abgeschalten wird.

    Quote

    Ich würde noch nicht mal eine CRT-Emulation Option anbieten, sondern eine die immer aktiv ist, und perfekt aussieht, so das man überhaupt nicht wechseln will. Und ohne CRT-Emulation sehen die Spiele alle häßlich aus, weil zu viele Ecken.

    Um Gottes Willen. Jeder hat andere Vorlieben und durch die Möglichkeit verschiedene shader einzusetzen, können die auch gut bedient werden.
    Es gibt keine perfekt aussehende CRT Emulation, schon gar nicht für jeden. Zudem ist die Optik einer Röhre mit keiner Software auf einem TFT Monitor identisch nachbildbar.
    z.B. mag ich keine scanlines. Schon auf der Röhre sah das unschön aus. Ich habe kein Verlangen mir das auf einem TFT anzuschauen.
    Durch die Emulation + shader hab ich für mich persönlich die Möglichkeit das bessere Original zu erschaffen.
    Aber ja, ganz ohne Filterung sieht es unbrauchbar eckig aus. Das würde nur Sinn machen, wenn das unveränderte Bild an ein Endgerät übertragen wird, welches selber filtert.
    Ich würde beim Erst-Start des Emulators den linearen Standard Filter von opengl/d3d aktivieren. (kann natürlich deaktiviert werden)
    Alles weitere machen dann die shader.

    Quote

    Und Kernal, Basic usw. ist schon im Code eingebaut (keine externen Files), so wie bei Frodo.

    habe ich überlegt. Macht es das rechtlich nicht noch problematischer als es schon ist ?

    Quote

    Die Idee C64 und Amiga in einem Emu zu mixen... keine gute Idee, man ärgert sich nur über das aufgeblähte Menü, weil alles 2x vorhanden ist.

    Wahrscheinlich hast du Recht aber das gehört zu meiner Motivation für dieses Projekt. Aber ja, die c64/amiga Untermenus stören mich auch.
    Ich denke ich teile das System Menu in 2 menus auf, jeweils für ein System.

  • Quote

    Das ist alles ein guter Grund für die cg shader, welche auch unter D3D funktionieren.


    Weiß gar nicht, ob das unter Windows 10 mit aktuellen Treibern so gut funktioniert. Dieser CG Toolkit Kram kam doch von nVidia. Irgendwann wollte ich das mal für meine Radeon RX 560 installieren, irgendwie ging das nicht mehr mit den CG Shadern in diversen Emulatoren. Der ältere PC hatte keine Probleme unter Windows 7 damals. RetroArch hat wohl die Vulkan/Slang Shader für Direct3D (aber nicht kleiner als 10, war mir so) portiert, so das alle aufwendigen Multi-Shader auch dafür verfügbar waren. Oder kannst du das irgendwie intern im Emulator kompatibler machen?


    edit: Die schreiben auch selbst, das CG eigentlich schon Geschichte ist und GLSL und HLSL (welches leider oft nicht die aufwändigen Multishader hat) genutzt werden sollen.



    Quote

    NVIDIA was proud to introduce programmable shading with Cg, which supported dozens of different OpenGL and DirectX profile targets. It allowed developers to incorporate interactive effects within 3D applications and share them among other Cg applications, across graphics APIs, and most operating systems (Windows XP, Vista and Windows 7, Mac OS X for Leopard, Snow Leopard & Lion, Linux 32-bit & 64-bit) as well as balance effect complexities with client GPU capabilities. Going forward, we recommend new development with GLSL, or HLSL for Windows applications, rather than Cg.

  • Quote from Autor

    5. Das mit der standardmäßigen CRT Emulation/Shader Filter kann man nicht machen. Sowas muß immer optional sein. Ich kann auch ohne CRT Shader nichts mehr emulieren. Aber es gibt viele Leute, die den klaren und verpixelten Look mögen.


    Meiner Meinung nach ist ein grundsätzlicher Fehler. Beim C64 konnte man sich das auch nicht aussuchen, und es war ein riesiger Erfolg.


    Es geht nicht darum was 1 Million Leute wollen, sondern wie man das Produkt intuitiv, handlich und übersichtlich macht. Die 5% die damit unzufrieden sind, die kann man vernachlässigen. Wenn 1 Million Leute mitreden könnten wie das iPhone auszusehen hat, dann würde Windows bei rauskommen: 1 Millionen Einstellungen + Kuddelmuddel GUI (obwohl ich mittlerweile auch denke das das iPhone immer komplizierter als einfacher wird, Jobs tot... und schon machen die bei Apple Unsinn ;-) - war ja bei Commodore ohne Jack Tramiel auch so).


    Das kann man machen, aber damit tut man den "Benutzern" keinen Gefallen.


    Wenn man 17 Submenüs und 200 Funktionen einbauen will, dann sollte man zumindest einen "Easy" Mode und "Hardcore" GUI Mode einbauen.


    Ich baue mittlerweile keine Dropdown/Submenüs mehr ein. Wenn das verlangen dazu doch mal steigt, ist es Zeit die GUI zu überdenken, und weiter zu reduzieren. Mein Motto: es geht alles, man muss nur lang genug nach der Lösung suchen. Programme und GUI einfach weiter aufblähen kann jeder :-)

  • ja die cg Shader scheinen etwas in die Jahre gekommen zu sein. Angeblich laufen die unter Ati. Aber du schreibst ja, das es auf Windows 10 möglicherweise nicht mehr so ist.
    Ich muss mich erst mit den cg shadern intensiv beschäftigen.
    Ich möchte alle wichtigen retroarch shader unterstützen. Wenn es für all diese cg shader GLSL / HLSL Versionen gibt, würde es in der Tat kein Sinn mehr machen cg einzuführen.
    Denise unterstützt multiple GLSL shader passes im Allgemeinen. Die sind dann aber nicht parameterisiert, heißt alle Parameter müssen im shader direkt gesetzt sein.
    Denise untersüzt nur die Parametrisierung von higan, nicht jedoch retroarch. Ich glaube Snes9x unterstüzt die specs von retroarch aktuell.
    Da fällt mir ein, ich habe im letzten release eingebaut, dass die higan shader manifest Dateien mit oder ohne .bml Endung geladen werden können.


    Vulkan und dessen slang shader sind Neuland für mich. Das wird noch ne Weile dauern, bis ich soweit bin.