Vor etwa vier Monaten habe ich ein Video gemacht, in dem ich ein neues Projekt vorstelle, an dem ich arbeite: eine Portierung von Zippy Race, dem frühen Arcade-Spiel von Irem aus dem Jahr 1983, auf einen Standard-Amiga 500 mit nur 512 Kilobyte Erweiterungsspeicher. Das Video schildert hauptsächlich einige der anfänglichen Entwicklungsherausforderungen, mit denen ich konfrontiert war, sowie die Techniken, die ich für die Entwicklung gegen Amiga- Spezialhardware eingesetzt habe. Ich hatte zwar eine Grundstruktur mit scrollenden Spielfeldern und verschiedenen anderen Systemen erstellt, aber das war noch lange kein Spiel. Nun, vier Monate später, habe ich folgende Fortschritte erzielt. Wir haben uns von einer rollenden Demo zu einem vollwertigen Spiel entwickelt, in dem alle Level, die kompletten Fahrzeug- und Verkehrssysteme, Kollisionen usw. integriert sind. Das gesamte Spiel ist hier von Anfang bis Ende durchspielbar, einschließlich der zweiten und dritten Schwierigkeitsstufe, falls Ihnen diese bekannt sind. Wenn wir es direkt mit der Arcade-Version vergleichen, ist es eine sehr originalgetreue Umsetzung, und ich habe viel Zeit, Sorgfalt und Aufmerksamkeit darauf verwendet, sicherzustellen, dass dieses Spiel so perfekt wie möglich dem Arcade-Original entspricht. Zusammenfassend lässt sich also sagen, dass Zippy Race auf dem Amiga auf einer Standard-OCS-Maschine in Vier-Bit-Ebenen läuft, das heißt, mit nur 16 Farben. Der Scroll-Teil des Spiels läuft in einer eigenen Karte für den Anzeigebereich. Um den Bildschirm zu scrollen, verwenden wir die Amiga- Scrolltrick-Methode, indem wir die Bitplane-Zeiger Pixel für Pixel nach oben bewegen, um diesen sanften Scroll-Effekt zu erzielen. Wenn der Zeiger das Ende der Bitmap erreicht , springt er zu einer Kopie derselben Bitmap, die darüber liegt . Während das Spiel scrollt, wird also nicht der gesamte Bildschirm aktualisiert. Es wird jeweils nur eine Reihe von Kacheln aktualisiert, nämlich 20 Kacheln der Größe 16 x 16 für die Bitmap auf dem Bildschirm sowie weitere 20 Kacheln der Größe 16 x 16 für die Bitmap außerhalb des Bildschirms. In meiner vorherigen Folge bin ich auf diesen Ansatz bereits ausführlich eingegangen. Für das HUD verwenden wir vier 16×256 Amiga-Hardware-Sprites und aktualisieren nur die notwendigen Elemente, wenn diese auftreten. Zum Beispiel die Punktzahl, die Rangliste, die Tankanzeige und die Fortschrittsanzeige der Etappen, falls erforderlich. Da diese Ereignisse nicht in jedem einzelnen Frame auftreten, ist der Leistungsverlust hier vernachlässigbar. In einigen Szenarien verwenden wir bis zu vier Hardware-Sprites, um das Motorrad darzustellen, einschließlich der Kollisionsanimation, wenn das Motorrad gegen ein Objekt prallt und ins Schleudern gerät. Aber auch im Abschnitt zur 3D-Vorderansicht verwenden wir zwei 16×32-Sprites, die insgesamt vier Amiga-Hardware-Sprites (0 bis 3) belegen. Und wiederum werden die verbleibenden Sprites (4 bis 7) vom HUD verwendet. Bei Zippy Race, dem Arcade-Spiel, sind zu Beginn eines Rennens fünf Autos gleichzeitig auf dem Bildschirm zu sehen. Und wenn ein Rennen beginnt, kommt ein Round-Robin- Algorithmus zum Einsatz. Wenn das Motorrad beispielsweise beschleunigt, erscheinen je nach Geschwindigkeit des Motorrads entweder Autos vor oder hinter dem Motorrad. Das ursprüngliche Arcade-Spiel nutzte ein Irem M52-Board mit zwei Z80-CPUs. Für diese Amiga-Version habe ich keinerlei Reverse Engineering des Spiels betrieben und das Verkehrssystem größtenteils nach Gefühl entwickelt. Ich habe mir allerdings den MAME-Quellcode angesehen, um Informationen und Richtlinien zu erhalten. Beim Amiga verfügt jedes Auto über ein eigenes Seitenkraftspeichersystem, dessen Wert zwischen -1 und +1 schwankt. Ich setze dies ein, um ein sanftes Lenkverhalten anstelle eines abrupten Spurwechsels zu erreichen. Die Fahrzeuge lesen aus einem Straßenmittelpunkt-Cache, einer 256 Einträge umfassenden Nachschlagetabelle, die während der Scrollroutine erstellt wird und jede Y-Position auf dem Bildschirm der X-Koordinate des Straßenmittelpunkts zuordnet. Dies ist die optimale Methode zur Fahrzeugpfadfindung. Es hilft auch dabei, Kurven vorherzusehen. Die Autos werden vorausschauend lenken, bevor die Kurve sie erreicht, anstatt zu reagieren und schnell in die Kurve einzulenken. Das Autoverkehrssystem und die Wegfindung funktionieren größtenteils recht gut . Das größte Problem, das ich mit den Autos hatte, war, sie auf einen scrollenden Hintergrund zu projizieren. Jedes Auto ist ein 32 x 32 Pixel großes Bild mit vier Bit-Ebenen, und wir müssen einen Cookie-Cutter-Blit in das Spielfeld durchführen. Das klingt einfach, aber es hat einige Wochen des Ausprobierens, Testens, erneuten Testens und Umschreibens gedauert, bis es endlich funktionierte. Am Ende musste ich also auf das sogenannte Dreifachpuffern zurückgreifen. Dies ist jedoch nicht unbedingt dasselbe wie das Dreifachpuffern, das man beispielsweise vom PC kennt. Dreifaches Puffern auf dem Amiga bedeutet etwas anderes, und ich möchte es Ihnen so gut wie möglich erklären. Im Wesentlichen geschieht Folgendes: Die Tile-Engine zeichnet gleichzeitig in alle drei Puffer, wobei der Prinsite-Puffer mit dem scrollenden Hintergrund synchronisiert bleibt. Das Fahrzeug-Rendering erfolgt in drei Durchgängen. Im ersten Durchlauf wird der Hintergrund aus dem ursprünglichen Puffer wiederhergestellt. Im zweiten Durchlauf werden alle Positionen aktualisiert, und im dritten Durchlauf werden alle Blitter- Objekte gezeichnet. Ohne den ursprünglichen Puffer müssten wir den Hintergrund unter jedem Blitterobjekt in einem kleinen Sicherungspuffer speichern und ihn dann im nächsten Frame wiederherstellen. Dies führt jedoch zu einem Problem, wenn sich zwei Blitter- Objekte überlappen. Die Wiederherstellung des einen führt zur Beschädigung des anderen, und vor einem scrollenden Hintergrund wird die Sache noch komplizierter. Der makellose Puffer löst dieses Problem also vollständig. Es stellt stets eine saubere Version des Hintergrunds auf dem aktuellen Bildschirm wieder her. Der Ansatz mit dem dreifachen Puffer ist also kein neues Konzept. Das gibt es schon seit den Anfängen der Amiga-Spiele im Jahr 1986. Das Problem ist aber, dass wir durch die drei 192 x 579 x 4 Bit-Plane-Bitmaps im Grunde ein Drittel des gesamten Chipspeichers des Amiga belegen. Allein für diese Bildschirmpuffer haben wir bereits über 160 Kilobyte Chipspeicher verwendet . Und das ist noch bevor wir über Dinge wie die gesamten Sprite-Daten, die gesamten Tile- Sheets, die gesamten Hintergründe, die verschiedenen Soundeffekte und die Musik sprechen. Wir sprechen hier von einem beträchtlichen Teil des Chipspeichers, der allein durch diese drei Puffer belegt wurde. Das bedeutet, dass wir vor einem Problem stehen, denn wir müssen uns jetzt wirklich Gedanken über das Speichermanagement machen . Das größte Problem, das ich nach der Implementierung des Triple- Buffering-Ansatzes hatte, war, dass mir schnell klar wurde, dass der Chipspeicher knapp wurde und ich mir einen Plan ausdenken musste, um dieses Problem zu umgehen . Zuerst dachte ich, ich würde vielleicht einfach die Niederlage hinnehmen und das Spiel mit nur 1 Megabyte Chipspeicher laufen lassen und diese Beschränkung etwas lockern. Ich bestand aber darauf, dass dieses Spiel mit nur 512 Kilobyte Chipspeicher auf einem Amiga mit Kickstart 1.3 als Basis laufen sollte. Um das Ganze in den Speicher zu bekommen, habe ich letztendlich ein Speicherverwaltungssystem implementiert . Anfänglich sollte das Spiel so funktionieren, dass ich alle Kachelbögen, alle Hintergrunddaten, alle Soundeffekte und alle Musikdaten in den Chipspeicher lade und sie verfügbar halte, um sie dann bei Bedarf bereitzustellen. Aber ich dachte mir, nun ja, ich habe 512 Kilobyte schnellen Speicher, also wäre es besser, anstatt es so zu machen, ein Speicherverwaltungssystem zu erstellen, das im Grunde den schnellen Speicher des Amiga, die 512K schnellen Speicher, die mir zur Verfügung stehen, nutzt, um all diese Daten während der Initialisierung bereitzustellen, wenn eine Phase im Begriff ist zu beginnen, und die relevanten Teile der Phasendaten, die Asset-Daten für diese Phase, vor Beginn der Phase in den Chipspeicher zu verschieben. Was ich damit meine, ist, dass wir die entsprechenden Tilesheets, die Tilemaps, die abzuspielende Musik, den Horizont der Bühnenstadt und verschiedene andere Assets in den Chipspeicher verschieben, bevor die Bühne geladen wird. Das ständige Hin- und Herschreiben dieser Daten zwischen Chipspeicher und schnellem Speicher hat das Problem gelöst. Ich konnte das gesamte Spiel mit nur 512 KB Chipspeicher unterbringen. Dieser Ansatz hat sich wirklich bewährt, und am Ende stehen mir jederzeit insgesamt etwa 60 Kilobyte freier Chipspeicher zur Verfügung , was bedeutet, dass ich weiterhin zusätzliche Animationen und verschiedene andere Soundeffekte in das Spiel einbauen kann, um es so nah wie möglich an das Arcade-Original heranzubringen. Doch dadurch wurde auch ein anderes Problem deutlich, das ich hatte. Da wir Daten vom Schnellspeicher in den Chipspeicher kopieren, und wir von einem 7-MHz-Amiga sprechen, muss dieser Kopiervorgang so schnell wie möglich erfolgen. Mit anderen Worten: Wir müssen so wenige Daten wie möglich vom schnellen Speicher in den Chipspeicher kopieren, um sie bereitstellen zu können. Also habe ich schließlich ein Komprimierungssystem in einige dieser Assets integriert, um die Dateigrößen zu reduzieren. Das Kopieren einer komprimierten Kachelkarte, die nur 2 Kilobyte groß ist, ist wesentlich einfacher als das Kopieren einer 30 Kilobyte großen Karte. Das Dekomprimierungssystem ist selbst auf einer 68000 recht schnell und benötigt nur wenige Frames, um diese Daten zu dekomprimieren . Und all das geschieht zwischen den einzelnen Phasen. Wenn man beispielsweise die erste Etappe in Zippy Race geschafft hat, gibt es hier eine ganz kurze Pause, in der das Spiel in den Chipspeicher dekomprimiert wird, und dann wird die Spielstufe normal geladen. Und dies nutzt natürlich schnellere Beschleunigerprozesse aus. Mit einer 020 Plus ist die Dekomprimierung deutlich schneller als mit einer Standard-68000. Das ist also ein Gewinn für alle Beteiligten. In meiner vorherigen Folge bin ich bereits ausführlich darauf eingegangen, wie ich meine Kachelbögen und Kachelkarten erstellt habe. Ich verwendete Personal Paint auf dem Amiga, um meine Kachelblätter zu erstellen, und ein Tool namens Power Crawler, ein weiteres Amiga-Programm, nutzte ich, um meine Kachelkarten zu erstellen. Im Großen und Ganzen funktionierte dieser Prozess recht gut, aber ich bemerkte, dass ich viele Probleme damit hatte. Ich wollte einen Weg finden, diesen Prozess noch besser zu optimieren . Idealerweise wollte ich einzelne Frames aus MAME als PNG- Dateien exportieren, sie in ein Tool wie Aseprite laden und dann im Wesentlichen den gesamten Viewport auf ein Tile-Sheet kopieren, um daraus dann meine Tilemaps erstellen zu können. Das ist jedoch nicht optimal, da es zu vielen doppelten Kacheln kommen wird. Beispielsweise wird eine Straßenkachel, die ein einzelner grauer Block ist, in einer einzigen Kachelkarte immer und immer wieder wiederholt. Deshalb beschloss ich, mein eigenes Tool zu entwickeln, um dies zu ermöglichen. Und das ist bekannt als Zippy Ed. Dies ist eine C++-Anwendung, die von Grund auf mit ImGui, OpenGL und SDL 3 speziell für dieses Projekt entwickelt wurde, obwohl sie auch für jedes andere Amiga-Projekt, das Tilemaps und Tilesheets verwendet, angepasst werden könnte. Es deckt die gesamte Asset-Pipeline ab. Es verwaltet [Musik-]Kachelblätter, Kachelkarten, Kollisionsdaten und Farbpaletten. Und das Beste daran ist, dass es das Amiga IFF-Format verwendet. Die wichtigsten Funktionen dieses Tools sind für mich ein Lebensretter. Wie bereits erwähnt, können wir IFF-Kachelblätter laden und speichern. Es unterstützt auch das raw.io-Kachelkartenformat. Es gibt ein visuelles Kollisionssystem mit Linien und Oberflächenart-Überlagerungen. Und es gibt eine sehr leistungsstarke Duplikaterkennung und -konsolidierung. Die Kachelbögen können komprimiert werden, wobei jede einzelne leere oder ungenutzte Kachel entfernt und die Kachelkarte per Knopfdruck neu erstellt wird . Sie können aus Tools wie Aseprite mehrere Kacheln in die Zwischenablage einfügen. Sie können Zeilen an jeder beliebigen Position sowohl in der Kachelkarte als auch im Kachelblatt einfügen und löschen. Zusätzlich verfügt es über Bildschirmrand-Overlays, die 256 Pixel große Grenzen entweder vom unteren oder vom oberen Kartenrand anzeigen, um eine realistische Arcade-Genauigkeit zu gewährleisten. Es besteht sogar die Möglichkeit, die Farbpalette zu modifizieren, Palettenindizes neu zuzuordnen und Indizes zu vertauschen . Sie können die Farbpalette auch mit einer zweiten Referenzpalette vergleichen und einzelne Farben gezielt auswählen, um die Konsistenz über alle Arbeitsschritte hinweg zu gewährleisten. Mit der Tausch- und Neuzuordnungsfunktion können Sie Palettenindizes neu organisieren und gleichzeitig alle Pixeldaten automatisch aktualisieren. Dies war unerlässlich, um die Fahrzeugfarben in Etappen mit unterschiedlichen Terrainpaletten einheitlich zu halten. Zippy Ed ist ein Tool, ohne das ich nicht leben kann, und ich bin so froh, dass ich mir die Zeit genommen habe, es zu entwickeln. Ich habe gerade festgestellt, dass alle anderen Tile-Editoren auf dem Markt, einschließlich Tiled und diverser anderer, zwar sehr gut funktionieren, aber nicht für den Amiga ausgelegt sind, und genau dafür wollte ich diesen Editor haben . Beim Amiga ist 50 Hz PAL mittlerweile der vorherrschende Standard . Amiga-Spiele sind in der Regel für 50 Hz PAL ausgelegt. Aber ich lebe in Nordamerika, und viele andere Leute, die ich kenne und die Amigas besitzen, sind ebenfalls Nordamerikaner. Und ich wollte sicherstellen, dass das Spiel 60 Hz NTSC unterstützt, was bedeutet, dass wir insgesamt nur 200 Pixel am Bildschirmrand haben anstatt 256 Pixel, weshalb ich einige kleine Anpassungen an der Position des Motorrads und einigen anderen Platzierungen vornehmen musste . Letztendlich konnte ich jedoch sicherstellen, dass dieses Spiel sowohl auf PAL- als auch auf NTSC-Systemen mit 50 Hz oder 60 Hz geladen wird. Und außerdem wollte ich sicherstellen, dass das Spiel auf PAL mit festen 50 Hertz und auf NTSC mit 60 Hertz läuft . Und wie Sie hier mit Engine 9000, einem wirklich großartigen Amiga- Debugger, sehen können, können Sie sehen, dass wir während der Level mit Arcade- Perfektion bei 50 und 60 Hertz laufen. Wenn Sie also jemand aus Nordamerika sind, können Sie dieses Spiel auf einem NTSC Amiga spielen. Sie müssen keine seltsamen Anpassungen an Ihrem Bildschirmformat vornehmen, damit es im PAL-Modus läuft. Wenn Sie einen NTSC Amiga 500 mit Erweiterung besitzen, können Sie dieses Spiel sofort nach dem Auspacken spielen. Ich wollte sicherstellen, dass NTSC vollständig unterstützt wird, denn ich liebe 60 Hertz. Ich würde es vorziehen, wenn die Spiele mit 60 Hertz statt mit 50 Hertz laufen würden. Eine weitere Einschränkung, die ich hatte, betraf das Head-up-Display. Das Head-up-Display besteht, wie bereits erwähnt, aus vier Hardware-Sprites, nämlich Sprite vier, fünf, sechs und sieben. Und jeder Sprite teilt sich Farbregister paarweise. Da wir die Farben einheitlich halten wollen, da wir im Grunde möchten, dass alle Sprites die gleichen Farben haben, mussten wir sie alle gleich gestalten. Und da uns nur drei Farben zur Verfügung stehen, bedeutete dies, dass es Einschränkungen hinsichtlich der möglichen Farben gab. Was ich damit meine, ist Folgendes: Wenn man sich die Arcade-Version ansieht, ist die Highscore-Tabelle rot und der Punktewert braun. [Musik] Und nicht nur das, der Text, der beim Spielstart angezeigt wird, blinkt ständig. Und leider konnten wir dies in der Amiga-Version mit 16 Farben nur erreichen, indem wir alle Farben gleichfarbig, nämlich weiß, gestalteten. Nun läuft das Kupfer synchron mit dem Videostrahl. Und während der Strahl über den Bildschirm läuft, kann das Kupfer die Hardware-Register an bestimmten Scanzeilen verändern. Wir können also sagen, dass wir, wenn sich das Kupfer an einer bestimmten Position oder einer exakten Scanzeile befindet, die Farbregisterwerte dieser bestimmten Werte ändern können. Wir warten also in Scanzeile 30 und setzen dann die Farben 17 bis 19 auf Rot, was bedeutet, dass der Highscore- Wert nun rot ist. Und dann, bei Scanzeile 38, also acht Pixel weiter unten, stellen wir es wieder auf Weiß [Musik], damit die darüber liegende Zeile zeichnen kann. Und dann stellen wir in Scanzeile 41 die Farbe Kupfer ein, indem wir die Farbregister 17 bis 19 für die Partitur auf Braun setzen, und dann stellen wir sie in Scanzeile 4A wieder auf Weiß zurück. Der hier zu sehende Blitz nach oben funktioniert nach demselben Prinzip. Wir verwenden hierfür eine Kupferliste. Im Wesentlichen schalten wir die Farbangaben für die Punktzahl alle 300 Millisekunden zwischen der normalen Farbe Weiß und Schwarz um . Und dies simuliert im Grunde das Ein- und Ausschalten des Geräts durch die Verwendung einer einfachen Kupferliste. Aber insgesamt bin ich sehr, sehr zufrieden damit, wie dieses Spiel geworden ist. Und hoffentlich geht es Ihnen genauso. Dies war mein erstes richtiges Amiga-Projekt, abgesehen von Portierungen auf beschleunigte Amigas, was ja selbst schon eine komplizierte Angelegenheit ist. Es ist eine andere Art von Arbeit, weil man im Grunde Spiele vom PC auf beschleunigte Amigas portiert und versucht, sie so gut wie möglich zum Laufen zu bringen, aber man nutzt dabei keine spezielle Hardware. Wenn ihr das Spiel selbst spielen wollt, schaut doch mal auf meiner itch.io-Seite vorbei. Schauen Sie es sich gerne an und teilen Sie mir Ihre Meinung dazu in den Kommentaren unten mit. Es ist selbstverständlich kostenlos. Aber ich habe aus diesem Prozess definitiv viel gelernt . Ich liebe es, Spiele auf dem Amiga zu entwickeln. Das Ganze ist definitiv eine Kunstform. Es wird nicht immer intuitiv sein, vor allem wenn man aus der modernen Spieleentwicklung kommt. Sich mit diesen Konzepten auseinanderzusetzen, etwas über Custom-Chips zu lernen, zu lernen, wie man Dinge zeichnet und wie man Sprite-Hardware, Blitter-Hardware und Kupfer optimal nutzt, macht einfach unglaublich viel Spaß. Wissen Sie, wenn erst einmal alles organisiert ist und gut funktioniert, kann das ein sehr lohnender Prozess sein. Aber wir belassen es für die heutige Folge dabei. Vielen Dank fürs Zuschauen. Wenn es euch gefallen hat, vergesst bitte nicht, mir einen Daumen hoch dazulassen, und wir sehen uns in der nächsten Folge. Bis bald.