Ja, genau. Habe die Version nun ein paar Tage. Hatte übrigens das .deb-Paket geladen.
funktioniert.
Please login to see this link.
Posts by PiCiJi
-
-
Kleine Anmerkung am Rande: Habe mir vor ein paar Tagen die Version 2.7 herunter geladen. Diese bezeichnet sich selbst jedoch noch als 2.6.
kann ich nicht nachstellen ... Du meinst doch die Versions Angabe in der Titelzeile der Anwendung ?
-
nightly: fix Codeboys & Endians
Das mit den Sprites ist nicht notwendig. Bereits ein veränderter Start Zyklus des VIC beim Hardware Reset reicht aus damit es unter Dolphin DOS funktioniert. Das timing ist so wackelig.
vorher: Zeile 0 -> letzter Zeilen Zyklus (warum hatte ich das gemacht ...)
jetzt Zeile 0 -> Zyklus 10 (startet bei memory Refresh Zyklus)
-
Dolphin und Standard Kernal initialisieren offensichtlich den VIC-II geringfügig anders. Denn damit es immer mit Dolphin Kernal nach einem Hard Reset funktioniert, reicht es aus wenn im Emulator Code beim power up Sprites "enabled" werden und Y auf $f.
Ich habe es nie getestet, aber ich vermute auf einem echten System werden nur die wenigsten Register durch die Hardware mit festen Werten initialisiert. (nicht deterministisch nach dem Einschalten) Die Software muss sich "rechtzeitig" darum kümmern.
-
Je nach Zeitpunkt des Soft Reset funktioniert es. Das ist bestimmt ein Initialisierungs Problem, denn beim Hard Reset wird in Denise bis auf ein paar Ausnahmen der gleiche Zustand gesetzt.
-
Code
Display More## 2.7 * added screenshot generation * option to merge two adjacent frames (e.g. interlace) * option to generate multiple screenshots at a set interval * option to take native or scaled, filtered screenshots * C64: support for USBSID-Pico was added by LouDnl * C64: added support for 2 MHz * C64 in C128 mode: e.g. Sonic, SNK vs CAPCOM (C128 version), Eye Of the Beholder, Mario * Hotkey to force 2 MHz for games that can handle it but don't support it * 2 MHz status LED * C64: added PALette measurements by Tobias as new default for color generation * C64: support for Structured Basic CRT was added by ClausS * support MP3 for audio recording * fix: mouse is found when changing the USB port (Windows) * disk finder: guessing follow disks or tapes take archives into account * support HDR for Windows (D3D11) and macOS (Metal) * monitor must support this and be activated in the OS and emulator * support black frame insertion (BFI) to reduce motion blur * monitor requires support for higher refresh rates, e.g. 100, 150, 200, 250 Hz... * BlUR BUSTERS CRT Simulation GPU Shader ... advanced BFI read more: https://blurbusters.com/crt-simulation-in-a-gpu-shader-looks-better-than-bfi/ * added rewind support * you can rewind a few seconds while playing, e.g. to avoid the loss of a life * the function must be assigned to a hotkey, ideally the gamepad * added option to prepend YUV (S/C-Video) PAL/NTSC color encoding to a CRT shader * default setting for C64 * added CoreAudio3 driver for macOS -
Die Farbcode Erstellung basiert nun auf den Messungen von PALette (Tobias) anstatt Colodore (Pepto). Wenn eine Palette ausgewählt ist, ändert sich nichts.
Es gibt nun also 3 Basis Einstellungen: Palette, Farb Spektrum PALette (default), Farb Spektrum Colodore.
Zudem gibt es nun einen neuen Paletten Eintrag: PALette
Gibt es einen optischen Unterschied bei der Auswahl PALette/Colodore als fixe Palette oder Farb Spektrum?
Ja geringfügig:
Bei der Farbspektrum Emulation wird aus den Messungen (luma, YUE angle, amplitude) im Allgemeinen YUV berechnet und im Speziellen bei Colodore nach der PAL Emulation Gamma (Vorgabe von Pepto) eingerechnet und bei "PALette" gibt es separate Messungen für gerade und ungerade Zeilen.
Bei Auswahl der Colodore RGB Palette wird daraus YUV zurück gerechnet und da die Gamma Korrektur bereits in der Palette steckt, ist das ermittelte YUV nicht gleich.
Bei Auswahl der "PALette" RGB Palette wird daraus YUV zurück gerechnet und das ermittelte YUV ist ein Mix Wert aus geraden und ungeraden Zeilen. Getrennte Werte sind somit nicht möglich.
Zusammenfassend gesagt ist der korrekteste Weg, wenn die Farb Spektrum Emulation verwendet wird.
-
nightly
Structured Basic CRT von ClausS in Denise integriert. danke dafür
Wenn ein Shader geladen wird, öffnet sich nun die Parameter Ansicht, anstatt die einzelnen Shader Passes anzuzeigen, welche in der Regel nur für Entwickler interessant sind.
Es gibt nun im Shader Menu eine Option "YUV-Kodierung" (für C64 vorausgewählt). Der VIC generiert Luma (Helligkeit - Schwarz/Weis) und Chroma (Farbe), anstatt RGB. Erst im CRT wird dies in RGB übersetzt.
Bilddaten werden vor der Übergabe an den gewünschten Shader in Luma/Chroma (AV, Composite, S-Video) zerlegt, PAL/NTSC Kodierung angewandt und danach wieder in RGB zurück übersetzt. Das ist kein CRT Effekt, sondern Farb-Kodierung. Jedoch ist auch hierfür ein Shader effektiver als die CPU.
Dieser extra Shader (und dessen Parameter) wird automatisch vor den gewünschten Shader geschaltet. Für NTSC ist diese Option weniger von Bedeutung, als für PAL, wo die Farbigkeit (Chroma) benachbarter Zeilen gemischt ist.
"play-with-colors.prg" zeigt wie die Zeilen bei PAL ineinander gemischt werden.Please login to see this attachment.Please login to see this attachment.
Die beiden markierten Felder dürfen sich nicht zur gleichen Farbe mischen, erst grau dann grün.
Viele CRT Shader berücksichtigen PAL-Kodierung nur rudimentär.Für Amiga ist dieser extra Shader nicht vorausgewählt.
Der übliche Übertragungsweg ist direktes RGB, wo benachbarte Zeilen nicht gemischt werden.
Möchte man allerdings Composite oder S-Video übertragen, kann man diesen zuschalten.
Bei RGB Übertragung gibt es keinen Unterschied zwischen PAL und NTSC in der Farbkodierung.
PAL und NTSC unterscheiden sich hier nur in der Bildgeometrie voneinander. (Anzahl Zeilen, Bildwiederholrate)folgende Parameter dieses vorgeschalteten Shaders beziehen sich hauptsächlich auf Anomalien, welche im C64 hervorgerufen werden.
Luma-Latenz (default: aktiviert)
Der HF-Modulator im C64 verursacht, dass eine Erhöhung der Helligkeit nicht sofort im nächsten Pixel sichtbar ist. in "emusuxX0r-crest.prg" ist der Text nur lesbar, wenn Luma Latenz emuliert wird.
Please login to see this attachment.VIC-Glitches (default: nicht aktiviert)
Die Signale AEC, BA, RAS, CAS, PHI0 haben minimalen Einfluss auf die Helligkeit. Das ergibt so eine Art Kachelmuster.Chroma Subsampling (default: nicht aktiviert)
Chroma Subsampling ist eine Art der Komprimierung, bei der die Farbinformationen in einem Signal zugunsten der Luminanzdaten reduziert werden,
um die Bandbreitennutzung zu verringern, ohne die Bildqualität wesentlich zu beeinträchtigen. Auf Farb-Änderungen reagiert das Auge weniger schnell als auf Änderungen der Helligkeit.Hanover Bars (nur PAL) (default: nicht aktiviert)
Durch die Mischung benachbarter Zeilen mit dem Ziel das Problem von NTSC (never the same colour) zu lösen, kommt es in älteren CRT zu minimalen Entsättigungen jeder 2. Zeile.anbei noch die beiden PRG's zu den Grafiken Please login to see this attachment. Please login to see this attachment.
-
nightly: Rewind - Hotkey um ein paar Sekunden zurückzuspulen, wenn man mal wieder die Platform nicht erwischt hat
für Amiga und C64
aktivierbar unter: Präsentation -> Rewind
Optionen:
Bilder pro Schritt: Anzahl der Bilder, nach welchen ein vergangenes Bild dargestellt wird.
Puffer Größe: Wie viel Arbeitsspeicher wird dafür verwendet.
In Abhängigkeit dieser beiden Optionen ergibt sich, wie weit zurück gespult werden kann.
Bei einer Schrittweite von 1 wird der Ton beim Zurückspulen rückwärts abgespielt, andernfalls stumm geschaltet.
Hotkey:
Der Hotkey muss noch gesetzt werden unter Steuerung -> globale Hotkeys -> Rewind (zweite von oben) ... Doppelklick auf diese Zeile ausführen und gewünschte Taste(n) drücken.
Am Besten weist man den Hotkey auf eine freie Taste am Gamepad zu.
-
Denise läuft bei mir weiterhin problemlos, nur diese Meldungen springen mir beim Systemupdate immer wieder ins Auge.
ok werde die runtime updaten
Vielen Dank!
das aktuelle nightly ist nun mit org.freedesktop.Platform Version 24.08 gebaut.
-
Denise läuft bei mir weiterhin problemlos, nur diese Meldungen springen mir beim Systemupdate immer wieder ins Auge.
ok werde die runtime updaten
-
Im Software-Menu passt es, da ist es super. Aber im Datei-Fenster ist die Größe der Vorschau suboptimal und ich habe keine Möglichkeit gefunden sie (oder die Schriftgröße) zu ändern.
Das könnte locker doppelt oder drei mal so hoch (und in voller Breite, fehlt ja nicht viel) sein:
Hattest du die Register Karte "Dialog Vorschau" gefunden? letzter Eintrag unter Disk, Tape, Steckmodule usw.
Dort wird die Ansicht des Datei-Fensters (OS System Dialog) konfiguriert, nicht die Ansicht im Software Menu.
Die Ansicht im Software Menu ergibt sich dadurch, wie groß das Software Fenster aufgezogen ist und bedarf somit keiner weiteren Einstellung.
Die Bezeichnung "Dialog Vorschau" ist wohl etwas ungünstig. Es legt den Gedanken nahe, dass damit die Vorschau im Software Fenster angepasst wird.
-
Beim Laden eines D64 fände ich es sehr praktisch wenn man das Options-Fenster mit der Vorschau irgendwie größer ziehen könnte (oder die Größe irgendwo voreinstellen kann, falls das einfacher ist).
Bei macOS ist diese sogenannte "accessory View" leider nicht rechts zum Datei Fenster positionierbar.
Im Software Baum Menu gibt es einen Eintrag ganz unten "Dialog Vorschau". Dort kann für macOS die Höhe des Options (Vorschau) Fenster angepasst werden.
Bei Windows und Linux kann dort nur die Weite des Vorschau Fensters angepasst werden. Die Höhe ist nicht notwendig, da diese immer der Höhe des gesamten Datei Dialoges entspricht.
In diesem Menu kann auch die Schriftgröße der Vorschau angepasst werden. Die Vorschau kann auch deaktiviert werden oder im Software Menu angezeigt werden, welches sich dann öffnet, wenn man im Datei Dialog etwas auswählt.
Ich wollte es nur melden. Wie gesagt, es ist nichts gravierendes. Mich wundert bei Linux nix mehr, warum da alles nicht so skaliert.
Das ist bei Windows und macOS genau so. Da wird nix skaliert, wenn die Elemente nicht mehr hinpassen, wie es im WEB üblich ist.
Die meisten Emulatoren verhindern, dass die Settings Fenster in ihrer Größe verändert werden können. Ich habe mir gedacht, das nicht zu tun, da je nach Sprache, mehr oder weniger
Platz nötig ist. Der Nutzer stellt sich die gewünschte Größe ein, welche dann mit abgespeichert wird.
-
Wird alles wieder normal, wenn man das Fenster wieder vergrößert. Keine große Einschränkung.
Da fehlt dann der Platz für die Elemente. GTK Themes haben ziemlich großer Steuerelemente. Vor Jahren habe ich über ein extra Stylesheet die meisten Elemente kleiner dargestellt.
Das ist aber nicht gewollt und man sollte doch die Vorgaben des Themes respektieren.
Man könnte eine Sperre einbauen, das das Fenster nicht zu klein gezogen werden kann.
Staune echt wie du das so machst.
manche Sachen sind schneller gemacht als andere. Der Credit geht hier eher an die beiden Autoren des CRT Simulation Shader.
-
DL des neuen Nightlies erscheint aktuell nur unter Win/Mac. Linux sieht bei mir so aus.
Linux builds sind begrenzt, da diese bei einem anderen Anbieter mit Credits (Open Source Credits) gebaut werden.
Ich habe es angestoßen und es steht nun bereit.
-
Black Frame insertion + CRT simulator shader
Unter Präsentation gibt es nun die Möglichkeit Vielfache der Bildwiederholrate einzustellen mit dem Ziel die Bewegungsunschärfe zu reduzieren.
Dafür braucht man einen Monitor, welcher in der Lage ist mindestens 100 Hz zu fahren, besser mehr ... viel mehr.
Z.b.: mein Monitor (ViewSonic XG270) schafft 240 Hz
Stoppp: Hier ist ein Wort der Warnung angebracht.
Die schnellen Wechsel der Pixel Zustände bei zu hohen Wiederholfrequenzen können bei einigen Monitoren zu Bildnachleuchten führen, was in der Regel ein temporärer Effekt ist.
google: image retention
Jedoch kann es auch zu dauerhaften Schäden kommen. Ein LCD IPS Panel sollte keine Probleme haben.
Es gibt 2 BFI Modi
typisch
Unter Präsentation -> BFI stellt man die vorher gesetzte Auflösung des Monitors ein. Der Wert in Klammern bezieht sich auf NTSC Emulation.
Läuft der Monitor mit 150 HZ, stellt man diese hier ein. Es werden dann hinter jedes angezeigte Bild 2 schwarze Bilder nachgeschoben.
Die Verdunklung ist normal und der Nachteil dieses Verfahrens.
Bei mehr als einem schwarzen Bild (also 150 HZ und mehr) kann man nun entscheiden ob alle zusätzlichen Bilder schwarz sind oder das aktuelle Bild wiederverwendet wird.
bezogen auf 150 Hz wäre es somit: Bild, Bild, schwarz
Man findet somit einen Kompromiss zwischen Bewegungsschärfe und Helligkeit
Blur Buster's CRT beam racing simulator shader: (BFI mit weniger flicker und besserer Helligkeit)
Ebenso wie beim typischen BFI stellt man die Monitor Auflösung ein und wählt diese im Emulator aus. Anschließend wird die darunter stehende Checkbox "Shader Sub-Frames" an gehakt.
Ein Shader steuert nun die schwarzen Bilder und deren Intensität.
Dazu lädt man aus dem RA Shader Paket: subframe-bfi/crt-beam-simulator.slangp
Der Shader sollte über seine Parameter angepasst werden um den besten Effekt zwischen Helligkeit und Bewegungsunschärfe in Abhängigkeit der verwendeten Bilderwiederholrate zu bekommen.
Please login to see this link.
Der bevorzugte CRT Shader kann an diesen BFI Shader angehängt werden über "Preset anfügen".
Schaut euch nun mal im Shadow of the Beast Intro Scroller den vordersten Layer an, welcher sehr schnell durch scrollt.
Man erkennt nun, wie auf einem CRT, die einzelnen Mauersteine. Um so mehr Hz, desto klarer: 50 -> 100 -> 150 -> 200 Hz
Oder Sonic im ersten Level, wenn man richtig speed aufnimmt und ohne abgebremst zu werden am Ende des Levels an den Plamen vorbei saust, erkennt man nun die Palmen als solche.
Beide BFI Modi lassen sich auch sehr gut mit VRR kombinieren. (nicht vergessen: VRR im Emu und Monitor anschalten)
ein paar allgemeine Infos:
Grafik Treiber werden in Denise unter Optionen -> Treiber eingestellt.
erwähnte BFI Techniken funktionieren nicht so gut unter openGL, wie mit den nativen Treibern.
Windows:
Sicherlich durch Windows oder Grafik Treiber Updates funktioniert nun VRR im Fenster Modus weder in Win10 noch 11. (bei mir) (immer noch die selbe Grafikkarte)
Unter openGL läuft VRR nicht mal mehr im Vollbild, selbst unter Win 10 nicht.
Ältere Versionen des Emulators, wo es sicher lief, bestätigen das kein bug diesbezüglich rein kam.
Durch Treiber Updates können die Karten schnell mal neu gemischt werden.
Es sollte keinen Grund geben openGL unter Windows D3D11 (nativ) vorzuziehen, eventuell bei älteren Rechnern.
macOS:
Auch hier ist die Performance von openGL mit neueren Versionen schlechter (VSYNC springt nicht immer an) und man sollte auch hier prüfen ob der native Treiber (Metal) ausgewählt ist.
Bei Systemen aus der Anfangszeit von Metal profitiert man allerdings von openGL, da ältere Metal Versionen weniger Shader als openGL unterstützen.
Linux:
Unter Linux gibt es keinen nativen Treiber. Es bleibt erst mal bei openGL, bis Vulkan hinzu kommt.
Nur das klassische BFI funktioniert unter Linux.
X11 ist veraltet, der Nachfolger ist wayland. wayland kam über viele Jahre nicht aus den Puschen und die Leute haben schnell wieder zurück zu X11 gewechselt, aufgrund der vielen bugs.
Nachdem was ich gelesen habe, ist wayland nun soweit und bietet wohl einige Vorteile beim Monitor Management.
Denise hat noch keine wayland Unterstützung und es wird auch noch Jahre dauern bis die meisten User dauerhaft zu wayland fähigen Distributionen wechseln oder dies in ihrer
Distribution aktiviert haben.
Abschließend noch ein paar Shader Hinweise:
Bei Wunsch nach einem Bezel (Monitor Rahmen) Shader sollte man nicht die Mega Bezel Shader verwenden. Diese sind sehr performance hungrig und ohne eine halbwegs moderne Grafikkarte ein Show Stopper.
Für Bezel Shader sollte man den Ordner "bezel\koko-aio\Presets-4.1" öffnen und durch probieren, welches Preset am Besten gefällt. Diese unterscheiden sich in der Maske und der Bezel Größe.
Grundsätzlich handelt es sich um den gleichen Basis Shader "koko-aio" aber mit unterschiedlichen Parametern.
Wem der Bezel Rahmen zu viel des Guten ist, wird im Shader Ordner unter "crt" fündig. Die Bezel Shader sind im Grunde diese CRT Shader nur mit Rahmen.
Im Emulator gibt es nach dem Laden eines Shaders zwei weitere Einträge im Baum Menu: Shader und Parameter.
Der Menu Punkt "Shader" ist eher für Shader Entwickler gedacht. Es zeigt die einzelnen Shader der Kette an, welche deaktiviert werden können und in der Reihenfolge der Abarbeitung
verschoben werden können.
Über den Menu Punkt "Parameter" lässt sich ein Shader konfigurieren. Das Resultat kann dann als neue Shader Datei gespeichert werden.
"Speichern" findet man in der Parameter Ansicht.
Ein gespeicherter, veränderter Shader kann ebenso unter Favoriten abgelegt werden und beim Emulator Start direkt geladen werden.
Man sollte nicht unbedingt die Shader Datei vom Hersteller überschreiben um später darauf zurückgreifen zu können.
Ein paar mögliche Anpassungen für den "koko-aio" Shader, ausgehend von einer hellen Palette (Community Colors).
Da nicht alle Parameter auf eine Karte passen, bekommt das Parameter Menu weitere Unter Menu Einträge, wo man sich durchklicken kann oder man klick direkt im Parameter Menu auf "weiter". Die Benennungen der Einträge im Baum Menu entsprechen dem ersten Parameter der jeweiligen Karten.
folgende Einstellungen habe ich ausprobiert:
Karte: CVBS: Bandwidth
CVBS Bandwidth: 1
Colorspace: PAL
Karte: Resolution
Mask Type: z.B. 5 für eine gröbere Maske
Karte: Halo: Gamma
Halo: Gamma out: 0.8
Karte: Zoom
Zoom: um die Größe des sichtbaren Bezel Rahmens zu reduzieren
Karte: Parameters app delayed when using DeltaRender
Spot an: 1
Eine dezente Aufhellung kann mittels der Parameter X/Y über den Screen positioniert werden. Zudem kann die Größe des hellen Flecks über "Size" geändert werden.
Am Besten den Fleck sehr klein schalten um diesen besser zu finden, dann positionieren und dann auf die gewünschte Größe bringen.
hier ein paar Beispiele mit den obigen Parametern
Please login to see this attachment.
gröbere Maske und schmalerer Rahmen
Please login to see this attachment.
Reflexion im Rahmen
Please login to see this attachment.
-
Nein – es handelt sich um keinen Denise-Fehler (Auslastung o.ä.), sondern es geht einfach darum, dass man (ich) Zeit braucht, um vom Auslösen des Screenshots (per Menü oder Shortcut) die Hände wieder dort an der Tastatur (oder Gamepad) zu haben, wo man sie zum Spielen benötigt. Um diese Zeit zum Umgreifen zu haben, wäre (für mich) ein kurzer (optionaler) Countdown/Timer/Verzögerer sinnvoll, dann könnte man das ohne Stress machen.
Es gibt im Screenshot Menu nun eine Checkbox um den Start 3 Sekunden zu verzögern. Übrigens kann man den Hotkey zum Erstellen von Screenshots auch auf das Gamepad zuweisen.
Besagte Menüpunkte enthalten nun "..." am Ende.
-
Als ich mal Wasapi probieren wollte, ist das Programm abgeschmiert, resp. kläglich hängen geblieben. Und zwar so, dass ich es nicht mal beenden/abschiessen konnte, egal wie.
Wasapi Exclusive oder Shared ?
Wasapi Exclusive macht alle anderen Anwendungen stumm, z.b. ein laufendes Youtube Video. Vielleicht wird diese Übernahme durch irgendeine Anwendung verhindert und der Wasapi Treiber hängt dann, wobei ich von diesem Verhalten von User Seite noch nicht gehört habe.
Liegt eventuell an Windows 7 und älterem Treibermaterial.
Exclusive Mode: bei Gelegenheit teste ich es mal unter Win7, keine Ahnung ob ich das getan habe.
-
Mir fiel auf, dass ich nach dem Starten einer "Aufnahme" immer erst einen kurzen Hänger habe, die aufzuzeichnenden Aktionen auszuführen
ich vermute du nimmst mehrere frames auf einmal auf ohne dabei auf Zwischenbilder zu verzichten? Skaliert oder unskaliert ?
Der Emu ist also ausgelastet und reagiert nicht auf den virtuellen Joystick und wenn dieser reagiert, sind die Screenshots schon durch ... habe ich das so richtig verstanden
Denise ist nun aber ein Multiplattform-Programm und ich weiß nicht genau, wie andere Plattformen das handhaben – aber zumindest für den Mac fände ich es schön (und übersichtlich), wenn man das ähnlich den anderen Programmen handhaben könnte.
das sind die Art von Details, auf die ich nie achten würde. Aber schaden kann es ja nicht und wenn ich einige Programme hier durchklicke, ist es tatsächlich so, das einige Optionen die drei Punkte zeigen.
-
Bei Denise bekomme ich nur bei fixen 50Hz ein stabiles Scrolling zum Beispiel. Also verhält sich C64emu schon mal toleranter.
Wenn dein Monitor auf 60 Hz läuft, sollte auch die Emulator Geschwindigkeit auf 60 FPS geschaltet werden.
Huch?
wegen einer für die meisten fälle sinvoll gewählten Einstellung soll das spiel 20% schneller laufen?
Was machen wir bei 144Hz? Lassen das spiel mit 288%iger geschwindigkeit laufen?
Ne, so war das nicht gemeint, das Spiel 20 % schneller laufen zu lassen um ein vernünftiges Scrolling zu bekommen.
Die Aussage ist, das man ein vernünftiges Scrolling nur bekommt, wenn Monitor Rate exakt zur Emu Geschwindigkeit läuft oder ein exaktes Vielfaches davon ist.
Möchte man sich damit nicht beschäftigen bzw. die Bildwiederholrate seines Monitors nicht anpassen oder denkt gar nicht darüber nach,
ist Interpolation sicherlich eine gute Möglichkeit das Ergebnis zu verbessern.
Der Emu liefert in dem Beispiel 50 FPS und durch Interpolation werden daraus 60 frames (Monitor läuft mit 60 Hz)
Um das in Echtzeit zu erreichen, werden benachbarte Bilder gemischt (crossfading) um Zwischenbilder zu erzeugen.
Auf diese Weise werden 10 zusätzliche Bilder erzeugt, die nicht vom C64 generiert worden.
Das hat 2 Nachteile:
1. ghosting, eher zittern (in Giana Sisters auf den Hintergrund achten oder die Schrift im Intro Scroller)
2. noch mehr Input Lag, da man ohne AI die Bewegung nicht vorausberechnen kann, können also nur bereits generierte Bilder interpoliert werden. Die Anzeige befindet sich also
zusätzlich zum Vsync noch weiter in der Vergangenheit.
Ich packe es mal auf die todo Liste. Einige können gut damit leben, dann hat es auch seine Daseinsberechtigung.
