Bild 1
Multicolor-Darstellung eines IFLI-Bildes: nicht mehr als 16 Farben
Was ist das? Wie geht das?
Eine ganze Reihe der erst im Laufe der Jahre entdeckten C64-Features beruht auf optischen Täuschungen, die bekannteste darunter ist die wundersame Vermehrung der 16 eigentlich unveränderlichen C64-Farben auf bare 136 Farben im IFLI-Modus. Weniger bekannt (aber genauso erstaunlich) ist die Erzeugung von ziemlich echten 3D-Bildern mithilfe von Anaglyphen und Stereogrammen. Andere optische Illusionen nutzt GoDot beim Erzeugen von Bewegtbildern und beim Antialiasing.
Dieses Tutorium fasst zusammen und erläutert vielleicht genauer, was hier bei den einzelnen beteiligten GoDot-Modulen bereits nachzulesen ist. Wir erzeugen:
1. Mischfarben erzeugen
Um das Auge zu überlisten, bedarf es nicht viel: Man muss nur zwei unterschiedliche Dinge klein genug machen und nahe zueinander stellen. Schon sieht es so aus, als habe man ein einziges Ding mit einer neuen Qualität. Im ersten Beispiel kann man das deutlich nachvollziehen, Bild 2 und Bild 3 sehen sich doch recht ähnlich, oder? Bild 2 scheint viel mehr Farben zu enthalten als nur 16. Stimmt aber nicht. Die Kästchen mit dem weißen Punkt links oben sind die 16 "unverfälschten" C64-Farben. Bei den anderen Kästchen in Bild 2 erkennt man bei genauem Hinsehen, dass sie aus zwei Farben aufgebaut sind, die abwechselnd untereinander stehen, jede Rasterzeile ist anders gefärbt als die darüber.
RevealIFLI enthüllt hier (genau wie der Name schon sagt), wie ein IFLI-Bild aufgebaut ist: Es besteht aus zwei kompletten Bildern mit jeweils unterschiedlicher Einfärbung. Bei der IFLI-Bildschirmdarstellung werden diese beiden Bilder in schneller Abfolge so angezeigt, dass sie sich in einem Pixel überlagern. Man sieht an dieser Pixelposition also mal die eine Einfärbung, mal die andere. Das geschieht so schnell, dass im Auge die Illusion entsteht, es handele sich um neue, ganz andere Farben. So macht man aus 16 Farben viel mehr, verdeutlicht in Bild 3. Hier ein Anwendungsbeipiel (Bilder 4 bis 6):
Und wie geht das jetzt? Nehmen wir mal ein Bild, bei dem wir zwei Farben abdunkeln wollen. Wie wär's mit dem Raspberry-Pi-Logo (rot und grün bieten sich an):
Man braucht hierfür den Lader 4Bit&Mask und zwei Masken, die miteinander verknüpft werden müssen. Die eine (Bild 8) dient dazu, die abdunkelnde Farbe in Scanline-Form ins Bild einarbeiten zu können. Im ersten Schritt erzeugt man mit Membrane eine Scanline-Maske und sichert sie in Undo Rendered oder als Bitmap (wenn man keine REU besitzt oder wenn man die Maske bei anderen Bildern weiterverwenden möchte).
Im zweiten Schritt lädt man das eigentliche Bild, Bild 7, und sichert es sofort in Undo 4Bit, wenn eine REU vorhanden ist. Dann kümmern wir uns mit QuickMask/rot/Make um die abzudunkelnde Farbe. Es entsteht eine Maske, die rot komplett durchlassen würde. Um sie mit den Scanlines aus Bild 8 zu verknüpfen, rufen wir nun 4Bit&Mask auf und laden per Mrge Mask from Undo (oder eben from Disk) die Scanline-Maske, die unmittelbar invertiert werden muss (Invert Mask). Damit haben wir Bild 9, die fertige Maske für die Farbe rot. Nun wird die Abdunklungsfarbe auf den Canvas (die Bildfläche) aufgebracht: ClipWrks/ClrClp/schwarz/Inside. Als Abschluss genügt ein Get 4Bit from Undo (oder from Disk) in 4Bit&Mask und der rote Anteil des Bildes ist abgearbeitet. An den Stellen, wo die Scanline-Maske war, sind schwarze Linien übriggeblieben und Rot weist damit schwarze Zwischenlinien auf, was insgesamt wie ein dunkles Rot aussieht (für eine alternative Vorgehensweise siehe auch das Tutorial über das Einfärben von monochromen Bildern).
Dieses vorläufige Ergebnis muss im dritten Schritt wieder gesichert werden, und dann folgt der gleiche Vorgang komplett noch einmal für den Grünanteil (grün ausmaskieren, die Maske mit der Scanline-Maske verknüpfen, den Canvas in schwarz löschen und die Maske auf das gesicherte Bild anwenden).
Hier das Endergebnis (und zwei weitere Beispiele aus der aktuellen C64-Grafik-Szene, bei denen dieser Farbeffekt zum Einsatz kommt):
Diese Technik kann man auf alle Grafikmodi anwenden, allerdings lassen sich dann die Ergebnisse u.U. optimal nur noch in IFLI (Multicolor) oder FLI (Hires) anzeigen, da ja die Anzahl der Farben pro Kachel erhöht wird. Übrigens beruht die Farbenvielfalt, mit der das Programm IPaint und die Basic-Erweiterung Basic8 für den VDC des C128 werben ("3876 eindeutige Farben"), genau auf dem hier beschriebenen Farbeffekt.
2. Künstliche Scanlines erzeugen
Man kann Bild 8 auch so verwenden, dass ein (beliebiges) Bild mit künstlichen Scanlines versehen wird. Das funktioniert noch einfacher als oben beschrieben, man braucht dazu im Prinzip nur BalancingCol und natürlich 4Bit&Mask. Nehmen wir ein Foto von meinem Auto (Bild 13, im IFLI-Modus)...
...dunkeln es mit BalancingCol (Einstellung: Brightness -3, Contrast -6) ein bisschen ab (Bild 14), laden mit 4Bit&Mask die Maske aus Bild 8 und holen das Originalbild mit Get 4Bit from Disk wieder dazu. Schon kommt dabei Bild 15 heraus, ein Bild mit künstlichen Scanlines. Wer die Scanlines gern dunkler hätte, verdoppelt die Balancingwerte für Bild 14 auf Brightness -6 und Contrast -12. Ist auch OK. Einige Farben werden von BalancingCol nicht sofort beeinflusst (rot und blau z.B.) Für die geht man dann, wenn nötig, (zusätzlich) so vor wie unter Punkt 1 ("Mischfarben erzeugen") beschrieben.
Hinweis: Wenn eins deiner Augen in seiner Sehfähigkeit beeinträchtigt ist, bleiben dir die folgenden Effekte leider verborgen.
Anaglyphen sind Bilder, die man mit einer Rot-Grün-Brille anschauen muss, um den 3D-Effekt zu sehen. In einem einzigen Bild sind bei Anaglyphen über die Rot- und die Grünfarbwerte die beiden unterschiedlichen Sehwinkel unserer Augen kodiert. Durch die Rot-Grün-Brille sieht dann das rechte Auge (durch das grüne Glas) den Rotanteil des Bildes und das linke Auge (durch das rote Glas) den Grünanteil. Im Gehirn werden beide Eindrücke zum ursprünglichen 3D-Bild verschmolzen. Statt grün wird heute meistens cyan verwendet, da dort auch der Blauanteil des Bildes vertreten ist. Hier ein Beispiel für ein Anaglyphenbild:
Wie kann man das auf dem C64 realisieren? Da es für unseren Rechner kein Tool gibt, das ein Bild in seine RGB-Farbanteile zerlegen könnte (außer für 4Bit-Bilder), muss man diese Aufgabe einem PC-Tool überlassen, z.B. XnView (dort: "Farbkanal extrahieren") oder IrfanView (dort: "Show channel"). Es müssen die Rot- und Grünanteile aus dem Vorlagebild extrahiert werden (wie in Bild 17 und Bild 18). Die Bilder bekommen jeweils ein Kennzeichen im Namen ("r." für den Rotauszug und "g." für den Grünauszug) und werden dann als GIF-Bilder auf eine C64-Diskette übertragen.
Hier beginnt GoDots Arbeit: Zuerst müssen wir die GIFs ins GoDot-4Bit-Format wandeln. Wir laden also die Bilder mit dem Lader GIF und dem Helfer-Modul DecodeGIFhir nach GoDot und speichern sie mit 4BitGoDot im damit richtigen Format gleich wieder ab.
Mit dem Lader für Anaglyphen verknüpfen wir die beiden Farbauszüge nun zu einem C64-Anaglyphenbild, entweder als Multicolor-Bild oder für den IFLI-Modus. Wenn die beiden Auszüge bereits die Namenskennung tragen, klicken wir im Filerequester einfach eine der beiden Dateien an. GoDot sorgt für die richtige Reihenfolge beim Einlesen. Hat man die Namen nicht vorbereitet, muss zunächst die Datei mit dem Rotauszug geladen werden. 4BitAnaglyph wartet danach darauf, dass man das zweite File - den Grünauszug - auch noch anklickt.
Nach getaner Arbeit kann man das Bild einfach rendern und mit einer Rot-Grün-Brille anschauen.
Obwohl die Bilder ohne Brille hier nicht besonders vielversprechend aussehen, ändert sich dieser Eindruck mit Brille sehr stark.
Anaglyphenbilder von Fotos sind noch mal ein anderes Problem. Auch hier ist uns die geringe Auflösung des C64 im Wege, vor allem, wenn es um die Darstellung von Flächen in unterschiedlichen Entfernungen geht (sie werden erzeugt durch ineinander verwobene Rot-Grün-Pixel in entsprechendem Abstand voneinander). Wenn auf einer Fläche keine roten und grünen Pixel dargestellt werden, fehlt die Tiefeninformation und das ganze Bild ist so nicht brauchbar.
In GoDot versuchen wir daher für 3D-Fotos eine andere Vorgehensweise als oben für Comics beschrieben: wir rastern die Bilder auf und hoffen, dadurch auch in Flächen Rot-Grün-Pixel zu erhalten. Dazu lesen wir die GIF-Bilder nicht mit der Einstellung Color ein, sondern gehen auf Gray 16. Es entsteht dadurch zunächst ein Bild mit 16 Graustufen (angezeigt als Falschfarben), die wir nun auf die fünf eingebauten C64-Graustufen reduzieren (wie wir das für 4BitAnaglyph brauchen) und gleichzeitig rastern (mit ApplyDither, Mode: Multi, Reduce to 5 Cols oder aber ReduceGrays/Multicolor, vorher im Hauptschirm Colors: 5 einstellen und die Palette auf Default). Erst nach diesem Zwischenschritt wird das Auszugsbild als 4Bit abgespeichert und fortgefahren wie oben beschrieben. Auf diese Weise erhalten wir brauchbare 3D-Fotos, wie z.B. dieses (links das Ergebnis, die beiden anderen Bilder zeigen die bereits gerasterten r- und g-Auszugsdateien:
Tipps: Bei Bild 19 wurde im Emulator VICE für den Screenshot zusätzlich die VICII-Farbpalette auf "RGB" eingestellt. Dadurch kommt vor allem die Farbe cyan besser zur Geltung (wie man sieht), was den 3D-Effekt erhöht. Oft ist es auch besser, wenn man beim Einlesen der Anaglyphen-Auszüge die Balancing-Werte geringfügig absenkt (Brightness: -1, Contrast: 1). Dadurch werden manche Formen klarer herausgearbeitet.
Vorlagen mit sehr vielen kleinen Details sind für 4BitAnaglyph ungeeignet.
Es geht um Einzelbild-Stereogramme (Single Image Stereograms). Wenn du kannst, richte deinen Blick in die Ferne und schaue durch diesen Punktehaufen hindurch, nur dann siehst du das 3D-Bild:
Wer es erkennen kann, sieht in der gleichen Entfernung, wie man davor sitzt, eine Fläche (alles, was in der Vorlage schwarz ist) und aus dieser Fläche erheben sich oben und unten zwei farbige Treppen nach rechts und links. Dazwischen, knapp über der Hintergrundfläche, schwebt der Schriftzug "GoDot".
Und gleich noch ein Versuch, diesmal monochrom:
Was braucht man dazu? Nur einen einzigen Modifier: SIRDS!
Jedenfalls für die monochrome Variante. Bei der Farbversion (Bild 24) muss man etwas tiefer in die GoDot-Werkzeugkiste greifen, denn Farbe ist bei den beiden Stereogramm-Modifiern von Peter Steinseifer (aus dem Jahr 1993) nicht vorgesehen. Wie geht also Farbe? So:
GoDot legt das Stereogramm als monochrome Bitmap in seinem Anzeigespeicher ab. Die 4Bit-Daten mit den Informationen über die Darstellungstiefe (die in der jeweiligen Graustufe kodiert ist) bleiben davon unberührt. Mit ihnen werden nur die 3D-Eigenschaften gesteuert, Farben gibt es hier nicht (sie sind also in diesem Zusammenhang nur Stellvertreter für Graustufen, z.B. wenn man Display betätigen würde). Um zu färben, brauchen wir daher das Ergebnis, das erzeugte Stereogramm. Da es aber monochrom ist (ohne Farbinformationen), müssen wir es zunächst in einen Modus konvertieren, der Farben zulässt. Dazu bietet GoDot den Modifier MaskTo4Bit an. Nach Anwendung wird in Hires, Colors: 16 neu gerendert. Das entstehende Bild entspricht exakt dem monochromen Stereogramm.
Noch etwas wird benötigt, und zwar bereits im Vorhinein, bevor das Stereogramm begonnen wird: Wir müssen wissen, an welchen Stellen das Bild neu eingefärbt werden soll. Soll es das ganze Bild sein? (In Bild 24 sind die weißen Pixel zu hellgrau umgefärbt.) Oder nur ein paar Ausschnitte? (Wie die beiden Farbstreifen im Bild.) Das muss nacheinander geschehen, zuerst färbt man das ganze Bild, dann die Ausschnitte. Fürs Umfärben verwenden wir Histogram/Swap, bei den Ausschnitten kommt ClipWorks/Clip dazu.
Also: Histogram aufrufen, vorhandene Farbe mit gewünschter neuer tauschen (Swap), rendern. Bei den einzufärbenden Ausschnitten nun vor dem Rendern in ClipWorks den neuen Clip festlegen. Da wir dabei nur die Pixel des Sterogramms sehen, müssen wir uns ganz am Anfang der Kampagne die Ausschnittsdaten der Stellen, die gefärbt werden sollen, aufschreiben. Diese Daten am besten hinter Row, Col, Wid und Hgt von Hand eingeben (Wid und Hgt zuerst). In Bild 24 waren das Row: 3, Col: 2, Wid: 36, Hgt: 3 für den oberen (roten) Ausschnitt und dann Row: 19 für den unteren (blauen). Da das jetzige Bild in der Anzeige nicht den Zustand des 4Bit-Speichers wiedergibt, darf man sich das Stereogramm jetzt nur noch mit Redisp anschauen.
Will man ein so eingefärbtes Stereogramm abspeichern, überträgt man es zunächst mit RendrdTo4Bit in den 4Bit-Bereich, danach kann man es in einem beliebigen Format auf Diskette sichern. RendrdTo4Bit berücksichtigt beim Konvertieren der Anzeige (anders als das monochrome MaskTo4Bit) die sichtbaren Farben.
Tipps: · Zwischen hellen und dunklen Pixeln im Stereogramm muss ausreichend Kontrast bestehen, sonst verliert sich der 3D-Effekt beim Ansehen. · Sehr helle Einfärbungen in einem ansonsten dunklen Stereogramm stören den 3D-Eindruck, man kann seine Augen schlechter synchronisieren. · Das Gleiche gilt für die Einfärbungen an sich: Zu viele kleine Farbstellen verhinden den 3D-Blick. · Die Einfärbungen sollten Stellen markieren, die bereits in der Graustufenvorlage "hervorgehoben" sind (wie z.B. die Treppen in Bild 24).
Diese Animationstechnik stammt aus den Anfangszeiten der Gamecomputer (Amiga und PCs der 1980er Jahre). Sie ermöglicht Bewegung auf dem Bildschirm (meist Bewegung, die mit Wasser oder Feuer zu tun hat: Wellen oder Flammen, siehe hier), ohne dafür viel Speicherplatz zu verschlingen. Das liegt daran, dass die Belegung einer Farbpalette dort - anders als beim C64 - beliebig umdefiniert werden kann. Ein Farbpixel, der eben noch schwarz angezeigt hat, kann im nächsten Augenblick weiß erscheinen. Wenn man also die Bilder geschickt einfärbt, lassen sich die entsprechenden Bereiche durch zyklisches Vertauschen der Farben in der Palette "in Bewegung" versetzen. An den Bitmaps der Bilder wird keine Veränderung vorgenommen, es sind für das Color Cycling (Farbrotation) keine umfangreichen und zeitraubenden Kopieraktionen erforderlich.
Das einzige bekannte C64-Programm, mit dem Color Cycling erzeugt werden kann, ist Amica Paint. Allerdings muss es dabei die festverdrahtete Farbpalette des C64 berücksichtigen, d.h. statt blitzschneller Umdefinition in einer Palette müssen für jede Phase einer Animation alle Stellen im Speicher, die die Farben eines Bildes festlegen (Farb-RAM, Color-RAM, Register), neu geschrieben werden. In GoDot gibt es für die Erzeugung einer Farb-Animation kein Werkzeug.
Hier einige Beispiele der original Amica-Paint-Diskette. Hier Beispiele auf dem Amiga.
Im Beispiel hier bewegen sich die Bäume und das Haus sehr schnell von links nach rechts. Dies alles sind umdefinierte Buchstabenzeichen.
Beispiele auf Twitter: eins, noch eins, ein drittes.
Weitere Informationen siehe hier und hier.
(Wird von GoDot unterstützt, es fehlen aber noch geeignete Werkzeuge.)
Es gibt zwei Möglichkeiten, mit Sprites Bewegungen vorzutäuschen: Einerseits kann man ein einziges Sprite unablässig mit den Pixeln neuer Bewegungsphasen beladen und andererseits kann man die Bewegungsphasen von vornherein auf mehrere Spriteblöcke aufteilen, die alle zugleich beladen werden. Die Bewegung kommt dann durch Umschalten der Spriteblock-Register (normal 2040 bis 2047) zustande. Diese zweite Methode ist im Ablauf schneller, da jeweils nur ein einziger Wert geändert werden muss.
Siehe hier.
(Wird von GoDot unterstützt, es fehlen aber noch Werkzeuge.)
Bei dieser Animationsart werden bei jedem Animationsframe die komplette Bitmap, das Video-RAM, das Color-RAM und die Farbregister für die Hintergrundfarben neu geschrieben. Das geht mit der erforderlichen Geschwindigkeit (ruckelfrei) nur unter Zuhilfenahme einer REU mit seiner Transferrate von 1 MB/s. Auch Double Buffering ist nützlich. Besonders beeindruckend sind die NuVIE-Filme, die Crossbow/Crest ermöglicht hat.
Dazu vorläufig beim Thema "Verläufe" weiterlesen.
