realskyrin/ns-game-apple-arm-port

NS-Spiele auf Apple ARM nativ portieren

Ziel: Der ursprüngliche Spielcode erzeugt auf dem Zielgerät sichtbare, bedienbare und speicherbare Ergebnisse. Da die CPU ebenfalls ARM64 ist, reduziert sich der Aufwand für die Befehlsumsetzung, aber die Kompatibilitätsschicht für OS-ABI, Speicher, Threads, Grafik, Audio und Eingabe darf nicht übersprungen werden.

Sprach- und Architekturanforderungen

• Neue Portierungskerne müssen in Rust (.rs) geschrieben werden. Ein Cargo-Workspace trennt Ressourcenanalyse, gemeinsame ABI, Offline-Umschreibung, Shader-Konvertierung und Host-Runtime. Bestehende Rust-Projekte werden direkt weiterverwendet; vorhandene C/C++-Native-Module werden über klare FFI-Grenzen angebunden – es werden keine bereits validierten Module umgeschrieben, nur um eine einheitliche Sprache zu erreichen. Wenn der Benutzer explizit einen anderen Technologie-Stack vorgibt, wird dies befolgt und dokumentiert.
• Swift wird für Launcher und Apple-Plattform-UI verwendet; Objective-C/Objective-C++, C/C++ für notwendige Systembrücken oder vorhandene native Bibliotheken; AArch64-Assembler ist auf Einsprungpunkte, Registerrettung und Aufruf-Trampoline beschränkt; Metal Shading Language (MSL) für GPU-Programme. Python/Bash orchestrieren nur die Ressourcenvorbereitung, den Build, die Signierung und die Diagnose – sie tragen keine Frame-für-Frame-Wiedergabe oder heiße Ausführungspfade des Gasts.
• Der Ablauf ist: Lokale Ressourcenanalyse → AArch64-Offline-Umschreibung → Native Ausführung des Original-Spielmaschinencodes → Horizon/SDK-Kompatibilität → NVN-Befehlsaufzeichnung und Metal-Wiedergabe. Die ursprüngliche Spiellogik bleibt erhalten; das Umschreiben von Spielmechaniken, Host-Demobildschirmen oder reiner API-Stubs ersetzt nicht die Portierung.
• Bevor mit der Implementierung oder der Wiederverwendung spielübergreifender Komponenten begonnen wird, ist architecture-and-workflow.md zu lesen, um Modulgrenzen, Spielversionskonfiguration und den kürzesten vertikalen Validierungspfad zu bestimmen. Diese Referenz ist aus der tatsächlichen Rust/Cargo-Portierungsstruktur abgeleitet und setzt nicht voraus, dass das Originalprojekt auf dem lokalen Rechner vorhanden ist.

Start der Arbeit

1. Das Ziel-Repository im vom Benutzer angegebenen Verzeichnis oder im aktuellen Arbeitsbereich lokalisieren. Referenz-Repositories werden nur gelesen, wenn sie vom Benutzer bereitgestellt oder im aktuellen Arbeitsbereich auffindbar sind – es werden keine Pfade auf dem Entwickler-Rechner angenommen. Die Repository-Beschreibung, lokale AGENTS.md, Git-Status, Build-Einstiegspunkte und die neuesten Validierungsaufzeichnungen lesen. Zuerst klären, ob der Benutzer implementieren, diagnostizieren oder nur bewerten möchte; Bewertungsaufgaben bleiben schreibgeschützt.
2. Eine Eingabematrix erstellen: Spiel/Title-ID, Basis/Update/DLC, angezeigte Version, NPDM-Architektur, tatsächliche NSO-Modul-Build-IDs, Ziel-OS/Chip, Quellcode-Version, Ausführungsmethode. Die tatsächlich extrahierten Module sind maßgeblich – es wird nicht allein anhand von Dateinamen oder Spielnamen auf AArch64 geschlossen.
3. Den festgelegten Ablauf beibehalten. Wenn bereits eine native Kompatibilitätsschicht existiert, werden Extraktion, Umschreibung, Host und Metal-Architektur wiederverwendet und Modul für Modul verglichen. Adress-Patches aus anderen Spielen werden nicht blind übernommen. Bei neuen Projekten wird zuerst geprüft, ob eine wiederverwendbare Kompatibilitätsschicht existiert, bevor der Aufwand abgeschätzt wird. AArch32-Eingaben sind für diesen AArch64-Direktausführungspfad nicht geeignet; es wird nach einer passenden Version gesucht, die der Benutzer besitzt, oder ein anderer Ausführungspfad wird explizit festgelegt.
4. Zuerst einen reproduzierbaren, kürzesten Abnahmepfad wählen: Start → Titel/Menü → Szene → Interaktion → Normaler Exit → Neuer Prozess lädt Spielstand. Schrittweise eine tatsächliche Blockade beheben und mithilfe von Logs, Code und Bildschirmdarstellung die Ursache bestätigen.

Referenzen nach Problem lesen

• Codeladung, Patches, Horizon-ABI, Threading und Plattformbereitstellung: runtime-and-platforms.md lesen.
• Schwarzer Bildschirm, verpixelte Darstellung, abnormale Boden-/Wasserfarben, Shader- oder Leistungsprobleme: graphics-and-debugging.md lesen.
• Abnahme, Fortschrittsbewertung, Retrospektive und Übergabe: validation-and-cases.md lesen. Enthält übertragbare Fälle und Beweisgrenzen.

Implementierungszyklus

• Zuerst die Fehlerschicht dokumentieren: Extraktion/Identifikation → Befehlsänderung → Laden/Relokation → SDK/Dienste → Befehlsaufzeichnung → Metal-Wiedergabe/Submission → Tatsächliches Fenster → Spielverhalten.
• Pro Runde eine falsifizierbare Hypothese verwenden, minimal notwendige Beweise sammeln und dann eine lokale Korrektur durchführen. Diagnoseschalter sind standardmäßig ausgeschaltet und haben Begrenzungen für Anzahl/Größe; Ausnahmen müssen die relative Position des Moduls, die Anfrage- oder Ressourceninformationen enthalten, dürfen jedoch keine Schlüssel preisgeben.
• Geeignete Validierung für semantische Korrekturen auf niedriger Ebene wählen: Befehlsäquivalenz, ABI-Layout, Nebenläufigkeit, echtes GPU-Rücklesen. Nach statischer Überprüfung und Build das eigentliche Spiel im genehmigten Umfang ausführen; wenn der Benutzer Tests verbietet, wird nur festgehalten, dass noch nicht validiert wurde – es wird nicht eigenmächtig ausgeführt.
• Quellcode, Build, Installationspaket, Ausführungs-ID, Logs und Screenshots einer Version müssen miteinander verknüpfbar sein. Neue Builds dürfen nicht mit Logs von alten Geräten als erfolgreich belegt werden.
• Diagnostische Gegenbeispiele aufbewahren und aktuelle Schlussfolgerungen aktualisieren. Frame-Captures/Single-Stepping können das Timing ändern; nach der Korrektur mit einem neuen Prozess und deaktiviertem Diagnose-Schalter erneut testen. Keine Ad-hoc-Änderungen an Rollenhöhe, Wasserfarbe, Kollision oder Spiel-Fortschritt vornehmen, um oberflächliche Anomalien zu beseitigen.
• Unbekannte Dienste, Befehle oder Formate mit eindeutigen Fehlermeldungen versehen; semantische Degradierung wird nur implementiert, wenn der Aufrufer eine Degradierung nachweislich zulässt. Es wird nicht pauschal ein Erfolg zurückgegeben, um nicht implementierte Funktionen zu verschleiern.

Ressourcen und Liefergegenstände

• Quellpakete, Schlüssel und Firmware bleiben lokal; Schlüsselwerte werden nicht in Befehlsargumente, Logs oder das Repository geschrieben. Keine dieser Inhalte werden in das Skill kopiert. Die ursprünglichen Lizenz- und Urheberrechtsvermerke bleiben erhalten.
• Quellpakete des Benutzers sind schreibgeschützt; extrahierte Inhalte, umgeschriebene Module, Caches, Spielstände und Logs werden in einem unabhängigen und ignorierten Datenverzeichnis abgelegt. Nach Spiel und Version isolieren, keine Zustände anderer Emulatoren überschreiben; Quellcode-Rollbacks löschen keine Benutzerspielstände.
• Caches müssen Änderungen der Eingabe-Build-ID, des Umschreibers/Konverters, der Plattform und der Compiler-Optionen erkennen. Unbekannte oder gemischte Versionen müssen vor dem Betreten des Gast-Codes abgelehnt werden.
• macOS und iOS/iPadOS werden separat gebaut, signiert und validiert. Der Erfolg eines Installationsskripts belegt nur die entsprechende Phase; Ergebnisse für iPhone, iPad, Simulator und Mac werden separat gemeldet.
• Lokale iOS-Builds können umgeschriebenen Code des Originalspiels enthalten; vor der Auslieferung oder Veröffentlichung ist der Inhalt des App-Pakets und die Lizenz zu prüfen – es werden nur Inhalte verteilt, die zur Verteilung berechtigen. Lokale abgeleitete Produkte werden nicht automatisch hochgeladen.

Abschlussbericht: Was wurde geändert, bis zu welchem Schritt wurde tatsächlich ausgeführt, welche Beweise liegen für welchen Build und welches Gerät vor, welche Einschränkungen bestehen weiterhin, welche Blockade sollte als nächstes überprüft werden. Nicht verifizierbare Prozentangaben oder "vollständig kompatibel" sind zu vermeiden.