Fast alle Nintendo-64-Spiele lassen sich zu nativen PC-Ports rekompilieren
(tomshardware.com)- Nintendo-64-Spiele aus dem Jahr 1996 können statt per Emulation zu nativen PC-Ports rekompiliert werden, sodass Verbesserungen wie Raytracing, Ultrawide und hohe FPS möglich werden
- Die zentralen Tools sind N64Recomp und Zelda64Recomp, die Mr-Wiseguy auf GitHub veröffentlicht hat; Zelda64Recomp portiert The Legend of Zelda: Majora's Mask auf den PC
- Dieser Ansatz unterscheidet sich vom 2020 veröffentlichten, vollständig auf Dekompilierung basierenden PC-Port von Super Mario 64, beide laufen jedoch nativ auf dem PC und können Leistung sowie Genauigkeit von Effekten verbessern
- Während eine manuelle Dekompilierung erfordert, dass eine oder mehrere Personen jahrelang daran arbeiten, verfolgt N64Recomp den Ansatz, N64-Spiele schneller in eine auf dem PC lauffähige Form zu bringen
- Das Ergebnis enthält keine Assets, zum Spielen ist daher eine ROM erforderlich; Banjo-Kazooie, Rocket Robot und Superman 64 werden ebenfalls als lauffähige Beispiele genannt
Wandel bei der Portierung von N64-Spielen
- Auch 2024 stoßen die Originalhardware und Spiele des Nintendo 64 in der Enthusiasten-Community weiterhin auf großes Interesse
- Die nächste Stufe des High-End-N64-Spielens könnte mit hoher Wahrscheinlichkeit nicht Emulation, sondern rekompilierte PC-Ports sein
- Mr-Wiseguy auf GitHub hat N64Recomp und Zelda64Recomp veröffentlicht
- N64Recomp ist ein grundlegendes Tool, um aus N64-Spielen native PC-Ports zu erstellen
- Zelda64Recomp portiert The Legend of Zelda: Majora's Mask auf den PC und wendet die Grafik- und Komfortverbesserungen von N64Recomp an
Mögliche Verbesserungen in PC-Ports
- Rekompilierte PC-Ports können die ursprünglichen N64-Spiele um Verbesserungen der PC-Umgebung erweitern
-
Echtes Raytracing
- Aufhebung der Framerate-Begrenzung
- Angemessene Ultrawide-Unterstützung
- Grafik- und Komfortverbesserungen, die man am PC erwartet
- Majora's Mask wird als Vergleichsbeispiel für Ultrawide-Ausführung per Emulation und per nativer PC-Rekompilierung behandelt
-
Unterschied zum PC-Port von Super Mario 64
- Der 2020 veröffentlichte, vollständig auf Dekompilierung basierende PC-Port von Super Mario 64 ermöglichte Funktionen wie Raytracing und den vollständigen Austausch von Modellen; Mods werden bis heute weiterentwickelt
- Rekompilierte Ports unterscheiden sich in der Herstellungsweise von dekompilierten Ports wie dem SM64-PC-Port
- Beide Ansätze laufen nativ auf dem PC und können gegenüber der Originalhardware Leistung und Genauigkeit von Effekten verbessern, während sie PC-typische Verbesserungen bieten, die man von Emulation erwartet
Warum N64Recomp wichtig ist
- N64Recomp ist ein Tool, das mit dem Rekompilierungsansatz die Vorteile von Emulation und nativen Ports zugleich anstrebt
- Um N64-Spiele manuell zu dekompilieren, müssten eine oder mehrere Personen jahrelang daran arbeiten
- Ein Tool, das N64-Spiele effizienter und schnell in einen auf dem PC ausführbaren Zustand bringt, kann auch für Bewahrer digitaler Spiele nützlich sein
RT64 und Ausführungsbeispiele
- Dario ist der Entwickler des RT64-Plugins, das in N64Recomp und einigen N64-Emulatoren genutzt wird
- Laut Darios Beitrag arbeitete Wiseguy ein Jahr lang im Verborgenen an einem Tool, das PC-Ports von N64-Spielen ohne vollständige Dekompilierung erstellt
- Das Ergebnis enthält keine Assets; zum Spielen wird lediglich eine ROM benötigt
- Als Ausführungsbeispiele werden folgende Spiele genannt
- Banjo-Kazooie
- Rocket Robot
- Superman 64
Weitere Entwicklungen im N64-Ökosystem
- Auch für Fans der N64-Bibliothek und der Originalhardware gibt es weitere Fortschritte
- Die Open-Source-SummerCart64 ist eine Flash-Cart für bestehende Konsolen und implementiert auch 64DD-Unterstützung
- Homebrew-N64-Spiele und ROM-Hacks, die mit echter Hardware kompatibel sind, erscheinen weiterhin
- Smash Remix mit 30 Kämpfern
- Peach's Fury, ein Projekt zur Neuschreibung der Mario-64-Engine
2 Kommentare
Hacker-News-Kommentare
Um dieses Tool zu verwenden, muss man die ROMs offenbar immer noch zuerst disassemblieren und dann umfangreich annotieren, damit sie sich erneut kompilieren lassen
Das Tool selbst ist großartig, aber die Übertreibung, dass sich beliebige ROMs fast per One-Click in eigenständige ausführbare Dateien verwandeln lassen, wirkt überzogen
Im Video zum Beitrag wurde ein namenloses N64-Spiel recompiled und lief problemlos, und zusätzliche Annotationen schienen nicht nötig zu sein
Eine ROM ist schließlich wörtlich Read-Only, also sollte ein Ablauf möglich sein, bei dem man die ROM eingibt und einen nativen Port erhält
Eine Binär-zu-Binär-Umwandlung wirkt intuitiver, und menschliche Eingaben sollten dafür doch eigentlich nicht nötig sein
Wirklich großartig
Verschiedene Basis-Tools, die für N64-Decompilation entwickelt wurden, breiten sich inzwischen auf Decompilation-Pakete für andere Systeme aus
https://decomp.me/ unterstützt, soweit ich kürzlich gesehen habe, kollaborative Decompilation für mehrere Systeme mit den jeweiligen SDKs und Hardware-Presets
Ich glaube, dass wir in den nächsten Jahren noch mehr solcher Entwicklungen für weitere Systeme sehen werden
Ich habe das gesehen, als es herauskam, und als jemand, der die ROM-Hacking-Szene nicht verfolgt, frage ich mich, warum so ein Ansatz erst so spät aufkam
Assembler-Instruktionen in C zu übersetzen und dann neu zu kompilieren wirkt wie ein naheliegender früher Versuch, deshalb frage ich mich, ob das vorher unmöglich war und ob es inzwischen andere Durchbrüche gab, die es erst jetzt machbar machen
Beim Überfliegen des GitHub-Repositorys sah es so aus, als würde intern rt64 für Raytracing-Unterstützung verwendet (https://github.com/rt64/rt64)
rt64 nutzt Ubershader, um die GPU zu emulieren, und dieser hervorragende Artikel erklärt, was Ubershader sind, warum sie nötig sind und wie verrückt das alles ist: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
Statische Rekompilation von einer Maschinensprache in eine andere Sprache ist in der Praxis entweder sehr schwierig oder allgemein unmöglich [1]
Damit so eine Rekompilation sauber funktioniert, braucht man auch Unterstützung von der Binärseite, die die Rekompilation erleichtert [2], und zusätzlich Patches, damit das Ergebnis tatsächlich läuft [3]
Dynamische Rekompilation hat diese Probleme nicht, daher kann man mit der ursprünglichen Binärdatei und den Assets, also der ROM, im Allgemeinen eine emulierte Version der Software erstellen
Es gibt viel Verwirrung darüber, wie allgemein diese Lösung tatsächlich ist
Im Sinne der Arbeitsersparnis, die Rekompilationen oder Ports deutlich einfacher macht, ist sie sehr beeindruckend und wertvoll, aber sie ersetzt nicht die Notwendigkeit klassischer Emulatoren
[1]: https://cs.stackexchange.com/questions/155511/why-is-static-...
[2]: N64-Spiel-Binärdateien vermeiden zufällig mehrere Eigenschaften, die allgemeine statische Rekompilation erschweren, was diesem Ansatz helfen könnte, aber genau weiß ich es nicht
[3]: Das Rekompilations-Repository von Majora's Mask enthält viele von Hand erstellte Patches, damit es funktioniert: https://github.com/Mr-Wiseguy/Zelda64Recomp
Jamulator hat das bereits 2013 für das NES gemacht, aber es scheint, als hätte das kaum jemanden interessiert.
https://andrewkelley.me/post/jamulator.html
Es gibt auch Winlator, um Windows-Programme auf Android auszuführen.
https://github.com/brunodev85/winlator
Und verwendet das im Artikel verlinkte YouTube-Video eine KI-Stimme?
Im N64Recomp-GitHub-Repository[0] steht Folgendes:
"This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
[0]: https://github.com/Mr-Wiseguy/N64Recomp
In so einer Situation macht Recompilierung die Sache nur komplizierter, ohne viel Nutzen zu bringen.
Das N64 hat feste Hardware und ist daher etwas einfacher.
Trotzdem nutzt dieses Projekt für den RDP weiterhin Emulation.
Ich weiß nicht, wie mit generiertem RSP-Mikrocode umgegangen wird, vielleicht auch gar nicht.
Viele Spiele haben einfach die offizielle Bibliothek verwendet.
Wäre Jamulator mit ähnlichen Verbesserungen für Zelda erschienen, wäre es viel populärer geworden.
Das Interesse scheint heute weniger an der Methode selbst zu hängen als daran, was man jetzt damit machen kann.
Die Erzählerstimme im Video ist einfach Nerrel, also ein echter Mensch.
Es ist auf interessante Weise ziemlich erstaunlich, dass KI-Stimmen inzwischen so gut sind, dass wir Menschen, die nicht so sprechen, wie wir es erwarten, für KI halten.
Die Erzählweise klang schon immer so flach, dass sie wie KI wirkte, und ich mag, wie sich das mit dem Humor mischt.
Es wäre schön, wenn alle Spiel-Binärdateien betriebssystemunabhängig wären, ähnlich wie WebAssembly.
So etwas wie GameAssembly zum Beispiel.
Auf neueren macOS-Versionen kann man jetzt keine 32-Bit-Spiele mehr spielen, und in Wine laufen 32-Bit-Windows-Spiele ebenfalls nicht.
Es ist fast unmöglich, 64-Bit-
.exe-Dateien zu finden, die unter Wine/Crossover ordentlich laufen.Bei Konsolen hängen besonders ältere Titel und Plattform-Exklusivtitel oft von sehr niedrigen GPU-Implementierungsdetails ab.
Ältere Konsolen hatten zusätzlich noch dedizierte Chips, die mehr als nur einfache Ein-/Ausgabe erledigten.
Der Soundchip des SNES war zum Beispiel eine vollständig separate CPU, die parallel zu CPU und GPU ihr eigenes kleines Programm ausführte.
Natürlich könnte man für alle künftigen Spieleentwicklungen eine High-Level-VM vorschreiben, aber wenn man bedenkt, dass die Konsolenhardware fest spezifiziert ist, wäre das für Titel, die moderne Grafik maximal ausreizen wollen, wohl nicht konkurrenzfähig.
Unter Debian musste ich Folgendes ausführen:
dpkg --add-architecture i386 && apt-get updateDanach installiert man einfach das Paket
wine32.Spiele brauchen viele verschiedene APIs: Grafik-API, Fenster-API, Eingabe-API, Sound-API, Datenträger-API und mehr.
Manchmal werden wegen Anti-Cheat oder Kopierschutz sogar Kernel-Module benötigt.
Schade ist, dass Open-Source-Betriebssysteme offenbar nicht versuchen, einen gemeinsamen API-Satz bereitzustellen, sodass Entwickler den Code einmal schreiben und testen und er dann überall läuft.
Es gibt zwar Flatpak, aber meinem Verständnis nach stellt es keinen API-Satz bereit, sondern verpackt eher eine Linux-Distribution ohne Spezifikation oder Dokumentation in einer virtuellen Maschine.
Das ist unschön und bietet auch keine Kompatibilität mit kleinen Nicht-Linux-Betriebssystemen.
Ich habe GTA IV auf einem M1 mini gespielt.
Es scheint, als gäbe es in der 32-Bit-Wine-Version, die PlayOnMac installiert, eine Art „32 auf 64“-Emulation, aber danach zu suchen ist so mühsam, dass ich nicht weiß, wie es tatsächlich funktioniert.
Es ist lustig, dass Macs mit alten Windows-Programmen kompatibler sind als mit alten Mac-Programmen.
Ohne die JVM würde ich bezweifeln, dass Minecraft Linux oder BSD-artige Systeme unterstützt hätte.
Die nicht auf der JVM basierende Bedrock Edition unterstützt Windows, Konsolen und Smartphones, aber macOS nicht, obwohl das offensichtlich möglich wäre.
Hoffentlich läuft das am Ende auch unter Linux, sodass man N64-Spiele auf sehr leistungsschwachen Handhelds stabil spielen kann.
Der N64 ist berüchtigt dafür, schwer zu emulieren zu sein, aber wenn man für die Plattform einen nativen Build erstellt, verschwinden die Performance-Probleme.
Ein Beispiel gibt es hier: https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
Ich kenne die Details der N64-Emulation nicht gut, aber ich lasse seit den frühen 2010ern N64-Emulatoren problemlos laufen.
Ich habe allerdings meist nur die großen Klassiker gespielt, daher weiß ich nicht, wie es bei eher nischigen Titeln mit der Performance aussieht.
Habe etwa eine Stunde gespielt und keine Probleme gehabt.
Habe es selbst getestet.
Für Spiele wie GoldenEye könnte das ziemlich nützlich sein.
Es setzt diese seltsame Joystick-Eingabe voraus und ist deshalb auf dem PC schwer zu spielen, daher wäre ein nativer GoldenEye-Port mit normalem Mausverhalten wie bei anderen FPS ziemlich cool.
Die Art des Moduswechsels beim Zielen und die Zeit, die der Cursor zum Bewegen und dann zum Zurückkehren in die Mitte braucht, sind ein interessanter Teil des Spielgefühls.
Wenn man wie in einem PC-FPS beim Laufen frei zielen könnte, würde das die Kampagne wohl eher kaputtmachen, weil sie auf anderen Annahmen basiert.
Gerade der Reiz liegt darin, auszuwählen, wo man stehenbleibt, um zu zielen, und beim Zielen die Ruhe zu bewahren.
Wenn man den Moduswechsel aber beibehielte und die Maus 1) Bond wie der Stick nach links und rechts drehen würde und 2) nur bei gedrücktem R im "Zielmodus" den Cursor steuern würde, könnte es Spaß machen.
Ehrlich gesagt finde ich es schade, dass Shooter so schnell alle direkt zu freiem Zielen im Quake-Stil mit WASD+Maus übergegangen sind.
Der Moduswechsel gibt GoldenEye ein physisches Gefühl, das ich daran mag.
https://github.com/Graslu/1964GEPD/releases/tag/latest
Auch mit Perfect Dark.
Ziemlich interessant, aber ich frage mich, ob das zu einer Conker-Version führen könnte, die auf MiSTer richtig läuft.
Könnte man das zum Beispiel als Hilfe bei der Dekompilierung nutzen und könnte dann jemand eine modifizierte Version erstellen?
Ich frage mich, was der Vorteil gegenüber einem Emulator ist.
Ist das am Ende nicht einfach ein Emulator in Form einer vorab übersetzten Version?
Solche Ansätze gab es früher schon mit Dingen wie Bleem, und sie können zwar Performance-Vorteile haben, aber auf modernen PCs läuft ein guter Emulator normalerweise ohnehin gut.
https://en.wikipedia.org/wiki/Bleem!
Das Ziel eines N64-Emulators ist normalerweise, das Verhalten der Originalkonsole möglichst genau nachzubilden.
Andererseits gibt es viele Leute, die SM64, OOT und MM mit 60fps, Widescreen, Texturpaketen, Randomizern und anderen grafischen Verbesserungen spielen wollen.
Für diese Leute ist es im Grunde nicht wichtig, dass diese Spiele ursprünglich auf dem N64 liefen.
Eher im Gegenteil:
Es ist fast ein Hindernis.
Die Grafik-Pipeline des N64 ist mühsam zu emulieren und steht modernen Verbesserungen aktiv im Weg.
Dieses Projekt scheint stärker darauf ausgerichtet zu sein, die Spiele selbst modern zu behandeln und N64-spezifische Elemente ganz aus der Gleichung zu entfernen.
Inzwischen sind Computer allerdings so viel schneller als ein N64, dass der Unterschied vielleicht gar nicht mehr auffällt.
Kompilieren übliche Emulatoren im Voraus, oder nutzen sie JIT?
Falls nicht, warum nicht?
Dieser Ansatz, also Vorkompilierung, scheint große Vorteile zu haben.
Aber sofern TeknoParrot nicht so funktioniert, weiß ich nicht viel über Vorab-Übersetzung.
Mit TeknoParrot kann man zum Beispiel Linux-Arcade-Spiele mit ELF-Binaries unter Windows ausführen, aber da die Architektur gleich ist, würde ich das in keinem Fall Emulation nennen.
Dabei schreibt man eine virtuelle Maschine, die verschiedene Teile des Zustands der emulierten Hardware repräsentiert, und führt Instruktionen aus, die diesen Zustand mit unterschiedlichem Genauigkeitsgrad verändern.
Was Fans alles draufhaben! Über Emulatoren mit JIT-Compiler hinaus geht es jetzt sogar so weit, per Binary Lifting nach C zu konvertieren und anschließend neu zu kompilieren