Ein Entwickler unter dem Pseudonym ilreb hat die Quake-Engine aus dem Jahr 1996 direkt in moderne Webbrowser portiert. Das Projekt mit dem Namen Quake-SRP (kurz für „slop rust port“) verzichtet vollständig auf externe Abhängigkeiten und verbietet die Verwendung von unsafe-Blöcken in der gesamten Codebasis ausnahmslos. Der dreißig Jahre alte C-Quellcode wurde Datei für Datei in sicheres Rust übertragen, nach WebAssembly kompiliert und läuft vollständig in einem dedizierten Web Worker. Nutzer können unveränderte pak1.pak-Dateien, offizielle Mission-Packs oder originale CD-Audiospuren per Drag-and-Drop direkt im Browser laden – die gesamte Ausführung erfolgt lokal auf dem Endgerät, ohne dass Daten den Browser verlassen.
Kompilierung des C-Codes nach WASM im Web Worker
Der von id Software 1996 als Open Source veröffentlichte C-Quellcode von Quake ist ein Labyrinth aus manueller Speicherverwaltung, direkter Zeigerarithmetik und hardwarenahen Optimierungen. Anstatt den modernen Weg einer hardwarebeschleunigten Render-Pipeline über WebGL oder WebGPU zu wählen, behielt der Autor den ursprünglichen CPU-Software-Rasterisierer von WinQuake samt seiner charakteristischen 8-Bit-Farbpalette bei. WebGL2 übernimmt lediglich den finalen Kopiervorgang (Blit), um die vorberechneten Framebuffer-Pixel auf den Bildschirm zu übertragen. Kapitel 2 bis 4 aus pak1.pak, Missionserweiterungen aus pak0.pak und Audio-Tracks lassen sich direkt im Browserfenster ablegen.
Eine Engine, die einst tief mit der zugrundeliegenden PC-Hardware verzahnt war, in einen Browser-Web-Worker zu verlagern, stellt einen fundamentalen Architekturwechsel dar. Die gesamte WebAssembly-Logik lastet in einem Hintergrund-Thread einen einzelnen CPU-Kern voll aus, während der Haupt-Thread lediglich Maus- und Tastaturereignisse weiterleitet und berechnete Bild- und Audiodaten aus dem gemeinsamen Speicher (SharedArrayBuffer) abruft. Der Verzicht auf moderne GPU-Pipelines zugunsten einer Ausführung des dreißig Jahre alten Software-Renderers auf einem einzelnen Browser-Kern minimiert Laufzeitunsicherheiten zwischen verschiedenen Host-Systemen drastisch. Diese scheinbar archaische Designentscheidung reduziert ein fragiles plattformübergreifendes Refactoring auf ein deterministisches Eingabe-Ausgabe-Übersetzungsproblem.
Frame-genaue Pixelvergleiche als Abnahmekriterium
Der eigentliche Dreh- und Angelpunkt von Quake-SRP ist ein automatisiertes Test- und Verifikationssystem. Um die Zuverlässigkeit der LLM-basierten Code-Migration zu garantieren, kompilierte das Projekt eine eigenständige, fensterlose (headless) Version des originalen C-Quellcodes von WinQuake, die als unanfechtbares Referenzorakel dient. Die Testsuite durchläuft neun Karten in zwei Auflösungen über hunderte Frames hinweg bei voller Monster-Aktivität. Sie vergleicht gerenderte 3D-Pixel, Interface-Elemente, gemischte Audiosamples und interne Spielzustände bei der Demo-Wiedergabe Frame für Frame mit der C-Referenz. Die Dokumentation listet bekannte Abweichungen transparent auf, anstatt spekulative Fehler-für-Fehler-Gleichheit zu behaupten.
In der Emulator-Entwicklung sind visuelle Regressionstests etabliert – Projekte wie Dolphin nutzen seit Jahren automatisierte visuelle CI-Pipelines. Kontinuierliche 3D-Sequenzen jedoch Frame für Frame auf Pixelebene abzugleichen und dabei Mipmap-Abtastungen sowie Beleuchtungsgradienten präzise zu erfassen, liegt in einer völlig anderen Komplexitätsklasse als herkömmliche DOM-Snapshots in der Frontend-Entwicklung. Wie viel Code ein Sprachmodell in einem Durchgang generieren kann, war nie der ausschlaggebende Faktor; entscheidend ist, ob Maschinen Abweichungen auf Pixelebene autonom erkennen können, um synthetischen Code an der Realität zu eichen. Solange das Referenzorakel kein grünes Licht gibt, besitzt selbst syntaktisch eleganter Code keinerlei Wert.
Abbildung: E1M1 im Classic-Preset (1280×960), exakt auf das Verhalten des originalen WinQuake abgestimmt. Quelle: Screenshot aus dem quake-srp-Repository.
Abbildung: Derselbe Level im Standard-Preset (1920×1080) mit Widescreen-Sichtfeld und unbegrenzter Bildwiederholrate. Quelle: Screenshot aus dem quake-srp-Repository.
Koordinator-Agenten mergen Branches erst nach grünem CI
Die Projekt-README dokumentiert die klare Arbeitsteilung zwischen Mensch und Maschine. Claude (betrieben über Claude Code) agierte als Hauptautor des Codes, der Refactorings und der Dokumentation. Der menschliche Entwickler übernahm die Rolle des Architekten: Er definierte Randbedingungen, testete Builds durch manuelles Spielen, meldete Fehler und koordinierte Aufgaben über isolierte Git-Branches hinweg. Zudem überwachte ein leitender Koordinator-Agent („Chair“) das Repository und mergte Branches erst dann, wenn alle automatisierten Tests und Bildvergleiche ausnahmslos bestanden waren.
Diese Aufgabenteilung verlagerte die aufwendige Korrektheitsprüfung vollständig auf ein deterministisches Orakel und entlastete den Menschen von der zeilenweisen Prüfung KI-generierter Syntax. Das Projekt bietet neben dem ?classic-Modus, der das Originalverhalten detailgetreu nachbildet, den Standardmodus ?slop mit Breitbild-Sichtfeld und unbegrenzter Bildwiederholrate. Der Mensch trägt lediglich die Verantwortung für die spielerische Qualität des Endprodukts, während der repetitive Aufwand für das Beheben von Compiler-Fehlern, Speicherlecks und Pufferüberläufen vollständig innerhalb der Generatorschleife abgearbeitet wird.
Abbildung: Vergleich der perspektivischen Texturausrichtung über Bildschirme hinweg während der Ausführung des automatisierten visuellen Differenzprüfers. Quelle: Screenshot aus dem quake-srp-Repository.
Übertragbarkeit des Workflows auf COBOL-Mainframes
Über den nostalgischen Reiz von Retro-Spielen hinaus weckte der Workflow von Quake-SRP unter Ingenieuren großes Interesse an der Bewältigung der größten Altlasten der Softwareindustrie. In Hacker-News-Diskussionen schilderten Entwickler ähnliche Erfahrungen: Claude wurde für das Reverse Engineering proprietärer Engines eingesetzt, wobei das Modell eigenständig Replay-Skripte ausführte, periodische Screenshots für bidirektionale Vergleiche erstellte, den Quellcode analysierte und Zustandsautomaten für deterministisches Verhalten patchte. Da sich maschinengestützte Verifikation und Codemigration als praxistauglich erweisen, wandte sich die Debatte rasch den COBOL-Systemen zu, die nach wie vor das Rückgrat globaler Finanzinstitute bilden.
Enorme manuelle Verifikationskosten und unüberschaubare Randfall-Logiken sind der Grund, warum unternehmenskritische Kernbanksysteme seit Jahrzehnten nicht auf Cloud-Native-Architekturen migriert werden konnten. Obwohl die Geschäftsregeln im Altwasser des Quellcodes vollständig dokumentiert sind, wagt wegen verflochtener Abhängigkeiten kaum ein Team den riskanten Schritt eines Neuschreibens. Genau hier entfalten duale Orakel-Systeme ihre größte Stärke. Sobald eine hochpräzise Verifikationsschleife für Ein- und Ausgaben etabliert ist, wandelt sich die Mainframe-Modernisierung von einem existenzbedrohenden Wagnis in ein planbares Code-Hedging, das primär gegen Rechenleistung und Zeit getauscht wird.
Missbrauchspotenzial beim Reverse Engineering von Steuerschnittstellen
Diese methodischen Fähigkeiten bergen jedoch eine Kehrseite. Wenn eine Schleife aus generativen Modellen und automatisierten Testorakeln in der Lage ist, eine komplexe 3D-Engine der 1990er Jahre durch kontinuierliche Fehlersuche und Differenzabgleiche verlustfrei zu übersetzen, besitzt sie gleichermaßen das Potenzial, die internen Zustandsübergänge geschlossener Systeme zu analysieren und nachzubilden. Kommentatoren verwiesen auf bedenkliche Einsatzmöglichkeiten: Wird solch hochgradig automatisiertes Black-Box-Reverse-Engineering auf kritische Infrastrukturen angewandt, lassen sich gefälschte Steuerbefehle und täuschend echte Schnittstellen erzeugen, die Schutzmechanismen umgehen. Während Befürworter argumentierten, dass replizierbare Systeme ohnehin nur auf trügerische „Security through Obscurity“ setzten und deren Aufdeckung überfällige Modernisierungen erzwinge, hielten Kritiker dagegen, dass das Klonen industrieller Steuerungs- und HMI-Schnittstellen ungleich verheerendere Folgen habe als fehlerhafte Bankbuchungen.
Ein Modell, das darauf trainiert ist, Diskrepanzen aufzuspüren und logische Lücken zu schließen, fungiert im Kern als Optimierer für berechenbare Logik – völlig unabhängig davon, ob es Open-Source-Spiele analysiert oder in gesicherte industrielle Steuerungssysteme vordringt. Bezogen auf Quake-SRP beweist die Implementierung in sicherem Rust ein pragmatisches Prinzip: Angesichts monumentaler Altcode-Labyrinthe sollten Entwickler Fehler nicht mühsam manuell aus Fluten generierten Codes fischen, sondern ihre Energie vorrangig in den Bau kompromissloser automatisierter Pixel-Orakel investieren. Ein solches Verifikationssystem treibt nicht nur die Wiederbelebung von Altsystemen voran, sondern bildet zugleich die unnachgiebige Leitplanke für generative KI-Code-Pipelines.
Weiterführende Links:
- GitHub-Repository-Übersicht
- Quake-SRP Online-Demo
- Hacker News Diskussion
