Auf dem Amiga einen animierten „Woosh“-Screen programmieren

 (dansalva.to)
1 Punkte von GN⁺ 2024-02-26 | 1 Kommentare | Auf WhatsApp teilen
  • Magicore Anomala nutzt die Grafik- und Soundfähigkeiten des 1985 erschienenen Amiga, um bildschirmfüllende CGs und animierte Übergänge umzusetzen, doch innerhalb der Game-Engine müssen dabei gleichzeitig RAM-Belegung, Screen-Splitting und Sprite-Beschränkungen gelöst werden
  • In einer typischen Amiga 500-Konfiguration stehen für Grafik und Sound nur 512 KB Chip RAM zur Verfügung, sodass die unkomprimierte Größe von 48 KB für ein 320x240-CG mit 32 Farben eine erhebliche Belastung ist
  • Das CG wird mit ZX0-Kompression auf etwa 8 KB reduziert, im Erweiterungs-RAM abgelegt und erst direkt vor der Anzeige in den Chip RAM entpackt, wobei die vorhandenen 48.000 Byte Screen-Speicher wiederverwendet werden
  • Der Übergangseffekt entsteht dadurch, dass der copper an bestimmten Scanlines Hardware-Register umschaltet sowie bitplane-DMA aus- und wieder einschaltet; die CPU passt dabei pro Frame die copperlist-Werte an die aktuelle Breite des Splits an
  • Die motion lines im Hintergrund müssen Farb-, Wiederverwendungs- und bitplane-Abhängigkeiten der Amiga-Sprites umgehen; zentrale Tricks sind attached sprites, Dummy-Steuerbits, das Aktivlassen von 1 bitplane und die Anpassung von BPLMOD1

Das RAM-Problem bei bildschirmfüllenden CGs auf dem Amiga 500

  • Die Zielplattform von Magicore Anomala ist ein gewöhnlicher Amiga 500 mit 512 KB Chip RAM und 512 KB Erweiterungs-RAM
    • Der Amiga-Chipsatz kann für Grafik- und Soundausgabe nur Chip RAM verwenden
    • Auf Erweiterungs-RAM kann nur die CPU zugreifen, daher lässt es sich nicht direkt für Grafik oder Sound nutzen
  • Die bildschirmfüllende Character Graphic (CG) ist ein 320x240-Bitmap mit 32 Farben und belegt unkomprimiert 48 KB
    • Berücksichtigt man gemeinsame Assets, Level-Daten und die Zuweisung von Screen-Speicher, sind 48 KB ein großer Overhead
  • Die kürzlich hinzugefügte Asset-Kompression verwendet das ZX0-Kompressionsformat
    • Das komprimierte CG schrumpft auf etwa 8 KB
    • Beim Laden der Level-Assets wird das komprimierte CG im Erweiterungs-RAM abgelegt
    • Erst unmittelbar vor der Anzeige wird es in den Chip RAM entpackt

48 KB Chip RAM gewinnen, ohne neuen Speicher freizuräumen

  • Für das CG wird kein separater freier Block von 48 KB Chip RAM gesucht, sondern ein Teil des vorhandenen Screen-Speichers wiederverwendet
    • Hintergrundbild des Raums
    • Screen-Layer zum Rendern gefährlicher Objekte
    • Screen-Bereich der Textbox
  • Diese drei Speicherbereiche liegen im RAM zusammenhängend und ergeben zusammen 48.000 Byte, also exakt die Größe des CG
  • Das Hintergrundbild des Raums kann nach dem Anzeigen des CG wiederhergestellt werden, daher ist ein Überschreiben unproblematisch
  • Das Entpacken des CG dauert etwa 500 ms, wird aber in den Ablauf der Cutscene eingebettet, sodass es nicht wie ein Ladevorgang wirkt
  • Ein Gameplay-Proof-of-Concept-Video von Magicore Anomala ist auf YouTube zu sehen

Screen-Split-Effekt und Einsatz des copper

  • Zunächst wurde ein vertikaler Wipe-Übergang erwogen, doch damit er gut aussieht, wäre ein Gradient nötig gewesen, bei dem pro Scanline die Farbpalette angepasst wird
    • Es wurde angenommen, dass sich allein mit dem copper nicht alle 32 Farben innerhalb eines horizontalen Blankings setzen lassen
    • Da man sich nicht mit „racing the beam“ beschäftigen wollte, fiel die Wahl auf einen Screen-Split-Effekt
  • Ein Screen-Split wirkt auf normale Betrachter eindrucksvoller, und der copper des Amiga verhält sich fast so, als sei er genau für solche Effekte entwickelt worden
    • Ein ähnlicher Effekt ist sogar in Amiga Workbench eingebaut; zu sehen in diesem Video
  • Für die Umsetzung werden zwei Funktionen des Amiga kombiniert
    • Der copper führt parallel zur CPU seine eigene Befehlsliste aus und kann auf bestimmten Bildschirmzeilen Hardware-Register umschalten
    • Screen-Pointer lassen sich über Hardware-Register so setzen, dass der Screen-Speicher auf jede beliebige Position im Chip RAM zeigt

Bitplane-DMA anhalten und später weiterzeichnen

  • Wenn der Haupt-Screen-Speicher beispielsweise bei 0x20000 beginnt, setzt der copper normalerweise diese Adresse in die bitplane-DMA-Register
    • Sobald die bitplanes aktiv sind, liest DMA diesen Speicherbereich der Reihe nach aus und zeichnet ihn auf den Bildschirm
  • Wenn jede horizontale Zeile 0x100 Byte belegt und der Screen-Pointer auf 0x20800 gesetzt wird, sieht es so aus, als wäre der Screen um 8 Zeilen nach oben gescrollt
    • Der Startpunkt des Bildschirms wurde im Speicher nämlich um 8 Zeilen nach unten verschoben
  • Die obere Hälfte des Splits wird auf diese Weise nach oben gescrollt
  • Am Split-Punkt schaltet der copper die bitplane-DMA aus und ändert die Hintergrundfarbe zu Rot
    • Die bitplane-bezogenen Hardware-Register frieren an diesem Punkt praktisch ein
    • Sobald der untere Teil des Splits erreicht wird, wird die Hintergrundfarbe wiederhergestellt und bitplane-DMA wieder aktiviert
    • Das Bild wird ab der angehaltenen Position weitergezeichnet, erscheint aber an einer tieferen Stelle auf dem Display
  • In jedem Frame passt die CPU vs_TCopTop und vs_TCopBottom an die aktuelle Breite des Splits an
    • Die Anpassung des Screen-Pointers für den oberen Split erfolgt ebenfalls, ist im Codebeispiel aber nicht enthalten

Sprite-Workarounds für die „Woosh“-Motion-Lines

  • Die motion lines des animierten Hintergrunds werden mit Sprites gezeichnet
    • Sprites werden unabhängig vom Screen-Speicher gezeichnet und lassen sich bewegen, daher eignen sie sich gut für diesen Zweck
    • Allerdings sind Amiga-Sprites stark eingeschränkt und aufwendig zu handhaben

  • Farbbeschränkungen

    • Sprites teilen sich bitplanes und Farbpalette, daher sollten möglichst wenige Farben verwendet werden
    • Die motion lines nutzen nur 3 Farben und lassen damit 28 Farben für das CG sowie 1 Farbe für den Hintergrund übrig
    • Beim Amiga verwendet jedes Sprite-Paar einen anderen Bereich der Palette
      • Die ersten beiden Sprites verwenden die Farben 16–19
      • Die nächsten beiden Sprites verwenden die Farben 20–23
    • Werden zwei Sprites attached, verhalten sie sich wie ein einzelnes Sprite mit 16-Farben-Palette und können die Farben 16–31 nutzen
    • Die motion lines verwenden 4 attached sprites; in der Grafik kommen nur die Farben 29–31 zum Einsatz

  • Dasselbe Sprite-Grafikmaterial an mehreren Positionen verwenden

    • Die ersten 4 Byte einer Sprite-Grafik sind Steuerbits, die Position und Höhe festlegen
    • Dadurch wird es schwierig, dieselbe Grafik an mehreren Positionen zu zeichnen
    • Es wurde versucht, die Sprite-Steuerbits direkt über Hardware-Register zu setzen, doch so ließen sich die Sprites nicht auf dem Bildschirm sichtbar machen
    • Die Sprite-DMA des Amiga folgt, ähnlich wie bitplane-DMA, den Zeigern auf die Sprite-Daten und zeichnet sie auf den Bildschirm
    • Die Lösung besteht darin, 8 gefälschte Sprites von je 4 Byte anzulegen
      • Diese gefälschten Sprites enthalten nur die Steuerbits
      • Alle Sprite-Pointer werden zunächst auf die gefälschten Sprites gesetzt
      • Nach etwa 19 Zeilen hat die Sprite-DMA die Pointer gelesen und die Steuerbits geladen
      • Danach werden alle Pointer auf die eigentliche „motion line“-Grafik umgeschaltet
    • Das Ergebnis ist, dass die DMA Sprites mit unterschiedlichen Positionen, aber derselben Grafik zeichnet; diese Umschaltung wird in der copperlist erledigt

Das Problem, dass beim Abschalten der bitplanes auch die Sprites verschwinden

  • Bevor das CG den oberen Rand des Bildschirms erreicht, befindet sich zwischen dem oberen Bildbereich und dem Beginn des CG leerer Raum
    • Wenn dort bitplanes aktiv bleiben, wird auf dem Bildschirm Zufalls- bzw. Müllspeicher dargestellt
  • In diesem Bereich müssen die bitplanes deaktiviert werden, damit DMA keine solchen Daten ausliest
  • Das Problem ist, dass beim Abschalten der bitplanes auch die Sprites nicht mehr gezeichnet werden
    • Dadurch wären die motion lines nur innerhalb der Grenzen des CG sichtbar
  • Die Lösung besteht darin, die bitplanes nicht vollständig abzuschalten, sondern 1 bitplane aktiv zu lassen und den Screen-Pointer auf leere Daten zu setzen
    • So wird zwar technisch etwas gezeichnet, sichtbar ist aber effektiv nichts
  • Es ist nicht nötig, dafür einen komplett leeren Screen bereitzuhalten
    • Bei 1-Bit-Pixeln entspricht eine Zeile mit 320 Pixeln 320 Bit, also 40 Byte
    • Wenn BPLMOD1 auf -40 gesetzt wird, springt der Pointer nach jeder Zeile 40 Byte zurück und zeichnet dieselben 40 Byte immer wieder
    • Es genügt daher, die ersten 40 Byte im Safety-Margin-Bereich des Bildschirms leer zu lassen

Ergebnis und verbleibende Detailaufgaben

  • Anfangs war wegen des RAM-Bedarfs unklar, ob sich solche CGs überhaupt ins Spiel integrieren lassen würden, doch nach der Implementierung der Datenkompression zeigte sich, dass der Overhead sehr vernünftig ist
  • Damit können Magicore zusätzliche visuelle Verzierungen hinzugefügt werden
  • Einige kleinere Aufgaben bleiben weiterhin offen
    • Zum Beispiel, wie sich verhindern lässt, dass bei einer 100px-motion-line der untere Teil abrupt verschwindet, nachdem sie oben aus dem Bildschirm gelaufen ist
  • Dieser Effekt verwendet den blitter überhaupt nicht
  • Der Amiga bleibt eine Plattform, die Menschen mit ihrer Fähigkeit zur Darstellung von Farbgraphik beeindrucken kann – heute genauso, wie sie Menschen Ende der 1980er beeindruckte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-02-26
Hacker-News-Kommentare

  • Jetzt verstehe ich genau, was „Racing the beam“ bedeutet. Früher haben wir am Anfang und Ende einer per Vsync synchronisierten Routine die Beam-Farbe unterschiedlich gesetzt, um auszurechnen, wie viele Scanlines CPU-Zeit pro Frame wir nutzen konnten.
    Ich erinnere mich, dass die Adresse dafür $dff180 war. Das war Farbpalette 0 und daher auch am Bildschirmrand außerhalb des Bitmap-Bereichs immer sichtbar.
    Auch diesen Trick haben wir komplett per Mundpropaganda gelernt, ohne Internet, und ich wusste nicht, dass es heute noch Leute gibt, die aus diesem Chipsatz noch mehr herausholen wollen.

  • Ich frage mich wirklich, wer die Leute sind, die sich Zeit nehmen, Spiele für den Amiga zu entwickeln. Jüngere Leute interessieren sich vermutlich nicht für so alte Computer, und die, die damit aufgewachsen sind, dürften mit Familie und Arbeit beschäftigt sein.
    Selbst wenn man nicht beschäftigt ist, gibt es so viele Projekte, die genauso viel Spaß machen und zugleich zeitgemäß bleiben können. Trotzdem ist es wirklich großartig.

    • Ich bin Jahrgang 1991, und bevor wir auf einen Windows-95-PC umgestiegen sind, hatten wir zu Hause einen Amiga 1000. Deshalb hatte ich immer eine gewisse Nostalgie für den Amiga, und meine Zuneigung ist gewachsen, je besser ich die besonderen und leistungsfähigen Chips verstanden habe, die diese Performance ermöglichten.
      Heute arbeite ich hauptberuflich als Indie-Game-Entwickler. Ein Amiga-Spiel zu machen war so etwas wie ein Lebenstraum, und ich glaube, dass ich jetzt die Fähigkeiten habe, es umzusetzen.
      Ich möchte zeigen, dass man mit heutigen Werkzeugen und dem heute weit verbreiteten Wissen geliebter klassischer Hardware neues Leben einhauchen kann – mit Spielerlebnissen, die nach modernen Designprinzipien gebaut sind.
    • Für viele Leute gibt es nichts, was so viel Spaß macht wie Amiga, C64, Atari oder ZX Spectrum.
      Wenn man alles im Leben mit der Karriere verknüpft, wird das ganze Leben zur Arbeit.
      Das ist ähnlich wie zu fragen, warum man Ölmalerei übt, wenn es Photoshop gibt, oder warum man ein Oldtimer-Auto restauriert, wenn es Tesla gibt.
    • Ich bin vielleicht nicht jung genug, um in diese Gruppe zu fallen, aber ich mag viele Computer, die meiner Zeit ein wenig voraus waren. Ich habe mir einen Commodore 64 besorgt, die Kondensatoren getauscht, die PLA ersetzt und sogar Dual-SID- und „Region-Switch“-Mods eingebaut.
      Der Region-Switch-Mod ist ziemlich aufwendig, weil man zwei VIC-II-Chips und zwei Oszillatoren umschalten muss. Ich habe auch einen MSX2, mit dem ich zwar nicht viel gemacht habe, der aber sehr reizvoll ist.
      Zeit zu finden, tatsächlich Code für solche Maschinen zu schreiben, ist schwierig, aber ich sehe es wie bei den meisten Hobbys von Berufstätigen: Wenn die Inspiration kommt, steckt man Nächte und Wochenenden hinein.
      Retrocomputing ist ein faszinierendes und lohnendes Hobby. Allerdings ärgern mich noch mehr als die Zeit die Preise und die Schwierigkeit, an Teile zu kommen.
      Es ist schade, dass im Computermarkt scheinbar immer mehr Leute alles mit dem Etikett „antik“ oder „vintage“ teuer verkaufen wollen.
      Für die Älteren kann ich nicht wirklich sprechen, aber bei einigen der Leute, die immer noch Commodore-64-Demos machen, scheint der Wunsch groß zu sein, wieder an ihre Kindheit anzuknüpfen.
      Es gibt sogar Werke, die das fast direkt erzählen, etwa die relativ neue Demo „Mojo“ von Bonzai und Pretzel Logic. Der Versuch, in einem Demoscene-Werk „ernsthaftes“ Storytelling zu betreiben, ist ein bisschen zum Fremdschämen, aber ich finde es trotzdem sympathisch.
      Es ist ein zeitintensives Hobby, aber wenn man sich wirklich Zeit dafür nehmen will, findet man am Ende einen Weg.
      [1]: https://csdb.dk/release/?id=232966, https://www.youtube.com/watch?v=HXi3oJ9huiI
    • Ich habe einen Freund, der Interfaces baut, um neue Gamecontroller an alte Computer anzuschließen. Hier verbindet er ein Nintendo Balance Board, um Decathlon auf dem Commodore 64 damit zu spielen.
      [1] https://retro.moe/2024/02/04/bluepad32-v4-0/
      [2] https://www.youtube.com/watch?v=Nj5fZlt_834
    • Ich bin fünf Jahre älter als der Autor des Originalbeitrags. Zu Beginn der Pandemie habe ich aus Spaß Atari- und Amiga-Hardware und ein paar Materialien gesammelt, um Assembler zu lernen. Es gibt auch einen Udemy-Kurs.
      https://www.udemy.com/course/programming-games-for-the-atari...
      Ich dachte, durch Homeoffice hätte ich mehr freie Zeit, aber in der Realität war das nicht der Fall. Trotzdem muss ich irgendwann daran weiterarbeiten.

  • Ich habe mich immer gefragt, wie Spiele im Stil japanischer Konsolen auf dem Amiga ausgesehen hätten, und ob dem Amiga die Leistung fehlte oder ob mir einfach das Design der meisten Spiele nicht zusagte.
    Bonk wurde von Factor 5 hervorragend portiert, aber die waren praktisch Zauberer.

  • Die Aussage „Ein gewöhnlicher Amiga 500 hat 512 KB Chip RAM und 512 KB Erweiterungs-RAM“ ist etwas ungenau. Der grundlegende A500 hatte nur 512 KB Chip RAM.
    Viele Nutzer ergänzten eine A501-RAM-Erweiterung und bekamen dadurch 512 KB Fast RAM, auf die die Grafikhardware nicht direkt zugreifen konnte.
    Es wurde zwar als Fast RAM bezeichnet, war wegen der Erweiterungsarchitektur aber langsamer als echtes Fast RAM.

    • Das sogenannte Slow RAM.
      Die meisten A500-Besitzer hatten eine 512-KB-Trapdoor-Erweiterung. Viele Programme, darunter Spiele wie Monkey Island, liefen ohne insgesamt 1 MB RAM nicht.
      Heute gibt es günstige Trapdoor-Erweiterungen mit offenen Hardware-Designs weit verbreitet; sie bieten 1,5 MB Slow RAM, 512 KB Chip RAM, um auf insgesamt 1 MB zu kommen, und sogar eine RTC.

  • Es hat etwas unglaublich Anziehendes, innerhalb solcher Einschränkungen zu coden.

    • „Der Feind der Kunst ist die Abwesenheit von Einschränkungen.“

  • Schön, IE zu sehen. Freut mich, dass du dich in den Amiga vertiefst.

  • Ich habe das Gefühl, dass viele Leute mit einem anderen Amiga herumgespielt haben als ich. Es gab definitiv Spiele, die cool aussahen, aber das galt auch für das Nintendo NES, und auf beide blicke ich nicht mit so viel Zuneigung zurück.
    Trotzdem ist es sehr cool zu zeigen, wie so eine Animation gemacht wurde.

    • Ich hatte beide, und der Amiga fühlte sich ehrlich gesagt wie eine Maschine zwei Generationen voraus an. Wenn man sich den Hardware-Unterschied ansieht, ist das auch kein Wunder.
      Der Amiga war wirklich ein System, in dem alles steckte: eine hochwertige 32-Bit-CPU, Grafikbeschleunigung, großartiges Audio und buchstäblich 256-mal so viel RAM wie das NES.
      Nicht einmal das SNES kam nahe heran; erst in der Sega-Saturn-Ära sah ich Maschinen, die den Amiga übertrafen.
    • Nur zur Sicherheit gefragt: Ist dir bewusst, dass das ein neues Spiel ist, das gerade entwickelt wird?
      https://www.youtube.com/watch?v=4SB20aFHc08