sm64

Super Mario 64

• Dieses Repo enthält eine vollständige Dekompilierung von Super Mario 64 der folgenden Versionen: Japan (jp), Nordamerika (us), Europa (eu), Shindou (sh) und iQue Player (cn).
• Die Benennung und Dokumentation des Quellcodes und der Datenstrukturen ist in Arbeit.

Es erstellt die folgenden ROMs:

• sm64.jp.z64 sha1: 8a20a5c83d6ceb0f0506cfc9fa20d8f438cafe51
• sm64.us.z64 sha1: 9bef1128717f958171a4afac3ed78ee2bb4e86ce
• sm64.eu.z64 sha1: 4ac5721683d0e0b6bbb561b58a71740845dceea9
• sm64.sh.z64 sha1: 3f319ae697533a255a1003d09202379d78d5a2e0
• sm64.cn.z64 sha1: 2e1db2780985a1f068077dc0444b685f39cd90ec

Dieses Repo enthält nicht alle Assets, die zum Kompilieren der ROMs erforderlich sind. Zum Extrahieren der Assets ist eine vorherige Kopie des Spiels erforderlich.

Schnellstart (für Ubuntu)

1. Installationsvoraussetzungen: sudo apt install -y binutils-mips-linux-gnu build-essential git pkgconf python3
2. Klonen Sie das Repo unter Linux: git clone https://github.com/n64decomp/sm64.git
3. Platzieren Sie ein Super Mario 64-ROM mit dem Namen baserom.<VERSION>.z64 im Projektordner für die Asset-Extraktion, wobei VERSION jp , us , eu , sh oder cn sein kann.
4. Führen Sie make aus, um zu erstellen. Geben Sie die Version über make VERSION=<VERSION> an. Fügen Sie -j4 hinzu, um die Build-Geschwindigkeit zu verbessern (hardwareabhängig).

Stellen Sie sicher, dass die Länge des Repo-Pfads 255 Zeichen nicht überschreitet. Lange Pfadnamen führen zu Buildfehlern.

Installation

Windows

Installieren Sie WSL und eine Distribution Ihrer Wahl gemäß dem Windows-Subsystem für Linux-Installationshandbuch für Windows 10. Wir empfehlen entweder Debian- oder Ubuntu 18.04-Linux-Distributionen unter WSL. Hinweis: WSL1 unterstützt Ubuntu 20.04 derzeit nicht.

Klonen Sie als Nächstes das SM64-Repo aus der Linux-Shell: git clone https://github.com/n64decomp/sm64.git

Befolgen Sie dann weiterhin die Anweisungen im Abschnitt zur Linux-Installation weiter unten.

Linux

Es gibt drei Schritte, um einen funktionierenden Build einzurichten.

Schritt 1: Abhängigkeiten installieren

Für das Build-System gelten die folgenden Paketanforderungen:

• binutils-mips
• pkgconf
• python3 >= 3.6

Nachfolgend finden Sie Anweisungen zur Abhängigkeitsinstallation für gängige Linux-Distributionen:

Debian / Ubuntu

So installieren Sie Build-Abhängigkeiten:

 sudo apt install -y binutils-mips-linux-gnu build-essential git pkgconf python3

Arch Linux

So installieren Sie Build-Abhängigkeiten:

 sudo pacman -S base-devel python

Installieren Sie die folgenden AUR-Pakete:

• mips64-elf-binutils (AUR)

Andere Linux-Distributionen

Die meisten modernen Linux-Distributionen sollten über gleichwertige Pakete wie die beiden anderen oben aufgeführten verfügen. Möglicherweise müssen Sie eine andere Version der GNU-Binutils verwenden. Nachfolgend sind vollständig kompatible Binutils-Distributionen mit Unterstützung im Makefile sowie Beispiele für Distributionen aufgeführt, die diese anbieten:

• mips64-elf- (Arch AUR)
• mips-linux-gnu- (Ubuntu und andere Debian-basierte Distributionen)
• mips64-linux-gnu- (RHEL/CentOS/Fedora)

Sie können Docker auch verwenden, um die Installation eines Images mit minimalen Abhängigkeiten durchzuführen.

Schritt 2: Basisrom(s) für die Asset-Extraktion kopieren

Für jede Version (jp/us/eu/sh/cn), für die Sie ein ROM erstellen möchten, legen Sie zur Asset-Extraktion ein vorhandenes ROM unter ./baserom.<VERSION>.z64 ab.

Schritt 3: Erstellen Sie das ROM

Führen Sie make , um das ROM zu erstellen (standardmäßig VERSION=us ). Weitere Beispiele:

 make VERSION=jp -j4       # build (J) version instead with 4 jobs
make VERSION=eu COMPARE=0 # build (EU) version but do not compare ROM hashes

Resultierende Artefakte finden Sie im build -Verzeichnis.

Die vollständige Liste der konfigurierbaren Variablen ist unten aufgeführt, wobei der Standardwert der zuerst aufgeführte ist:

• VERSION : jp , us , eu , sh , cn
• GRUCODE : f3d_old , f3d_new , f3dex , f3dex2 , f3dzex
• COMPARE : 1 (ROM-Hash vergleichen), 0 (ROM-Hash nicht vergleichen)
• NON_MATCHING : Verwenden Sie funktional äquivalente C-Implementierungen für Nichtübereinstimmungen. Außerdem werden Fälle undefinierten Verhaltens vermieden.
• CROSS : Cross-Compiler-Tool-Präfix (Beispiel: mips64-elf- ).

macOS

Unter macOS können Sie entweder Homebrew oder Docker verwenden.

Homebrew

Schritt 1: Abhängigkeiten installieren

Installieren Sie Homebrew und die folgenden Abhängigkeiten:

 brew update
brew install coreutils make pkg-config tehzz/n64-dev/mips64-elf-binutils

Schritt 2: Basisrom(s) für die Asset-Extraktion kopieren

Für jede Version (jp/us/eu/sh/cn), für die Sie ein ROM erstellen möchten, legen Sie zur Asset-Extraktion ein vorhandenes ROM unter ./baserom.<VERSION>.z64 ab.

Schritt 3: Erstellen Sie das ROM

Verwenden Sie das GNU-Make von Homebrew, da die in macOS enthaltene Version zu alt ist.

 gmake VERSION=jp -j4       # build (J) version instead with 4 jobs

Docker-Installation

Erstellen Sie ein Docker-Image

Erstellen Sie nach der Installation und dem Start von Docker das Docker-Image. Dies muss nur einmal durchgeführt werden.

 docker build -t sm64 .

Bauen

Zum Erstellen mounten Sie das lokale Dateisystem im Docker-Container und erstellen Sie das ROM mit docker run sm64 make .

macOS-Beispiel für (U):

 docker run --rm --mount type=bind,source="$(pwd)",destination=/sm64 sm64 make VERSION=us -j4

Linux-Beispiel für (U):

Für einen Linux-Host muss Docker angewiesen werden, welcher Benutzer die Ausgabedateien besitzen soll:

 docker run --rm --mount type=bind,source="$(pwd)",destination=/sm64 --user $UID:$GID sm64 make VERSION=us -j4

Resultierende Artefakte finden Sie im build -Verzeichnis.

Projektstruktur

 sm64
├── actors: object behaviors, geo layout, and display lists
├── asm: handwritten assembly code, rom header
│   └── non_matchings: asm for non-matching sections
├── assets: animation and demo data
│   ├── anims: animation data
│   └── demos: demo data
├── bin: C files for ordering display lists and textures
├── build: output directory
├── data: behavior scripts, misc. data
├── doxygen: documentation infrastructure
├── enhancements: example source modifications
├── include: header files
├── levels: level scripts, geo layout, and display lists
├── lib: SDK library code
├── rsp: audio and Fast3D RSP assembly code
├── sound: sequences, sound samples, and sound banks
├── src: C source code for game
│   ├── audio: audio code
│   ├── buffers: stacks, heaps, and task buffers
│   ├── engine: script processing engines and utils
│   ├── game: behaviors and rest of game source
│   ├── goddard: Mario intro screen
│   └── menu: title screen and file, act, and debug level selection menus
├── text: dialog, level names, act names
├── textures: skybox and generic texture data
└── tools: build tools

Mitwirken

Pull-Anfragen sind willkommen. Bei größeren Änderungen öffnen Sie bitte zunächst ein Problem, um zu besprechen, was Sie ändern möchten.

Führen Sie clang-format für Ihren Code aus, um sicherzustellen, dass er den Codierungsstandards des Projekts entspricht.

Offizieller Discord: discord.gg/DuYH3Fh