Hier kann man die True-Hires-Auflösung deutlich sehen.
upmem v1.22 12.01.26
Pixel:
Ein Bit einer Bitmap (Bildpunkt oder Pixel; der C64 hat 64000 Bildpunkte, abgelegt in 8000 Bytes) kann faktisch nur zwei Farben widerspiegeln (Vordergrund - Hintergrund; die zugehörigen auf dem Bildschirm erscheinenden Farben werden beim C64 nicht direkt in diesem Bildpunkt, sondern in einem extra Farbspeicher abgelegt (1000 Bytes), siehe: Hires-Modus). Der Video-Chip des C64 (VIC II) kann bei dann nur noch halber horizontaler Auflösung auch vier mögliche Farben pro Bildpunkt darstellen, indem dabei je zwei Bits der Bitmap zu einem doppelt so breiten Pixel zusammengefasst werden (mit zwei Bits lassen sich vier Zustände kodieren, der Speicherbedarf für die Farben verdoppelt sich allerdings auf zwei Farbspeicher (mit weiteren 1000 Bytes), das schon angesprochene und das Farb-RAM, und ein Register für die vierte Farbe, siehe: Multicolor-Modus).
Kacheln:
Der Farbspeicher des C64 ist so organisiert, dass je 64 Pixel (bzw. 32 Doppelpixel) in Form eines Quadrats (eine Kachel, 8×8 Bytes) eine Einheit mit höchstens 2 bzw. eben 4 Farben bilden. Die daran anschließende nächste Kachel darf andere Farben enthalten. Farben werden vom C64 also eher behandelt wie bei den Zeichen des Textbildschirms, dessen Farbfähigkeiten im Textmodus sind für die Realisierung der Grafikdarstellung einfach wiederverwendet worden.
Das führt zu erhöhtem Speicherbedarf, erforderlich sind nämlich 32000 Bytes für GoDots Bitmap (gegenüber 9000 Bytes farbigem Hires bzw. 10000 Bytes Multicolor). Im Speicher des C64 befinden sich daher die Farbdaten des Bildes im Bereich von $4000 bis $BCFF und zwar in der gleichen Kachelanordnung wie in einer normalen C64-Bitmap. Das bedeutet, dass je 8 Bildpunkte nebeneinander erscheinen und die nächsten 8 eine Zeile tiefer, für eine Kachel insgesamt 8×8 Bildpunkte je vier Bit. Darauf folgt die nächste Kachel usw. Jede Kachel nimmt damit in GoDot 32 Bytes Platz ein. 32×40×25 ergibt 32000 Bytes Platzbedarf.
Rendern:
Der C64 kann wegen seiner Farbbeschränkungen bei der Grafikanzeige die bis zu 16 Farben pro Kachel in GoDot gar nicht anzeigen. Sollten in einer Kachel zu viele Farben vorkommen, wählt der Videochip bei normaler Grafikdarstellung lediglich die zuletzt erkannten zwei (im Hires-Modus) bzw. vier (im Multicolor-Modus) davon zur Darstellung aus. Das führt zu deutlich sichtbaren Darstellungsfehlern, meist in Form von spitzen Ecken ("Color Clashes").
GoDot mit seinem erhöhten Anspruch an das Datenmaterial analysiert daher jede einzelne Farbkachel vor der Anzeige, um durch optimale Auswahl der häufigsten Farben in einer Kachel solche Bildfehler zu vermeiden. Dieser Vorgang der Optimierung von Bildpunkten und der erst nachfolgenden Bilddarstellung heißt Rendern (s. dazu Display).
Wenn GoDot auf Geräten läuft, die mit höherer Taktgeschwindigkeit arbeiten können (SuperCPU, Ultimate Elite, C64 Ultimate, Turbo Chameleon, C128, Mega65), dann schaltet es während des Renderns automatisch den Turbomodus ein und beschleunigt so den Vorgang - je nach Taktgeschwindigkeit - erheblich. Achtung: Dabei verliert auf einem C128 der VICII die Kontrolle über das Bild und zeigt während des Aufbaus der Grafik schnell wechselnde zufällig entstehende Bildpunkte und Farben. Nach dem Rendern kehrt der VIC zu seinem normalen Verhalten zurück und das fertig berechnete Bild erscheint.
Achtung (wichtig für Pixelkünstler!): Die RGB-Werte der GoDot-Palette (die innerhalb der Saver für GIF, PCX, IFF, BMP, EPS und PNG für Konversionen verwendet werden) sind dort nicht nach Helligkeitsgesichtspunkten angeordnet, Farbgradienten gelten daher nur für Bilder, die auch mit der GoDot-Palette entstanden sind, und sehen dann auf PCs u.U. vollkommen anders aus als beabsichtigt! Eine Anpassung an andere RGB-Paletten - z.B. Pepto - muss daher gesondert vorgenommen und bereits vorab berücksichtigt werden). Siehe auch: GoDot-IFLI-Palette.
Der große Vorteil von GoDots 4Bit-Format ist aber die Informationstiefe von 16 möglichen Zuständen pro Bildpunkt. Jedes einzelne Pixel GoDots wird dadurch gezielt manipulierbar. Die Fülle der Bildbearbeitungsmodule GoDots ist erst aus diesem Grund überhaupt denkbar.
Diskettenformat und Kennung:
Auf Diskette besitzt GoDot ein eigenes, gepacktes Format mit einer einleitenden
Kennung. Lader können anhand der Kennung unterschiedliche Funktionen ausführen. Jedes GoDotbild
beginnt mit den Zeichen "GOD0" ($47, $4F, $44, $30), eine Startadresse gibt es nicht. Darauf folgt fortlaufend der Inhalt des 4Bit-Speichers. Serien von gleichen Bytes (mehr als drei) werden gepackt, indem sie durch einen Zähler ersetzt werden. Damit das einlesende Programm erkennt, wann ein Zähler kommt und welches Byte gezählt wird, ersetzt der Saver 4BitGoDot diese Serie gleicher Bytes durch ein Flagbyte ($AD), einen Zähler und das zu wiederholende Byte, wobei eine Angabe von Null beim Zähler 256 gezählten Bytes entspricht. Eine Folge von 100 Mal Wert 88 würde demnach durch den Code $AD $64 $58 repräsentiert. Das allerletzte Byte in jedem Bildfile ist $AD. Es wird jedoch nicht verwertet und ist mehr eine "Unterschrift" von GoDot.
Eine Signatur von "GOD1" leitet einen GoDot-Clip ein. Auf die Signatur folgen dort vier Bytes, die die Zeile und Spalte der Herkunft des Clips und seine Breite und Höhe angeben (in Anzahl von Kacheln, maximal also 255 Kacheln für Breite und Höhe, das sind je 2040 Pixel). Der Rest baut sich auf wie GoDots Standardformat.
Ein Überblick über alle GoDot-Formate findet sich hier.
zurück --- zum Hauptmenü
Arndt Dettke