mod.BossConvert

v1.13 18.06.20


Bild 1: BossConvert GUI
Bild 1: Das Modul "BossConvert"

BossConvert ist speziell für Spiele-Entwickler gedacht. Es dient dazu, aus mit Malprogrammen hergestellten Bildern von Sprite-Endgegnern und sonstigen Spielfiguren fertige Spritesets zu erzeugen. Solche Spiele-Spritesets, speziell die Endgegner, können in GoDot bis zu 192×192 Pixel groß sein, d.h. letztendlich aus bis zu 80 Einzelsprites bestehen.

BossConvert geht davon aus, dass höchstens acht Sprites nebeneinander in einer Rasterzeile angezeigt werden, das entspricht einer maximalen Breite von 8×24 Pixeln (192 Pixel). Untereinander passen neun komplette Sprites auf eine Bildschirmhöhe (9×21 Pixel gleich 189 Pixel). Wenn man aus Darstellungsgründen die Sprites ein wenig (um zwei Pixel) gegenseitig überlagert (wodurch ein Flimmern an den "Nahtstellen" der Sprites vermieden wird), die Sprites effektiv also nur 19 Pixel hoch sind, passen 10 Sprites untereinander auf den Bildschirm. Die daraus resultierende Höhe beläuft sich auf 10×19+2 Pixel (192 Pixel, das unterste Sprite hat natürlich seine volle Höhe von 21 Pixeln, es wird ja nicht überlagert, 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.

Bild 2: Zu viele Farben für ein Sprite
Bild 2: Alert! Zu viele Farben im Sprite!

BossConvert geht von drei klaren Voraussetzungen aus:
· Als erstes muss das Vorlagebild in einem von GoDot unterstützten C64-Multicolor-Fileformat vorliegen. 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 (s. aber auch SetColorBase). Bilder vom PC wandelt man für GoDot zunächst in ein C64-Multicolor-Format um (damit BossConvert die richtige Hintergrundfarbe selbst erkennt und sie für die Konvertierung ausklammert; ansonsten verwendet man dafür SetBGColor).
· 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 farblich gestalten.
· Drittens: Abgesehen von der transparenten Hintergrundfarbe sollte ein Endgegner in der Hauptsache aus zwei Farben bestehen: den beiden für alle acht darstellbaren Sprites gleichen Farben der VIC-Register $d025 (Bitmuster %01) und $d026 (Bitmuster %11, zu den technischen Details s. Videochip des C64). Pro Einzel-Sprite darf nun noch eine vierte Farbe verwendet werden, siehe Bild 3.

In diesem Bild lauten die beiden Basisfarben dunkel- und mittelgrau, sie werden von Sprite zu Sprite ergänzt durch hellgrau, weiß, hellrot, rot oder hellblau (Sprites entworfen von Stefan Gutsch für das Spiel Metal Dust, Verwendung hier mit freundlicher Genehmigung). Diese vierte Farbe wird im C64 über das Register $d027 (und den folgenden, je Sprite eins) dem Bitmuster %10 zugeordnet. Sollen die Sprites des Endgegners sich überlappen, muss auch diese Option beim Malen berücksichtigt werden. Zur Veranschaulichung zeigt Bild 2, 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
Bild 3: Einen Boss definieren

Der erste Vorgang beim Erstellen von Spiele-Sprites in BossConvert ist das Laden der Endgegnervorlage (mit dem Lader für das entsprechende Fileformat, z.B. Koala) oder das Wiederbearbeiten eines bereits als Spriteset abgespeicherten Endgegners (mit SPSto4Bit oder SpritePad). Die Vorlage sollte nach dem Laden bündig links oben in der Grafik liegen. Vor dem Start von BossConvert muss das Bild gerendert werden (Display im Hauptbildschirm). Immer bedenken, dass BossConvert kein Sprite-Editor ist, sondern ausschließlich dazu dient, eine Grafik in einen Spriteset zu konvertieren.

Nun startet man im zweiten Schritt BossConvert und erhält ein Fenster ähnlich wie in Bild 1 (die Zahlenangaben 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 als Nächstes fest, wie groß der Endgegner sein soll. Dazu klickt man die rechte untere Ecke des Endgegners an, so dass alle Teile des Boss' 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 ("yes") bzw. nicht überlappende Sprites ("no"). Gleichzeitig wird der Define-Modus aktiviert, man braucht nicht extra auf den Define-Knopf zu klicken.

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" - Farbfehler - steht). Werden keine Farbfehler entdeckt, ist alles in Ordnung und der Endgegner könnte so abgespeichert werden. Während des Check-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 Spritesets. 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. Unterhalb der Sprite-Vorschau steht die zugehörige Nummer des Sprites im Spriteset, mit der man in BossEdit sehr schnell die entsprechende Stelle wiederfinden und dann reparieren kann. Die zum Farbfehler führende Ursache muss man allerdings selbst herausfinden, meist sind nur ein oder zwei Pixel irrtümlich in einer fünften Farbe verblieben, was mit BossEdit leicht behebbar ist.

Bild 4: Einen Boss abspeichern
Bild 4: Einen Boss abspeichern
Bild 5: Hier ein Beispiel für andere Spritefarben
Bild 5: Dies hier Beispiele für andere Spritefarben

Kommt kein Farbfehler mehr vor, kann man mit Save zum Speichern des Endgegners im GoDot-SPS-Format (s. unten) 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 ("⇓⇑"). Hinweis: Es ändert sich tatsächlich nur die Zuordnung der Bitmuster zu den Farben, nicht die Verteilung der Farben im Bild.

Die Zahl neben dem Save-Gadget (hier: 10) bezeichnet das Ziellauffwerk. Ein Klick hier hinein zählt hoch bis 11 und fängt dann bei 8 von vorn an.

Sinnvollerweise gibt man seinem Endgegner noch einen aussagekräftigen Namen (maximal 12 Zeichen) und überschreibt dabei den Vorgabenamen ("Boss01"). Schließlich kann man mit nochmaligem Save den Endgegner endgültig abspeichern. Der Name erhält dabei automatisch das Präfix "SPS." (für "Sprite-Set").

Achtung: GoDot versucht zuerst, auf das zuletzt zum Abspeichern von Bildern verwendete Laufwerk zuzugreifen! Wenn hierbei der BossConvert-Requester komplett ausgeblendet wird und die reine Floppymeldung auf dem Hintergrund des Hauptbildschirms übrigbleibt, hat BossConvert versucht, auf ein volles Laufwerk zu speichern oder der Dateiname kommt auf der Disk bereits vor. In diesem Fall die (leider nicht aussagekräftige) Floppymeldung wegklicken, das Modul neu starten, dann mit Save und Klick auf die dort angezeigte Laufwerksnummer ein anderes Ziellaufwerk anwählen.

Wer nur mal schauen wollte, welche zwei Grundfarben BossConvert ermittelt hat, verlässt ohne weitere Maßnahmen mit Ex (für Exit) das Save-Fenster. Übrigens erfolgt beim Aufruf des Save-Fensters ein automatischer Farben-Check. Wird dieser nicht erfolgreich abgeschlossen (wird also ein Alert gemeldet), erscheint das Save-Fenster nicht. Man muss erst mit BossEdit die Farbfehler beseitigen.

Nach dem Speichern zeigt GoDot den Erfolg über eine Floppy-Rückmeldung, die mit einem letzten Mausklick beendet wird. Leave im Hauptfenster von BossConvert schließt das Modul endgültig.

Wer ein verbreiteteres Speicherformat für den Spriteset bevorzugt, speichert das Bild mit SpritePad ab (Subchrist SpritePad, wird auch von Spritemate akzeptiert).

In Bild 4 (und auch in Bild 5) sieht man, dass nicht nur Abstufungen von Grau für die Endgegner sinnvoll sein müssen (in Bild 4: grün und hellgrün, Spriteset aus Rimrunner).

Aussichten

Bild 7: Ein animiertes Sprite
Bild 7: Ein animiertes Sprite
Bild 6: Ein animierter Endgegner
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 Spritesets, wobei zusammengehörige Animationsframes alle in einem einzigen File (bzw. File-Set) abgespeichert werden sollen. Für GoDot werden zukünftig die entsprechenden Tools programmiert: Frame-Builder (der FrameBuilder nimmt die einzelnen mit BossConvert erstellten Animationsphasen entgegen und bildet daraus die Gesamtdatei, deren Länge eigentlich nur vom zur Verfügung stehenden Speicher begrenzt ist), Animator (mit diesem Modul wird dann die Animation entwickelt - und auch abgespielt -, die einzelnen Phasen kommen in Bewegung; hierfür wird eine REU nötig sein), Optimizer (der Optimizer soll Frames mit gleichem Inhalt erkennen und diese markieren, damit sie nicht mehrfach abgespeichert werden müssen, was Platz und Zeit verbraucht, s. Bild 7, wo die meisten Sprites in jedem Frame unverändert bleiben).

Außerdem fehlen (neben dem Animator) noch ein standalone Player für animierte Sprites und ein echter Sprite-Editor (der mehr kann als das Reparatur-Tool BossEdit).

Das SPS-Dateiformat hat (vorläufig, Stand 03/2022) folgenden Aufbau:

SPS-Dateiformat

  File-    Inhalt       Beschreibung
  Offset
  ----------------------------------
  0000     $47 $4f $44  Kennung: "god"
  0003     $37          Filetyp: "7" (Spriteset, Filenamenspräfix muss lauten: "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 (dann 0004/0005 beide = 1),
                        2 oder größer = Es folgt eine Animation, die pro Frame aus mehreren Sprites
                        zusammengesetzt ist (Wert = Anzahl Sprites pro Frame, mindestens also 2)
  0014     $01          Anzahl Frames in *dieser* Datei - wenn 0013 =0 war: Anzahl Einzelsprites in
                        dieser Datei (mindestens: 1)
  0015     $00          Anzahl Folgedateien, die zu dieser Animation/diesem Spriteset dazugehören
                        0 = keine weitere Folgedatei,
                        1 und größer: Anzahl noch folgender Dateien (1: sukzessiv, >1: absolut)

                        Hier beginnt der variable Teil der Datei (frameweise):
  0016     $00          Timer für den Frame: 0 = Standbild, 1 = sehr schnell .. 255 = sehr langsam
  0017     $01          endgültige Anzahl Sprites im Frame (nach Optimierung), max.: Breite × Höhe)
  0018     ...          Darauf folgt die Spritepointer-Tabelle für den anschließenden ersten Frame,
                        die Tabelle umfasst bis zu 80 Bytes, angegeben sind die Indizes der Sprites
                        im jeweiligen VIC-Adressraum (# der 64-Byte-Blöcke).
                        Mit diesen Spritepointern wird die Optimierung vorgenommen (s.o.: "Optimizer")
                        BossConvert selbst speichert hier Dummy-Werte (eine Serie von $ad-Bytes)
                        Genaue Anzahl: Breite × Höhe Bytes, bei Single-Sprite-Anim: der Wert von 0014
  xxxx     ...          erster Frame... (enthält bis zu Breite × Höhe Sprites à 64 Bytes, max. 80)
  xxxx+63  ...          Im 64. Byte jedes Sprites befindet sich die noch fehlende individuelle dritte
                        Farbe des Sprites ($d027 und folgende, Bitmuster %10)
  yyyy     ...          nächster Frame, zuerst wieder Timer, Anzahl, Spritepointer-Tabelle und dann
                        die Sprites...

  zzzz     $ad          Dateiende

Hinweise:
· Voreingestellte bzw. vorgegebene Werte sind fett gedruckt.
· Bisher wird von BossConvert nur der Multicolormodus (Flag an File-Offset 0006) unterstützt. Der SPS-Lader erkennt auch Hires-Spritesets.
· Die Ausrichtung der Sprites im Spriteset ist Sache des einlesenden Programms, das Flag an File-Offset 0011 sagt nur, wie es beim Erstellen gedacht war.
· Die Parameter 0013, 0014 und 0015 spielen zusammen (eine Aufgabe des Frame-Builders):
  · Ist 0013 gleich 0, dann zeigt 0014 die Anzahl der im File enthaltenen Sprites.
  · Wenn 0013 gleich 1 ist, steht in 0014 die Anzahl der Sprites, aus denen die Animation besteht. Ein File = eine Animation (max. 255 Frames).
  · Ist 0013 > 1, dann gibt 0013 die Anzahl Sprites pro Frame an und in 0014 steht die Anzahl der enthaltenen Frames.
  · An 0015 sieht man (generell), ob noch weitere Dateien zu diesem Spriteset/Frameset dazugehören. Dadurch kann man beliebig viele zusammengehörige Sprites/Frames abspeichern. Diese müssen alle den gleichen Namen wie die erste Datei aufweisen und mit einer direkt anschließenden vierstelligen laufenden Nummer versehen sein.
· Byte 0016 ist ein Maß für die Dauer, die ein Frame angezeigt wird. Beim Wert 0 muss von Hand weitergeschaltet werden. Alle anderen Anzeigedauern berechnet ein Player aus dem angegebenen Wert, wobei 1 "keine Verzögerung" bedeutet, 255 "höchste Verzögerung".
· 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. Die Kompression erfolgt frameweise (ein Frame = ein Kompressionsobjekt), außer bei einer Single-Sprite-Animation (alle Sprites = ein Kompressionsobjekt).


Der Sprite-Werzeugkasten (korrespondierende Module):
· SPSto4Bit (zum Umwandeln eines Spritesets in Grafik)
· SpritePad (Lader für Dateien des PC-Sprite-Editors SpritePad)
· SpritePad (Saver für Dateien dieses Programms)
· BossEdit (zum Reparieren eines Spritesets und Begutachten von Vorlagegrafiken)


zurück - zum Standardmodifier-Menü

Arndt Dettke
support@godot64.de