Die PS1-Portversion von Super Mario 64

 (github.com/malucard)
1 Punkte von GN⁺ 2025-12-12 | 1 Kommentare | Auf WhatsApp teilen
  • Basierend auf dem Super Mario 64 Decompilation Project für Nintendo 64, eine auf PlayStation (PSX) portierte Version
  • Enthält umfangreiche Anpassungen für PS1-Hardware wie DualShock-Vibrationsunterstützung, Umstellung auf Festkomma-Mathematik und Rendering-Optimierungen
  • Leistungsverbesserungen durch Grafikpräprozessor, Texturkompression und Optimierung des Animationsspeichers wurden ergänzt
  • Mehrere bekannte Fehler sind vorhanden, darunter eine unvollständige Kamerasteuerung, Kollision- und Absturzfehler sowie ein nicht mögliches Musik-Build
  • Ein plattformübergreifendes Portierungsexperiment eines Klassikers, das als relevantes Beispiel für die Entwicklung auf Legacy-Konsolen und Reverse-Engineering-Forschung gilt

Projektübersicht

  • Dieser Code ist ein Fork der vollständigen dekompilierten Super Mario 64 (J/U/E/SH)-Version und ist nur für PSX und PC (Debugging) gedacht.
    • Der Nintendo-64-Build wird nicht mehr unterstützt.
    • Derzeit kann nur ein US-ROM gebaut werden.
  • Der Spiel-Build enthält keine Original-Assets, daher ist ein Extrahieren der Assets aus einem gültigen ROM erforderlich.

Hauptfunktionen

  • DualShock™-Kompatibilitätsgrafik wurde hinzugefügt und imitiert die originale Anzeige „Rumble Pak Compatible“.
  • Unterstützt sowohl analoge Vibrationssignale für den großen DualShock-Motor als auch digitale Signale für den kleinen Motor.
  • PSX-Implementierung für Low-Precision-Soft-Float senkt den Performance-Verlust bei Fließkomma-Berechnungen.
  • Festkomma-Mathematik ersetzt Teile des Codes; 16-Bit-Integer-Vektoren und -Matrizen nach PSX-Standard.
  • Render-Graph-Worker vereinfacht und neu geschrieben.
  • Polygon-Splitting (bis zum 2-fachen) reduziert Probleme bei großen Polygonen.
  • RSP-Displaylisten werden in ein JIT-basiertes eigenes Format konvertiert, um die Verarbeitungsrate zu steigern.
  • Ein Displaylisten-Präprozessor entfernt unnötige Befehle und optimiert Meshes.
  • Mario-Animationskompression (580,632 → 190,324 Bytes) und direkte Platzierung im VRAM.
  • Eigenen Profiler und 4bpp-Textur-Encoder hinzugefügt.
  • Aufgrund der Transparenzgrenzen der PSX wurden hexagonale Schatten eingesetzt.
  • (Geplant) Kameradrehung mit dem rechten Analogstick und eine Überarbeitung des Goddard-Subsystems.

Bekannte Probleme

  • Schwebende Bäume, manche Animationen funktionieren nicht oder stürzen ab
  • Musik-Build nicht möglich, Soundeffekte fehlen oder klingen fehlerhaft
  • unvollständige Kamerasteuerung, Abstürze beim Betreten bestimmter Levels
  • Laden der Endsequenz schlägt fehl, Lakitu taucht nicht auf, Pol funktioniert nicht
  • lange Ladezeiten durch einzelnes Laden von Texturen, Texturverzerrungen aufgrund von PSX-Limits
  • Verbesserung des Grafikpräprozessors erforderlich, einige Textur-Rendering-Fehler, nicht vollständiger Titelbildschirm, Pause-Menü funktioniert nicht

Build-Methode

Linux

  • Toolchain mipsel-none-elf-gcc installieren und das Repository klonen
  • Datei baserom.us.z64 im Stammverzeichnis ablegen
  • (Optional) Soundtrack-.wav-Dateien (0~37) im .local-Ordner hinzufügen
  • make ausführen, um ein ISO-Image zu erzeugen (build/us_psx/sm64.us.iso)
  • Die Benchmark-Version (make BENCH=1) erzeugt ohne ISO nur ELF/EXE und benötigt eine 8 MB RAM PSX

Windows (nicht verifiziert)

  • Nach Installation von MSYS2 die mingw-w64-Pakete einrichten
  • mipsel-none-elf-gcc installieren und das sm64-psx-Repository klonen
  • baserom.us.z64 ablegen und make ausführen
  • Das Build-Ergebnis wird im selben Pfad wie unter Linux erzeugt

Fehlerbehebung

  • Bei nicht erkanntem gcc prüfen, ob die falsche MSYS2-Umgebung ausgeführt wird
  • Bei fehlendem baserom.us.z64 den Dateistandort überprüfen
  • Bei nicht gefundenem Makefile den Verzeichnispfad prüfen
  • Bei Paketfehlern mit pacman -Syu und pacman -Su aktualisieren
  • Die Funktionsfähigkeit von mipsel-gcc prüfen mit mipsel-none-elf-gcc -v
  • Beim Plattformwechsel make -C tools clean ausführen, um Tools neu zu kompilieren

Projektstruktur

  • actors: Objektverhalten, Geo-Layout, Displaylisten
  • assets: Animations- und Demodaten
  • src: Kern-C-Quelle des Spiels (Audio, Engine, Spielablauf, Menü, Portierung usw.)
  • textures, text, levels: Grafik- und Level-Daten
  • tools: Build-Tools
  • lib: enthält N64-SDK-Code

Beiträge

  • Pull Requests sind willkommen.
  • Vor größeren Änderungen empfiehlt sich die Erstellung und Diskussion eines Issues.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-12
Hacker-News-Kommentare

  • Wenn dir dieser Port gefällt, dürfte auch das vollständig neu implementierte SM64-Projekt für den GBA interessant sein
    YouTube-Video ansehen

    • Da wir hier auf HN sind, muss das unbedingt erwähnt werden. Dieser GBA-Port wurde in Rust geschrieben
      Zugehöriger Artikel: The Impossible Port – Super Mario 64 on the Game Boy Advance
    • Interessant. Ich frage mich, ob der GBA eine abgespeckte Minecraft-artige Version stemmen könnte
      Das würde auch gut zum N64 passen, und ich würde mir irgendwann gern ein SummerCart64 besorgen und damit experimentieren
    • Weiß zufällig jemand, wo der Quellcode dieses Projekts ist? Er scheint gelöscht worden zu sein
    • Cool ist es auf jeden Fall, aber persönlich fällt mir das Anschauen etwas schwer
      Trotzdem ist es wirklich beeindruckend, dass es bis zur Fertigstellung gebracht wurde

  • Wirklich eine erstaunliche Leistung
    Ich hatte früher beide Konsolen, und dieser Port zeigt mir nochmal, wie gut das N64 1996 dieses „SGI-im-Wohnzimmer“-Gefühl eingefangen hat
    Der Eindruck, als ich Mario 64 zum ersten Mal auf einem japanischen Import-N64 gesehen habe, ist mir noch immer lebhaft in Erinnerung
    Das ruft auch die vielfältige Spielelandschaft jener Zeit in Erinnerung, in der sich Spiele wie Wipeout auf der PSX in eine andere Richtung entwickelten

  • Es heißt, mit „Tessellation (max. 2x)“ werde das Problem großer Polygone reduziert, aber im Video ist die Texturverzerrung immer noch stark sichtbar
    Vielleicht reichen 2x nicht aus, oder man müsste die Level-Geometrie neu bauen

    • Ich sehe die Texturverzerrung auch, aber nicht das für PS1-Spiele typische Geometrie-Wackeln
      Vermutlich werden Gleitkommaoperationen per Software verarbeitet, daher wäre perspective-correct mapping wahrscheinlich zu belastend für die Framerate
    • Derzeit gibt es bei den Level-Polygonen fast keine Vorverarbeitung
      Wenn das später implementiert wird, sollen große Polygone aufgeteilt werden, um auch die Beschränkungen bei den Texturkoordinaten zu lösen
    • In den bekannten Problemen steht auch ausdrücklich, dass „die Tessellation nicht ausreicht“
      Das raue Gefühl früher 3D-Grafik ist aus der PS1-Ära also weiterhin vorhanden

  • Ich frage mich, ob es irgendwo ein Laufvideo oder Screenshots gibt. Ich verstehe allerdings, warum auf GitHub nichts davon ist

    • Ich habe gestern Abend ein ordentliches Gameplay-Video dazu gesehen
      YouTube-Link
    • Es gibt auch noch ein weiteres Video
      YouTube-Link

  • Viele beschweren sich über die Texturverzerrung, aber trotzdem ist das hier wirklich eine erstaunliche Arbeit

  • Kaze darf man hier nicht unerwähnt lassen
    Er optimiert Mario 64 seit Jahren auf verschiedenste Weise, und wenn man sich für die Schnittstelle zwischen Retro-Gaming und Programmierung interessiert, ist das absolut sehenswert
    Kazes YouTube-Kanal

    • In einem im August hochgeladenen Video hat er analysiert, wie viel RAM Mario 64 verschwendet, und dort erstmals die Möglichkeit eines PS1-Ports erwähnt
      Ich hätte nicht gedacht, dass das so schnell Realität wird
      Zugehöriges Video ansehen
    • Er ist wirklich beeindruckend (und muskulös)
      Wenn es auf der PS1 jemanden mit Kazes Wissensstand gäbe, wäre vielleicht sogar ein Projekt wie Mario 32 möglich

  • In letzter Zeit explodiert die Zahl der Decompilation-Projekte regelrecht, und ich frage mich, warum

    • Der Hauptgrund ist wohl der Fortschritt bei Tooling, das 1:1 bytegenaues Decompiling unterstützt
      Ein typisches Beispiel ist decomp.me
      Solche Tools ermöglichen es, Code zu rekonstruieren, der exakt mit dem bestehenden Binärformat übereinstimmt, wodurch neue Projekte schnell anlaufen können
      Auch das Aufkommen von Porting-Layern, die Konsolen-SDK-APIs nachbilden, hat dazu beigetragen
      Für perfekte Übereinstimmung muss man allerdings enorme Arbeit investieren, etwa um das unnormale Verhalten alter Toolchains nachzubilden
    • Vielleicht liegt es auch daran, dass KI das Decompiling einfacher gemacht hat
    • Vielleicht ist einfach KI der Grund
    • Dass mehr Leute Ghidra nutzen, dürfte ebenfalls eine Rolle spielen

  • Kürzlich ist auch ein Dreamcast-Port erschienen, und Star Fox 64 sowie Mario Kart 64 wurden ebenfalls auf verschiedene Plattformen portiert
    Zugehörige Liste: awesome-game-decompilations

    • Der Star-Fox-64-Port wurde auch gerade erst fertiggestellt

  • Schade, dass es keine Screenshots gibt

  • „Endlich, Super Mario 32“