MultiColor Interlace (MCI) Konverter in Python/Windows

Es gibt 36 Antworten in diesem Thema, welches 1.934 mal aufgerufen wurde. Der letzte Beitrag (11. März 2025 um 12:29) ist von ivettaB.

  • Hallo Leute ,

    Sende Euch meinen MCI PC Grafikkonverter.

    nach dem ich bei Herrn Rottensteiner den Artikel über den multikolor Interlace mode gelesen habe, habe ich gleich den Konverter für PC Bilder geschrieben.
    Vielleicht braucht es jemand ? Sourcecode im Archiv.

    Auf dem PC Bilder in den Ordner schieben und einfach konvertieren.

    Nach dem linker.bat hat man eine fertige C64 Programm Datei mit Anzeige Code.

    Sourcen sind im Projekt.

    Wenn jemand was sinnvolles daran erweitert bitte um Info.

    Das Bild ist jetzt nicht so wie in echt da ich das Interlace nicht fotografieren konnte. Aber es sieht echt besser aus wenn der Code läuft...

    Das Programm nimmt ein Bild und passt Grösse an, führt ein Steinberg dithering durch und konvertiert es in zwei Multicolor Grafik Dateien,

    welche mit linker.bat automatisch in eine ausführbare Datei gewandelt werden.

    Windows und python 3.12 erforderlich.

    Andere Farben:

    Wer den Multicolor.asm mit anderen Farbwerten benötigt kann das in den ersten Zeilen erledigen, die grafik includes am Ende rauslöschen (sonst ist ein anderes Bild drinnen) und das assemblieren. diese prg datei zu play.prg umbenennen. fertig.


    --------------------------------------------------------------------------------------------------------------------------------

    Bedienung:

    Bild laden, Auto Helligkeit oder mit Reglern spielen, Resize Bild (320x200) , konvertieren drücken.
    Danach finden sich zwei "converted...." Bilddateien im Ordner (ohne startadressen)

    Nun im Ordner die Linker.bat aufrufen und sich eine foo-out.prg Datei erzeugen. Dies ist eine ausführbare C64 Datei mit dem Bild und dem Interlace Anzeige Programm.

    Inkl. Exomizer packer. Sehr praktisch.

    Was brauchts:

    Windows PC mit python 3.12 oder höher , auf der Kommandozeile im Konverterordner:

    pip install -r requirements.txt

    alle pakete installieren.

    Startgui.bat aufrufen.

  • 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.

  • toll. Danke für diese Reise. Damals war wirklich eine tolle Zeit. d.H TFT nicht gut ?!

    wegen der halben auflösung verschiebt der player die 2. bitmap um 1 pixel nach rechts (scrollreg) dann sieht es beim betrachten so aus

    als wenn wieder 320x200 pixel da sind obwohl es nur 160x200 sind.

  • Kiregt man das ohne Python hin?

    Meine Frage wäre eher: Kriegt man das auch ohne Windows hin? ;) (Python habe ich)

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Die requirements.txt erfordert :

    Zitat

    matplotlib==3.8.3

    numpy==2.2.3


    Wenn ich versuche, das so zu installieren, dann kommt aber:

    Zitat

    ERROR: Cannot install -r requirements.txt (line 1) and numpy==2.2.3 because these package versions have conflicting dependencies.

    The conflict is caused by:

    The user requested numpy==2.2.3

    matplotlib 3.8.3 depends on numpy<2 and >=1.21

    ???

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Das hatte ich auch.

    Bei mir hat es gereicht NumPy aus der Requirements.txt rauszunehmen.

    Dann wurde alles installert. Er hat mir dabei auch noch die alte numpy und das alte mathplotlib deinstalliert und dann die passenden Versionen installiert.

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • leider ohne fastload im Moment...

    So leider finde ich das gar nicht... mich stören eingebaute Fastloader eher, weil sie in der Regel deutlich langsamer als Jiffydos oder Dolphindos sind.

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • danke für die Rückmeldungen. Wusste nicht das ich eine alte Numpy hatte. Naja ...

    Kein Fastload OK. Ob es auf Linux geht habe ich nicht getestet. Python sollte gehen aber der Linker.bat müsste dann ein Bash Script werden und der exomizer müsste irgendwie eine Linuxvariante sein ..... Ich verwende ihn zum Linken der Bilder und komprimieren.

    Anhang:

    DISK Image Slideshow. Hatte im Slideshowplayer einen Fehler entdeckt welcher einen Stacküberlauf machte (irgendwann später)

    slide.asm : slideshow source, startadresse $c000 ,

    slide.prg : ausführbares Programm

    slideshow.prg : diese Datei muss als erste Datei auf eine leere Disk, danach die Bilder welche ihr Euch generiert. Das ist das gleiche wie slide.prg

    aber mit Basicstart somit lässt sich das einfach in Images als Autostartdatei verwenden.

    ach ja, der slide.prg ladet die Bilder welche man mit dem MCI Konverter generiert hat. weil ich dort aber keine Leertastenabfrage drinnen hatte patcht der slideshowplayer das Binärfile mehrmals (es verändert den Exomizer depacker und den play.prg). Wenn jemand jetzt viele Änderungen, im multicolor.asm (welches das play.prg ohne Bilder ist) wird der patcher an der falschen Stelle die Leertastenabfrage einbauen und das Progrmm wird falsch abbiegen.

  • Kiregt man das ohne Python hin?

    Meine Frage wäre eher: Kriegt man das auch ohne Windows hin? ;) (Python habe ich)

    Ich kann ehrlich gesagt nichts sehen, was windowsspezifisch sein sollte. Die Batsch-Datei natürlich, aber da steht nur `python mastergui8.py` drin. Den Befehl kann man auch direkt im X-Term eingeben. Evtl. muss man dabei `python` durch `python3` oder `python3.11` oder sowas ersetzen...

  • meine die linker.bat nicht das startgui ...... da steht exomizeraufruf mit den einzelnen parts zum linken drinnen.

    Wenn wer das auf Linux macht bitte ein archiv machen und hier reinstellen. danke

  • Bist du sicher dass der Artikel von einem Herrn Rottensteiner ist? Gibt's da noch andere? :)

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Für diejenigen die ganze Bildordner auf einen Satz konvertieren möchten gibts jetzt die Konsolenanwendung.

    python consolenman.py

    usage: consolenman.py [-h] input_dir output_dir

    consolenman.py: error: the following arguments are required: input_dir, output_dir

    Das output_dir ist ein Verzeichnis für temporäre Dateien.

    welches existieren sollte.

    Die PRG Dateien wandern direkt in dieses Verzeichnis aus dem Sie den Konsolenkonverter

    starten.

    passt gut zum Slideshow Programm welches als erstes ins D64 Image muss.

  • 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.

  • ich weiss jetzt nicht auswendig ob ich den Zufall genommen habe. Eigentlich hatte ich dem floydsteinberg Algorithmus verwendet welcher normalerweise für Monochromdarstellung verwendet wird. Habe das auch getestet aber nicht raufgeladen.

    Hier habe ich den Algorithmus aber auf 8 Graustufen angepasset welche ich mit 2 MCU Bildern a 4 Graustufen durch Mischung erzeuge.


    Bastle aber auch an einem echten MCU Farbkonverter welcher aber noch nicht gut läuft... siehe:
    Bitte melde dich an, um diesen Link zu sehen.