mod.BossConvert

Bild 1: BossConvert GUI
BossConvert ist ein Modul speziell für Spiele-Entwickler. Es dient dazu, aus gemalten Bildern von Endgegnern Sprite-Sets für Action-Spiele zu erzeugen. Ein solcher Endgegner kann bis zu 192x192 Pixel groß sein, d.h. im Ergebnis aus bis zu 80 Einzelsprites bestehen.

BossConvert nimmt an, dass hardwarebedingt höchstens acht Sprites in einer Rasterzeile angezeigt werden können, das sind also 8x24 Pixel Breite (192 Pixel insgesamt). Untereinander passen neun komplette Sprites auf eine Bildschirmhöhe (9x21 Pixel gleich 189 Pixel) bzw. zehn, wenn man aus Darstellungsgründen die Sprites ein wenig (um zwei Pixel) gegenseitig überlagert (dadurch wird ein Flimmern an den "Nahtstellen" der Sprites vermieden). Die daraus resultierende Höhe beläuft sich auf 10x19+2 Pixel (192 Pixel, das unterste Sprite hat effektiv seine volle Höhe von 21 Pixeln, daher "plus 2"). In Bild 3 kann man am rechten Rand die entsprechenden Markierungen sehen: Die kurzen weißen Striche deuten die normale Spriteverteilung ohne Überlagerung an, die längeren stehen für überlappende Sprites.

BossConvert geht von zwei klaren Voraussetzungen aus:

· Als erstes muss das Vorlagebild in einem C64-Multicolor-Fileformat vorliegen, das von GoDot unterstützt wird. Falls das Bild auf einem PC gemalt wurde, muss es dort mit der GoDot-Palette erstellt worden sein, da es sonst beim Einlesen in GoDot zu Farbveränderungen kommen würde. Auch solche Bilder vom PC müssen für GoDot zunächst in ein C64-Multicolor-Format umgewandelt werden (damit BossConvert die richtige Hintergrundfarbe erkennt und sie für die Konvertierung ausklammert).
Bild 2: Zu viele Farben für ein Sprite
· Zum Zweiten muss sich der Entwickler beim Malen genau der Restriktionen bei der Darstellung von Sprites auf dem C64 bewusst sein und seine Endgegner entsprechend gestalten. Abgesehen von der Hintergrundfarbe (die nur kosmetische Bedeutung hat, da sie bei Sprites transparent ist; zugehöriges Bitmuster %00), sollte der Endgegner aus nur zwei (Basis-) Farben bestehen. Dies sind die beiden für alle acht gleichzeitig vom Videochip des C64 darstellbaren Sprites gleichen Farben der VIC-Register $d025 (Bitmuster %01) und $d026 (Bitmuster %11). Zusätzlich darf pro Fläche eines Sprites nur noch eine weitere Farbe verwendet werden (siehe Bild 3, hier sind die beiden Basisfarben dunkel- und mittelgrau, sie werden spritekachelweise ergänzt durch hellgrau, weiß, hellrot, rot oder hellblau; entworfen von Stefan Gutsch). Diese Farbe wird im C64 über die Register ab $d027 dem Bitmuster %10 zugeordnet. Sollen die Sprites des Endgegners sich überlappen, muss auch diese Option beim Malen berücksichtigt werden. Bild 2 zeigt, dass die gleiche Vorlage wie in Bild 1 ohne Überlappung Farbfehler in BossConvert hervorrufen würde ("Alert" und "7 ccl").

Bedienung
Bild 3: Einen Boss definieren
Der erste Vorgang ist das Laden der Endgegnervorlage mit dem Lader für das entsprechende Fileformat (z.B. Koala). Vor der Bearbeitung mit BossConvert muss das Bild gerendert werden (Display im Hauptbildschirm).

Nun startet man BossConvert und erhält ein Fenster ähnlich wie in Bild 1 (die Zahlenangaben rechts zu Höhe, Breite und Gesamtzahl der Sprites stehen dann noch auf Null). Wer sich einen ersten Überblick verschaffen will, klickt im Sprite-Fenster auf das angezeigte erste Sprite. Die gesamte Grafik erscheint, der Mauszeiger erhält rechts einen Winkel, der die rechte untere Ecke eines Sprites markiert. Dieser Winkel bewegt sich in Spritegröße-Schritten weiter, wenn man die Maus bewegt (Bild 3). Mit der STOP-Taste kehrt man zurück ins BossConvert-Fenster.

Mit Define legt man im nächsten Schritt fest, wie groß der Endgegner sein soll. Dazu klickt man die rechte untere Ecke des Endgegners an, so dass alle Teile des Objekts innerhalb eines gedachten Rahmens um das Objekt liegen. Je nachdem, ob Overlap dabei auf Yes oder No steht, berechnet BossConvert nun die entsprechende Breite und Höhe des Endgegners in Sprites (Width und Height) und die darin enthaltene Anzahl an Sprites (Total).

Jeder Klick auf die Anzeige hinter Overlap stellt den Modus um auf überlappende bzw. nicht überlappende Sprites. Gleichzeitig wird der Define-Modus aktiviert, man braucht nicht extra auf den Define-Knopf zu klicken. Will man jedoch die bestehende Definition eines Endgegners ändern, ohne den Überlappungsmodus mitzubeeinflussen, klickt man auf Define.

Der dritte Schritt sollte darin bestehen, zu überprüfen, ob alle Sprites des geladenen Endgegners korrekt gemalt wurden. Dazu dient der Check-Knopf. Wird er betätigt, arbeitet BossConvert alle Sprites im eingestellten Overlap-Modus durch und zählt die im jeweiligen Bereich vorkommenden Farben. Sind dort zu viele enthalten, meldet Check einen Alert. Nach Ende des Vorgangs wird auch die Gesamtanzahl der Alerts ausgegeben (s. Bild 2, dort zählte BossConvert "7 ccl", wobei ccl für "color clash" steht). Werden keine Farbfehler entdeckt, ist alles in Ordnung und der Endgegner könnte so abgespeichert werden. Während dieses Vorgangs erkennt BossConvert auch die beiden schon angesprochenen festen Basis-Spritefarben und hält sie fürs Speichern bereit.

Sollten jedoch Fehler angezeigt werden, kann man mit den Pfeil-Knöpfen neben der Sprite-Anzeige den Endgegner nach der fehlerhaften Stelle absuchen. Normalerweise bewegt man sich dabei waagerecht durch die Sprites des Sprite-Sets. Möchte man senkrecht hin und her wandern, klickt man auf den Richtungsknopf "Dir⇒". Stößt man nun auf ein Sprite, das einen Farbfehler enthält, erscheint ein weiteres Mal die Alert-Meldung. Ein Klick auf das dazu angezeigte (und wahrscheinlich unschön aussehende) Sprite schaltet um auf die Grafik und setzt den Anzeige-Winkel auf die zugehörige Stelle im Endgegner. Man soll dadurch in die Lage versetzt werden, die problematische Stelle im Editor (mod.PixelEdit) leichter wiederzufinden. Die zum Farbfehler führende Ursache muss man allerdings selbst herausfinden, meist sind nur ein oder zwei Pixel irrtümlich in einer vierten Farbe verblieben, was mit PixelEdit leicht behebbar ist.
Bild 4: Einen Boss abspeichern
Kommt kein Farbfehler mehr vor, kann man mit Save zum Speichern des Endgegners schreiten. Ein neues Fenster überlagert den unteren Teil der bisherigen BossConvert-Oberfläche. Ganz links werden hier die beiden gefundenen Basis-Farben angezeigt, wobei die obere dem Bitmuster %01 zugeordnet ist ($d025) und die untere dem Bitmuster %11 ($d026), siehe Bild 4. Wer die Zuordnung umdrehen möchte, klickt auf das Gadget mit den beiden Pfeilen ("⇓⇑"). Anm.: Es ändert sich tatsächlich nur die Zuordnung der Bitmuster zu den Farben, nicht die Verteilung der Farben im Bild. Sinnvollerweise gibt man seinem Endgegner noch einen aussagekräftigen Namen (maximal 12 Zeichen) und überschreibt dabei den Vorgabenamen ("Boss01"). Schließlich kann man mit Save den Endgegner endgültig abspeichern. Der Name erhält dabei automatisch das Präfix "SPS." (Sprite-Set). Wer nur mal schauen wollte, welche Farben BossConvert ermittelt hat, verlässt ohne weitere Maßnahmen mit Leave das Save-Fenster. Übrigens erfolgt bei seinem Aufruf ein automatischer Farben-Check. Wird dieser nicht erfolgreich abgeschlossen, erscheint das Save-Fenster nicht.
Bild 5: Hier ein Beispiel für andere Spritefarben
In Bild 5 sieht man, dass nicht nur Abstufungen von Grau für die Endgegner sinnvoll sein müssen (hier: grün).

Aussichten

Bild 6: Ein animierter Endgegner Das SPS-Fileformat eröffnet bereits die nächste Stufe der Endgegner-Erstellung: das Animieren des Endgegners. Aus einer Serie von Endgegner-Vorlagen entsteht dabei eine Serie von Sprite-Sets, wobei zusammengehörige Animationsframes alle in einem einzigen File abgespeichert werden sollen. Für GoDot werden im Laufe der nächsten Monate die entsprechenden Tools programmiert: Frame-Builder, Animator, Optimizer.

SPS-Fileformat

  File-    Inhalt       Beschreibung
  Offset
  ----------------------------------
  0000     $47 $4f $44  Kennung: "god"
  0003     $37          Filetyp: "7" (Spriteset, Filenamenspräfix: "sps.")
  0004     $00          Breite in Anzahl Sprites (max. 8)
  0005     $00          Höhe in Anzahl Sprites (je nach Überlappung max. 9 oder 10)
  0006     $01          Grafikmodus, 0 = Hires, 1 = Multicolor
  0007     $00          2 Pixel Überlappung, 0 = aus, 1 = ein
  0008     $00          Hintergrundfarbe, Bitmuster %00
  0009     $00          Sprite-Multicolor 0 ($d025), Bitmuster %01
  0010     $00          Sprite-Multicolor 1 ($d026), Bitmuster %11
  0011     $00          Ausrichtung, 0 = nebeneinander, 1 = untereinander
  0012     $00          Kompression, 0 = aus, 1 = ein
  0013     $00          Anzahl Animations-Frames, 0 = keine Animation
                        1 = Animation in Spritegröße, ein Sprite = ein Frame
                        2 und größer: es folgt eine Optimierungstabelle, die
                        in je zwei Bytes (Frame#/ Sprite#) festhält, welches
                        Sprite an dieser Stelle eingesetzt werden soll, die
                        Tabelle enthält für jeden Frame bis zu zweimal 80 Bytes
                        Spriteverweise.
  0014     ...          erster Frame... (enthält Breite x Höhe Sprites à 64 Bytes)
                        Im 64. Byte jedes Sprites befindet sich die noch fehlende
                        dritte Farbe des Sprites ($d027 und folgende, Bitmuster %10)
  nnnn     $ad          File-Ende

Voreingestellte Werte sind fett gedruckt. Zum gegenwärtigen Zeitpunkt (August 2008) wird nur der Multicolormodus (Flag an Offset 6) unterstützt. Die Ausrichtung der Sprites im Spriteset ist Sache des einlesenden Programms, das Flag an Offset 11 sagt nur, wie es sein soll. Die Kompression ist die von GoDot verwendete: auf das Indikatorbyte $ad folgt ein Zähler für die Anzahl der Wiederholungen des dritten Bytes. Ein Zähler von $00 steht dabei für 256 Wiederholungen: $ad $00 $ff = 256 mal $ff.

Korrespondierende Module:

ldr.SPSto4Bit (zum Rückwandeln eines Spritesets in Grafik)

zurück

Arndt Dettke
support@godot64.de