a5k – Another World / Out of This World auf FPGA portiert

 (github.com/sylefeb)
1 Punkte von GN⁺ 2023-07-16 | 1 Kommentare | Auf WhatsApp teilen
  • Ein persönliches Hommage-Projekt, das VM, Blitter und Rasterizer von Another World / Out of This World ohne Standard-CPU in FPGA-Hardware implementiert
  • Das Kerndesign besteht aus einer VM als realem Custom-Prozessor, einem Blitter zum Kopieren und Füllen zwischen Framebuffern, einem Rasterizer zum Zeichnen von Polygonen sowie einem SOC, das die Display-Aktualisierung bündelt
  • Die 128 KB SPRAM des Lattice UP5K passen zu vier 4-Bit-Framebuffern mit 320x200; dabei entspricht jeder 32-KB-SPRAM-Block einem einzelnen Framebuffer als Speicherlayout
  • Die Spieldaten sind nicht im Repository enthalten; BANK01 bis BANK0D sowie MEMLIST.BIN müssen in den Ordner GAMEDATA kopiert werden, damit Datenpaket und Bitstream verwendet werden können
  • Die Ausführung ist sowohl für Simulation als auch für echte Boards vorgesehen
    • Die Simulation kann nach Installation von Silice mit make simul1 das Intro starten
    • Hardwareseitig werden icebreaker + VGA PMOD, mch2022 badge und ULX3S HDMI unterstützt
    • Ein vorab gebauter Bitstream ist enthalten, die Spieldaten werden jedoch separat benötigt
  • Die VM-Ausführung lädt Befehle und Operanden aus dem SPI-Speicher und liest zur Verringerung der Latenz zunächst 64 Byte in einen kleinen BRAM-Cache
  • Der Grafikpfad verwendet vier Framebuffer, Double Buffering, Zugriffsbeschränkungen während vblank sowie Arbitrierung der Framebuffer-Zugriffe von Blitter und Rasterizer
  • Der Rasterizer zeichnet die konvexen Polygone von Another World als horizontale Spans und kann für Transparenzeffekte vorhandene Pixelwerte lesen und ändern oder Pixel aus einem anderen Quell-Framebuffer kopieren
  • Textrendering und einige Hintergründe aus Part 6 werden wegen des verbleibenden LUT-Budgets verarbeitet, indem vorgerenderte Pixelbuffer im ROM gespeichert und über den op_drawString-Pfad kopiert werden
  • Genannte Einschränkungen und offene Arbeiten sind fehlender Sound und fehlende Musik, separate Bitstreams und Datenpakete pro Part, noch nicht abgeschlossene Verifikation des vollständigen Gameplays, Timing-Anpassungen, die schneller als im Original sind, sowie die Suche nach einer Methode zur Verbindung der Parts
  • Lizenz: Silice-Design unter MIT License, Dokumentation unter CC BY-NC-SA 4.0, modifizierter C++-Port bleibt unter der bisherigen GPL, Spieldaten unterliegen dem Urheberrecht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-16
Meinungen auf Hacker News
  • Als Kind habe ich Out of this World auf dem Sega Genesis gespielt und dachte, Grafik könne nicht besser werden.
    Solche komplett animierten Cutscenes hatte ich auf Sega zum ersten Mal gesehen, und sie waren wirklich großartig. Natürlich ist Grafik besser geworden, aber ich finde, Another World hält sich künstlerisch auch heute noch sehr gut. Der Stil ist unverwechselbar, und als ich es vor etwa einem Jahr erneut gespielt habe, war es immer noch beeindruckend.
    Viele der Rätsel sind eher Trial-and-Error, und das Spiel ist extrem kurz, aber trotzdem würde ich nichts daran ändern wollen. Wer Another World mag, dem empfehle ich auch Flashback: The Quest for Identity. Es hat eine ähnliche filmische Atmosphäre; anfangs mochte ich es nicht besonders, aber in den letzten zehn Jahren ist es mir immer mehr ans Herz gewachsen.
    • Ich liebe Flashback wirklich. Das Cyberpunk-Setting trifft genau meinen Geschmack, die Hintergründe sind schön und die Story ist großartig.
      Trotzdem ist Another World ein Kunstwerk. Das Spieleposter sieht wie ein Ölgemälde aus und ist wirklich wunderschön [1]
      [1] http://www.anotherworld.fr/download/AnotherWorld_Poster.jpg
    • Flashback gefiel mir so gut, dass ich versucht habe, es auf Experten-Schwierigkeitsgrad durchzuspielen, bin aber ungefähr im späteren Abschnitt stecken geblieben und konnte den Slime Man nicht besiegen.
    • Die Genesis-Version kam ziemlich spät heraus. Ich habe direkt nach dem Release 1991 die Amiga-Version gespielt, und sie hat mich völlig umgehauen; so ein Spiel hatte ich vorher noch nie gesehen.
    • Ich bin auf Sega zuerst mit Flashback in Berührung gekommen und mochte es sofort. Als ich später Out of this World spielte, dauerte es etwas, bis es mich packte, aber beide sind großartige Kunstwerke.
    • Flashback stammt von Delphine Software, und auch im Detektivspiel Cruise for a Corpse wurde ein Teil derselben Polygon-Technik verwendet.
  • Weitere sehenswerte Materialien:
    cyxx’ Reverse Engineering und JavaScript-Port von Infernal Runner für den Amstrad CPC. Es ist ein Werk des Another-World-Schöpfers, und beide nutzen eine Virtual-Machine-Architektur: https://github.com/cyxx/infernal_js
    Norbert Kehrers Vortrag „The Virtual Machine Architecture of Infernal Runner“. Der Vortrag ist auf Deutsch, die Folien sind auf Englisch: https://media.ccc.de/v/vcfb20_-146-en-202010111400-_th...
    The Story of Another World on the Amiga | MVG: https://www.youtube.com/watch?v=0iz9PJbs5rE
    Nintendo-64-Port von Another World: https://github.com/jnmartin84/aw64
    PlayStation-1-Port von Another World: https://github.com/fgsfdsfgs/rawpsx
  • Falls HDL verwirrend ist: Das ist die eigene Sprache des Autors: https://github.com/sylefeb/Silice/tree/master
    Sie stellt einen Compiler bereit, der nach Verilog kompiliert; das Ergebnis kann man dann in bestehende Design-Flows einspeisen.
  • Das Intro war fantastisch. Sogar nur mit PC-Speaker, ohne Soundkarte.
    Schon als erste Handlung wegschwimmen zu müssen und danach vor einer löwenartigen Kreatur zu fliehen, gehört zu den brutalsten Spielerfahrungen aller Zeiten. Dieses Spiel bleibt einem schon nach einer Minute fürs Leben im Gedächtnis.
    • Ich glaube, ich habe es mehr als ein paar Minuten, höchstens ein paar Stunden gespielt und bin kaum vorangekommen, aber dieses Intro und die erste Flucht haben sich mir bis heute eingeprägt.
      Für damalige Verhältnisse wirkten die dramatischen Kameraeffekte dieses Spiels wirklich wie aus einer anderen Welt, ganz wie der Titel.
    • Ich habe dieses Spiel nie selbst gespielt, aber allein die zweiminütige Szene auf einer Promo-VHS-Kassette, die einem Videospielmagazin beilag, sitzt mir seit 30 Jahren im Kopf.
      Auch das Coverbild ist großartig.
    • Auch den „Dialog“ im Spiel direkt nachdem der neue Freund einen vor dem löwenartigen Ding rettet, werde ich nie vergessen.
      konanaka beetzai! motsuubo! /wave
    • Schockierend war nicht nur das Intro, sondern auch, dass das gesamte Spiel auf eine einzige Diskette passte.
    • Ich habe genau dieselbe Erinnerung, dass ich ungefähr eine Minute gespielt habe und dann festhing. 25 Jahre später habe ich es noch einmal gespielt und durchgespielt; sobald man die Reaktionsgeschwindigkeits-Hürde überwunden hat, ist es ein großartiges und unvergessliches Spiel.
  • Der ursprüngliche Entwickler von Another World hat einen GDC-Retrospektivvortrag gehalten, der zu den ziemlich guten GDC-Vorträgen gehört:
    https://www.youtube.com/watch?v=JFaOYYSxSEA
    Soweit ich mich erinnere, zeigt er auch einige der Entwicklungstools, darunter wie Animationen im Bytecode der virtuellen Maschine zeilenweise direkt bearbeitet und schrittweise ausgeführt wurden.
  • Ich frage mich, wie verbreitet virtuelle Maschinen für komplette Spiele in den 90ern waren. Das Spiel ist älter als ich; war die Performance-Einbuße durch eine Virtual-Machine-Schicht auf damaligen PCs nicht groß?
    • Viel wichtiger war, dieselbe Software auf Amiga, x86 (DOS), Mac und zahllosen weiteren Systemen zum Laufen zu bringen.
      Heute gibt es weniger Plattformen als in der explosionsartigen Wachstumsphase der 80er. Auch heute kann man den Großteil der „Software“ als JavaScript betrachten, das vom Webbrowser interpretiert wird. Auch in den 80ern gab es Portabilitätsprobleme, und damals war es sogar schwieriger, weil man den Interpreter selbst bauen musste.
      Viele, vielleicht die meisten Videospiele scheinen vor Doom beziehungsweise vor leistungsfähiger 3D-Grafik mit virtuellen Maschinen geschrieben worden zu sein. Konsolenspiele waren wegen der Performance wahrscheinlich eher in C oder Assembler geschrieben.

Damals war die Ära der „Computer“-Spiele entweder noch vor der Standardisierung auf den IBM PC, oder zumindest bevor der PC gewann und Microsoft dominierte. In einer Situation, in der unklar war, ob Amiga, PC-98, IBM PC, Mac oder etwas anderes gewinnen würde, war es sinnvoll, eine virtuelle Maschine zu bauen; SCUMM kommt einem da sofort in den Sinn.

  • Trotzdem hat man mit solchen Spezial-Virtual-Machines keine Dinge wie Elite gebaut.
    Portabilität war zwar wichtig, aber zu einer Zeit, in der Moore’s Law mit voller Kraft wirkte und Plattformen eine Lebensdauer wie Eintagsfliegen hatten, hatten virtuelle Maschinen auch einen Kompressionseffekt. Vollständig kompilierte Binaries konnten zu viel Disketten- oder Tape-Speicher sowie RAM verbrauchen.
    Eine sehr kleine virtuelle Maschine konnte dagegen eine maßgeschneiderte Sprache interpretieren, und in einer Situation, in der jedes einzelne Kilobyte zählte, sparte das erheblich Platz. Man denke nur an den Größenunterschied zwischen print "Hello world!" und einem normal kompilierten Binary. Bei einem Textadventure nützte es nichts, wenn es noch so schnell war, solange es nicht in X KB passte.
  • In der Hochphase der Assemblersprache waren virtuelle Maschinen auch bei Business-Software verbreitet. Standardkonforme C-Compiler für mehrere Systeme gab es noch nicht oder sie waren sehr teuer, daher wurde das Portieren auf unterschiedliche Systeme einfacher.
  • Der Kniff früher virtueller Maschinen wie Infocoms Z-Machine, dem interpretierten Pascal-Code von Wizardry, SCUMM, Sierra AGI und SCI, Another World, Horrorsoft-Spielen usw. lag darin, dass sie gut erkannten, dass die Spiele, die sie bauten, vor allem „Content-Auslieferungsgeräte“ waren.
    Es gab viele Text- und Grafik-Assets, während die Berechnungen vergleichsweise simpel waren. Die Constraints beim Authoring hingen mit der Hardware im Wesentlichen nur in Bezug auf Ein-/Ausgabe und Datenkompression zusammen, und der vom Interpreter ausgeführte Code bestand meist aus einmalig ausgeführter „Szeneninitialisierung“ und ein paar Animationstimern.
    Die gegenteilige Idee zeigt sich besser bei Arcade-Spielen und später bei Dingen wie Doom und Quake. Das, was das Spiel simuliert, ist viel enger mit der Hardware verbunden, und die Szenendefinition ist eher Kartendaten als Skriptlogik – etwa „platziere hier ein Monster und dort ein Health-Item“.
  • Es hängt davon ab, wie man eine „Virtual Machine für das gesamte Spiel“ betrachtet. Infocoms Adventures ließen den gesamten Spielcode in der virtuellen Maschine laufen, und bei den Grafikadventures von Sierra und LucasArts war es ebenso.
    Natürlich verwendeten die beiden Letzteren einige native Grafik-Primitivoperationen.
  • Es fühlt sich an, als würde Only Amiga makes it possible 30 Jahre später durch FPGA ersetzt.
  • Die Stelle „[Transparenz] fügt dem Rasterizer Komplexität hinzu. Um nur ein Bit [des Farbwerts] umzudrehen, muss man den vorherigen Wert des Pixels an dieser Position kennen“ ist eher einer der drei Vorteile, die man bei planarer Grafik wie auf dem Amiga bekommt.
    Mit Bitplanes muss man den Videospeicher nicht erneut lesen. Man kann annehmen, dass das höchstwertige Bit ausschließlich für Transparenzeffekte reserviert ist, und den Span einfach direkt ausgeben.
    Die beiden anderen Vorteile sind, dass man die Ebenen relativ zueinander verschieben kann, um hübsche Moiré-Effekte zu erzeugen, und dass Speicher- und Busbandbreite bei krummen Farbtiefen effizient genutzt werden, die nicht sauber in Bytes oder Nibbles passen, etwa 8 Farben (3 Bit pro Pixel) oder 32 Farben (5 Bit pro Pixel).
  • Dank dieses Threads habe ich schließlich akzeptiert, dass ich dieses Spiel wohl nie selbst lösen werde, und mir auf YouTube ein Playthrough angesehen. Es war 22 Minuten lang. Ich glaube, ich bin damals nicht weiter gekommen, als einmal an dem Löwen vorbeizukommen.