Was ist das? Wie geht das?
Dateiformat · Grafikmodus · Ergebnisoptimierung
Definieren wir doch mal:
Konvertieren ist der Übergang eines Objekts (oder auch eines Subjekts) von einem (regelbasierten) Bezugssystem in ein anderes. Der Zweck des Konvertierens ist, dass man das Objekt (oder Subjekt) in einen besseren (oder besser geeigneten) Zustand versetzen möchte. Für eine erfolgreiche Konvertierung ist es erforderlich, sowohl den Ausgangszustand als auch den Zielzustand genau zu kennen, denn sonst misslingt dieser Vorgang.
Was wir hier so allgemeingültig formuliert haben, gilt natürlich im Besonderen für die Grafik des C64. Sie ist (für heutige Verhältnisse) ganz unangenehmen Beschränkungen unterworfen: geringe Punktauflösung (320×200 Pixel), geringe Farbauflösung (16 fest verdrahtete Farben und erhebliche Beschränkungen bei der Anzeige der Farben). Auch die technische Organisation der Farbzuordnung ist uneinheitlich und daher umständlich zu handhaben: einerseits ist sie registerorientiert (Hintergrundfarbe, Rahmenfarbe), andererseits werden die Farben in bestimmten (voneinander getrennten) Speicherabschnitten festgehalten, jedenfalls nicht dort, wo sich die Bildpunkte befinden.
Wenn etwas aus so vielen Einzelteilen besteht, dann kann man sich leicht vorstellen, dass es zig verschiedene Wege geben muss, diese Teile zusammenzusetzen. Genau das ist auf dem C64-Sektor passiert. Jedes Grafikprogramm setzt seine Bilder aus anders gewichteten Bestandteilen zusammen und speichert diese auch auf je eigene Weise auf Datenträgern ab. Dabei entstehen zwei entscheidende Probleme:
· Bilder, die von Programmen stammen, die sich auf einen bestimmten Grafikmodus spezialisiert haben, können Bilder von Programmen mit einer anderen Ausrichtung nicht adäquat darstellen.
· Bilder, die von dem einen Programm gespeichert wurden, kann das andere Programm nicht fehlerfrei einlesen.
Beide Probleme können gelöst werden, wenn man die Bilddaten des einen Programms für die Bearbeitung in einem anderen Programm vorbereitet, die Daten also konvertiert. Und hier kommt GoDot ins Spiel: Zum einen verwaltet GoDot seine Bilddaten so, dass alle erforderlichen Informationen zum Aussehen eines Bildpunktes in diesem selbst festgehalten werden (4Bit-Format). Zum anderen versteht GoDot rund 90 verschiedene Grafikspeicherformate und kann diese auf etwa 50 verschiedene Weisen wieder auf Datenträger zurückschreiben.
Eigentlich ist das Konvertieren von einem Dateiformat in ein anderes ein simpler Vorgang: Man installiert den Lader für das Quellformat, den Saver für das Zielformat, lädt das Bild und speichert es wieder ab, fertig. Im Prínzip ist es genau so einfach, aber man sollte doch einige Dinge darüber, wie GoDot dabei vorgeht, wissen, damit man nicht doch plötzlich mit unvorhergesehenen Ergebnissen konfrontiert wird:
GoDot wurde als Konvertierungswerkzeug in einigen bekannten Softwareprojekten genutzt.
Da nun GoDot die Eigenschaft besitzt, das Aussehen eines Pixels in ihm selbst festzuhalten, ermöglicht dies Konversionen wie hier im Beispiel: Aus einem farbigen Hiresbild kann man mit GoDot auf Klick ein sehr gut an den Multicolormodus angepasstes neues Bild zaubern (mit ForceMulti, Bild 6, oder auch mit Antialiasing, Beispielbilder s. dort). Das gleiche Ausgangsbild kann GoDot aber ebenso in ein auch in diesem besonderen Modus immer noch beeindruckendes IFLI-Bild konvertieren (Bild 7, enthält 72 Farben). Oder auch in ein genauso beeindruckendes monochromes Bild, wie es z.B. für einen Schwarzweiß-Drucker gebraucht würde (Bild 8). Das erste der folgenden vier Bilder (als Vorlage für die anderen) ist ein erstaunliches Beispiel für großes gestalterisches Können im farbigen Hiresmodus:
Natürlich beherrscht GoDot auch die umgekehrte Richtung beim Konvertieren von Farben: aus vielen mach wenige. Bild 9 ist ursprünglich ein JPG-Bild mit 16,7 Millionen Farben, nun reduziert auf ganze 16. In Bild 10 wies die Vorlage 256 VGA-Farben auf, in Bild 11 waren es 32 Amiga-Farben. Schließlich in Bild 12 sehen wir 256 PC-Graustufen.
Dabei ist GoDot in der Lage, die unterschiedlichen, in der C64-Szene gebräuchlichen Farbsysteme (Pepto, Colodore, Community Colors usw.) sowohl beim Einlesen der Daten als auch beim Wiederwegschreiben zu berücksichtigen. Bild 5 und 6 oben sind z.B. in der Pepto-Palette gehalten (Bild 6 zeigt die Pepto-Farben aus GoDot).
Ein Anzeigemodus, der immer wieder vergessen bzw. oft sogar missachtet wird, ist der reine Text- oder PETSCII-Modus. Commodore hat bei der Definition der Textzeichen von vornherein grafische Möglichkeiten mitgedacht und den Zeichensatz mit sehr vielen Zeichen ausgestattet, mit deren Hilfe man Rahmen, Hintergünde, Diagramme usw. erstellen kann. Obwohl also die Auflösung in diesem Modus nur magere 40×25 Kacheln beträgt, sind die Gestaltungsmöglichkeiten sehr viel weitreichender. Entsprechend kreative Grafiker können mit den Grafikzeichen des Textmodus schon erstaunliche Bilder erstellen, wie die folgenden Beispiele zeigen:
Wenn diese PETSCII-Art-Bilder in Form von PRINT-Anweisungen im Rahmen eines BASIC-Programms vorliegen, kann GoDot sie nach Hires konvertieren (mittels PrintTo4Bit). Mit dem C64Studio von Endurion kann man z.B. solche BASIC-Dateien für GoDot herstellen. Außerdem sollte man sich mal intensiv mit dem PC-Tool "PETSCII" von Marq beschäftigen, das die Konvertierung beliebiger Vorlagen unterstützt.
Hier ein Konversionsergebnis (Textmodus nach Hires) mit PrintTo4Bit unter GoDot (Bild aus dem 64'er Magazin, Ausgabe 04/86):
Wenn Bilder mit vielen Farben auf C64-Verhältnisse konvertiert werden sollen, steht man oft vor der frustrierenden 16-Farben-Einschränkung (die begleitet ist von weiteren Einschränkungen, was die Darstellbarkeit dieser 16 Farben angeht). Zum Glück ließ das die wahren C64-Koryphäen nicht ruhen und sie fanden (z.B. mit dem IFLI-Modus) einen Weg, die Frustrationsgrenze hier stark anzuheben. Die folgenden Bilder sind solche beeindruckenden IFLIs (für die Darstellung im Internet haben wir hier die scheinbaren Farben des IFLI-Modus in echte Farben umgerechnet):
Nehmen wir "Afghan Girl" (ein berühmtes Foto von Steve McCurry) als Beispiel, wie man solche Bilder auf den C64 "portiert".
Die erste unabdingbare Maßnahme ist das Skalieren des Bildes auf C64-Verhältnisse, also eine Verkleinerung auf eine Größe in der Nähe von 320×200 Pixeln. Die nächste wichtige Maßnahme ist eine Vorreduzierung der Farben auf die C64-Farben, und zwar nicht auf 16 Farben, sondern auf die 136 IFLI-Farben, die vom Lader GIF/DecodeGIF64c verwendet werden. Seit v1.04 von DecodeGIF64c ist das die PALettev1 (von Forum64-User @tobias). Die Reduzierung möglichst mit einer Option zum Dithern während der Farbreduktion durchführen. Damit sieht das Bild dann immer noch beinahe wie das Original aus, ist jetzt aber bestens für die endgültige Konversion gerüstet (s. Bild 25). Abgespeichert wird das Bild im GIF-Format (256 Farben).
Jetzt kommt GoDot ins Spiel. Zuerst (ganz wichtig!) stellen wir mit SetColorBase die PALettev1 ein (nennt sich dort PAL@v1). Dann laden wir das Bild mit ldr.GIF und dem Helper-Modul DecodeGIF64c (64c steht für "64 colors"). Dieser Vorgang erzeugt eine 4Bit-Datei, in der zwei FLI-Bilder pixelweise abwechselnd im Speicher vorliegen, wie es für ein IFLI-Bild gebraucht wird. Da wir im Zielbild möglichst wenig IFLI-Flackern wollen, mischen wir im nächsten Schritt mit OddSwap die beiden Halbbilder schachbrettartig ineinander (Bild 26). Dieses Bild (bitte als 4Bit abspeichern!) hat Hires-Auflösung, lässt sich aber auf einem C64 nicht im Hires-Modus anzeigen, da dessen Farbrestriktionen dies verhindern würden. In diesem Zustand ist das Bild zwar schon für eine Anzeige in IFLI auf dem Bildschirm geeignet, es kann aber noch verbessert werden.
Den letzten Schliff erhält das Bild nämlich mit einer weiteren Maßnahme: Es wird noch einmal geladen, diesmal aber mit aufgehellten Farben und erhöhtem Kontrast. Dazu brauchen wir die Balancing-Einstellungen. Brightness erhält dort den Wert 2 und Contrast den Wert 5. Diese Werte akzeptieren wir und starten erneut den Ladevorgang wie eben, einschließlich OddSwap.
Und jetzt der entscheidende Schritt, beide Bilder werden miteinander verknüpft. Wir starten Membrane und stellen dort die nötigen Voraussetzungen her: Opacity wird auf 25% geändert (der helle Bildanteil kann so nur einen Beitrag von 25 Prozent ins Ergebnis einbringen) und der Modus wird von Hires auf Multi umgestellt (wir erfassen somit beim gleich nachfolgenden Verknüpfungsvorgang Doppelpixel, behalten also die IFLI-Farbkombinationen, die beim Laden erzeugt wurden, bei). Diese Einstellung wird mit Apply angewendet, und mit Leave verlassen wir Membrane.
Wir wechseln den Lader zu 4Bit&Mask und laden die vorhin abgespeicherte (dunklere) Version des Bildes mit Get 4Bit (from Disk) nach. Das dunklere Bild überschreibt nun auf 75 Prozent der Fläche das im Speicher befindliche hellere Bild und wir erhalten ein insgesamt ausgewogenes Ergebnisbild. Da es sich links am Rand des Bildschirms befindet, schieben wir es mit ClearFLIBug noch an die für IFLI richtige Position. Damit haben wir Bild 28.
Hier die ganze Entwicklungskette:
Die anderen Bilder (Bild 17 bis 21) sind auf ähnliche Weise entstanden. Mit den Balancing-Werten muss man vielleicht ein wenig experimentieren, aber die Ergebnisse lohnen den Aufwand.
