Beiträge von atomcode im Thema „MultiColor Interlace (MCI) Konverter in Python/Windows“

    Das Ergebnis war also nicht schlecht, und vor allem - das war ja das Ziel - wirklich flimmerarm. Allerdings eben nur mit fünf Graustufen und kein Multicolor.

    Hier ein Beispiel als 50 Hz-Video. Dabei muss der Monitor eben auch auf 50 Hz eingestellt sein, sonst funktioniert es nicht. Irgendwo hatten wir uns noch über die Sache mit der C64-Bildfrequenz und der von modernen Monitoren unterhalten. Hab den Überblick verloren. Mein Monitor läuft mit 50 Hz, und das Video zuckelt dabei nur ganz selten, weniger, als wenn ich es im Emulator laufen lasse. Aber, und darum ging es mir dabei, wenn es einmal synchron mit dem Monitor ist, dann ist das Flimmern nur schwach, da die Farben bei dem Bild nicht nur abwechseln, sondern zusätzlich möglichst gut gemischt sind.

    Für das Mischen hatte ich, wie gesagt, einen riesigen algorithmischen Aufwand betrieben. Wenn ich das richtig verstanden habe, machst Du das per Zufall. Ist wahrscheinlich gar nicht so viel schlechter. Uns kam es halt darauf an, dass z.B. bei einer Linie wirklich ein Punkt auf den anderen abwechselt. Und, na ja, in Multicolor ginge das wegen der Restriktionen eh nicht so einfach.

    Ein weiterer "Trick" gegen das Flimmern ist natürlich, möglichst nur Farben zu mischen, die in der Helligkeit nicht so weit auseinanderliegen, also nicht Gelb mit Dunkelblau oder so. Dazu kann man am besten eine Tabelle vorbereiten, die den Farbraum mit möglichst nah liegenden Farben aus den 16 Originalen und den flimmerarm Gemischten abdeckt.

    Bitte melde dich an, um diesen Anhang zu sehen. => Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    d.H TFT nicht gut ?!

    Hat Vor- und Nachteile. Bzgl. Interlacefarben eher Nachteile.

    weil die flickerei die meisten menschen verwirrt .... ausser uns nerds :wink:

    Ui, lange Geschichte bei mir. Ich versuch's mal zu umreißen ...

    Daaaaamals ... C64 und Moni 1802. Das erste Mal von Interlace-Farben gehört. Verschiedene Software-Modi gab's da, OK, ganz nett, aber mein erster Gedanke war, ob man das Flimmern nicht noch irgendwie reduzieren könnte. Denn insbesondere bei flächigen Farbwechseln störte mich das auch auf dem CRT. Nun gab es ja auch noch das andere Mischverfahren, das Dithering. Ich weiß noch, wie ich mit meinem älteren Bruder zusammensaß und wir diskutierten, ob man diese beiden Verfahren nicht geschickt kombinieren könnte. Das ist eine meiner schönsten Erinnerungen an diese Zeit.

    Den Kern dieser Überlegung hatten wir zwar in Angriff genommen und halbwegs gelöst, aber noch längst nicht optimal. Die Aufgabenstellung klingt im ersten Moment einfach: Verteile alle Punkte auf den beiden Bildern so, dass keine Flächen, Linien oder verstreute Punkte entstehen, die es nur in einem der beiden Bilder gibt und somit stark flackern würden. Ich weiß noch, wie die Diskussion begann. Bruder schlug wechselndes Schachbrettmuster vor. Ich sagte ok, und was ist mit 45°-Linien oder bereits vorhandenen Schachbrettmustern? Die würden dann wieder flackern. Am Ende waren es 12 Passes, die sogar in Assembler eine Weile dauerten, bis die beiden Bilder gut gemischt waren, und letztes Jahr bemerkte ich, dass es da noch immer Probleme geben kann.

    In Multicolor ist das ja noch mal ein anderes Thema, weil sich wegen der Restriktionen die Pixel nicht beliebig mischen lassen. Wir konzentrierten uns auf HiRes und nannten das neue Format einfach Super HiRes, kurz SHR, bei dem eine Monochrom-Auflösung von 640 x 400 px heruntergesamplet wurde. In Wirklichkeit war es also die normale HiRes-Auflösung, bei dem 4 Punkte zu einem Punkt mit einer von 5 Graustufen gerendert wurde. Dafür wurde ein Sprite-Layer eingesetzt, und das bedeutet leider eine Reduzierung der Breite auf 192 px, bezogen auf die "simulierte" Auflösung aber immerhin eine Breite von 384 px, und wie wir wissen, erzeugt eine höhere Punktdichte den Eindruck einer besseren Qualität, obwohl die Auflösung dieselbe bleibt. Ihr kennt das: Man sieht ein 320x200-Bild unvergrößert auf einem PC-Monitor, und es sieht dann oftmals besser aus als in groß.

    Das Ergebnis war also nicht schlecht, und vor allem - das war ja das Ziel - wirklich flimmerarm. Allerdings eben nur mit fünf Graustufen und kein Multicolor. Mit dem Multicolor-Modus ist das Verfahren wegen der Restriktionen nur sehr eingeschränkt möglich, und man hat dann auch nur die halbe Auflösung. Da würde sich eher anbieten, das sorgfältig von Hand zu pixeln, bspw. für Sprites, nachdem man dann Spritemuster und Farben frameweise umschaltet.

    Heute ist das alles für mich nur noch eine nette Erinnerung. Da wir damals eigentlich ein Spiel entwickeln wollten, aber unsere Zeit damit verbrauchten (ich sage bewusst nicht "verplemperten"!), dem C64 Eigenschaften zu entlocken, die er eckdaten-mäßig nicht hat, um auf diese Weise das Spiel aufzuwerten, hat mich das Ganze später zum Umdenken bewegt. Aber, was Interlace-Farben angeht, auch weil CRT-Monitore stark zurückgegangen sind und weniger nerdige Leute jetzt eher einen TFT verwenden, der in den wenigsten Fällen genau mit den Frames synchronisiert.

    Das Bild ist jetzt nicht so wie in echt da ich das Interlace nicht fotografieren konnte.

    Ich mache das immer so:

    1. Emulator anschmeißen

    2. Bild starten

    3. Pause drücken

    4. Frame als PNG speichern

    5. Taste für Frameweiterschaltung drücken

    6. Frame als PNG speichern

    7. Beide Bilder ins Bildbearbeitungsprogramm laden

    8. Bild 2 mit 50 % Transparenz über Bild 1 legen

    9. Gemischtes Bild als PNG speichern