The Witcher 3 und die Nebenquest mit zwei Bugs.

Steam wechselte kurz auf „Wird ausgeführt“ und dann zurück auf „Spielen“. Kein Spielfenster, keine hilfreiche Erklärung. Dieses Symptom lässt viel offen: Ein Launcher, eine fehlende Datei oder ein sehr früher Prozessfehler können in der Bibliothek gleich aussehen.

Der erste sinnvolle Schritt war deshalb eine Bestandsaufnahme: aktive Bottle, Steam-Bibliothek auf der externen SSD, Spiel-Build und tatsächlich gestartete Datei. Ein Ordner namens „The Witcher 3“ verrät noch nicht, ob eine ältere Fehlerbehebungsanleitung zu seinem Inhalt passt.

In dieser Installation lag die DX12-Datei unter bin/x64_dx12. CrossOver leitete ihren Start auf den älteren Pfad bin/x64 um. Dieses Verzeichnis fehlte. Die Anfrage stand vor dem richtigen Haus und folgte dann einem veralteten Schild zu einer abgerissenen Tür.

Requested:  bin/x64_dx12/witcher3.exe
Redirected: bin/x64/witcher3.exe
Missing:    bin/x64
Workaround: bin/x64 -> x64_dx12

Die Unterscheidung ist entscheidend: Ein DX12-Dateiname beweist noch nicht, dass die DX12-Initialisierung begonnen hat. Hier kam der Prozess gar nicht so weit. Schatteneinstellungen oder ein anderer Grafik-Backend konnten das fehlende Zielverzeichnis nicht herstellen.

Bei einer ähnlichen Untersuchung ist diese kleine, rein lesende Prüfung nützlicher als ein Nachmittag voller Schalter. Den Beispielpfad durch das tatsächliche Spielverzeichnis ersetzen:

TASK_GAME_DIR="/path/to/The Witcher 3"
ls -ld "$TASK_GAME_DIR/bin/x64" \
  "$TASK_GAME_DIR/bin/x64_dx12"

Der Community-Installer berücksichtigt die alte Umleitung mit bin/x64 → x64_dx12. Der erwartete Pfad führt dadurch zur vorhandenen DX12-Version. Ein DX11-Renderer entsteht dabei nicht. Auf Dateisystemen, die den Link nicht speichern können, verwendet das Skript stattdessen eine Verzeichniskopie. Ein Symlink ist deshalb nicht der einzige mögliche Installationszustand.

Im Verlauf der Diagnose half auch eine umbenannte Testdatei, die vom ursprünglichen Dateinamen abhängige Umleitung zu umgehen. Das war ein Versuch zur Eingrenzung. Die beibehaltene Installation verwendete anschließend den Pfad-Workaround des Community-Fixes und den normalen Steam-Eintrag.

Die Belohnung für das erste gelöste Hindernis war ein Spielfenster. Es war schwarz. Der Quest-Designer hatte offenbar einen zweiten Gegner eingeplant.

Der erste Fix öffnete ein Fenster. Der zweite Fehler steckte in der Shader-Übersetzung.

Ein vorhandener Prozess und ein geöffnetes Fenster sind andere Meilensteine als eine gerenderte Oberfläche. Die Untersuchung musste nun von der Dateiauflösung zur Grafikinitialisierung wechseln. Diagnose und Community-Quellcode deuteten auf eine problematische Pipeline in Apples Shader-Konvertierung innerhalb von D3DMetal.

Das Community-Projekt beschreibt eine Stream-Output-Pipeline mit Geometry Shader und ohne Pixel Shader. Sein Proxy fängt den entsprechenden Aufruf zum Erzeugen der Grafikpipeline ab und weist diesen Fall zurück, bevor die Übersetzung ihn verarbeitet.

Der folgende Ausschnitt zeigt die Entscheidung aus der für den lokalen Build verwendeten Revision. gs und ps beschreiben Geometry- und Pixel-Shader-Bytecode; soEntries zählt Stream-Output-Deklarationen. Die Variablen stammen aus dem umgebenden Quellcode. Der Ausschnitt ist deshalb kein eigenständiges Programm.

if (gs->n && (soEntries || !ps->n)) {
    logmsg("  -> #%ld SKIPPED (stream output / GS without PS)", id);
    if (out) *out = NULL;
    return (long)0x80070057; /* E_INVALIDARG */
}
long hr = origGfx(dev, desc, riid, out);

Die Bedingung liefert für den abgefangenen Fall E_INVALIDARG zurück. Andere Aufrufe zur Erstellung von Grafikpipelines werden an die ursprüngliche Funktion weitergegeben. In Microsofts D3D12-API liefert diese Funktion einen HRESULT. Der Proxy verändert die Antwort auf eine Anfrage, statt einen neuen Renderer zu implementieren.

Außerdem leitet die DLL die FidelityFX-Einstiegspunkte an den gesicherten Original-Loader weiter. Sie sitzt damit an einer nützlichen Stelle der Startkette: Der problematische Aufruf lässt sich beobachten und beeinflussen, während die ursprüngliche Bibliothek beteiligt bleibt.

Es handelt sich um einen anwendungsspezifischen Workaround. Annahmen über Datenlayouts und die Device-Hooks gehören zu der Umgebung, für die der Quellcode geschrieben wurde. Ein erfolgreicher Start kann mit einem fehlenden Grafikeffekt einhergehen. Auch „FidelityFX“ im Dateinamen belegt für sich noch keine geprüfte Skalierung oder Frame Generation.

Der nächste Schritt war eine überraschend kleine Crafting-Rezeptur: eine C-Datei, ein Windows-Ziel und ein Compiler auf macOS. Ein Windows-Desktop wurde für diesen Build nicht benötigt.

Zig unterstützt Cross-Compilation. Das dokumentierte Ziel war x86_64-windows-gnu: Die Ausgabe musste zum Windows-x86-64-Prozess in CrossOver passen, obwohl der Mac Apple Silicon verwendet. Host-Architektur und Ausgabe-Architektur sind zwei getrennte Entscheidungen.

Für den damaligen Build kamen Community-Commit 436de811fcc8784dd0dfb6c9666077b34ca53d31 und die dokumentierte ziglang-Version 0.17.0 zum Einsatz. Die folgende Befehlsfolge macht diese Eingaben ausdrücklich. Sie baut die DLL; sie installiert noch nichts im Spiel.

git clone https://github.com/tholtman1-del/witcher3-crossover-fix.git
cd witcher3-crossover-fix
git checkout 436de811fcc8784dd0dfb6c9666077b34ca53d31

python3 -m venv .venv
.venv/bin/python -m pip install ziglang==0.17.0
.venv/bin/python -m ziglang cc \
  -target x86_64-windows-gnu \
  -shared -O2 \
  -o amd_fidelityfx_loader_dx12.dll \
  ffxproxy.c

shasum -a 256 amd_fidelityfx_loader_dx12.dll

-target wählt die Windows-Zielplattform, -shared erzeugt eine DLL und -O2 aktiviert Optimierungen. Der letzte Befehl erfasst den SHA-256-Fingerabdruck. Der Hash des lokalen Ergebnisses steht im herunterladbaren Build-Protokoll.

Ein Hash identifiziert bestimmte Bytes. Er beweist weder die Vertrauenswürdigkeit einer Datei noch muss eine andere Compiler-Umgebung aus demselben Quellcode denselben Hash erzeugen. Quellrevision, Compiler, Ausgabeziel und Testergebnis zusammen festzuhalten macht den Build später nachvollziehbarer.

Bei der Installation eine Adresse und einen Rückweg mitnehmen

Die Steam-Bibliothek lag auf einem externen Laufwerk. Die aktive Bottle war außerdem nicht das erste Verzeichnis, das eine Vermutung über Standardpfade nahelegte. Das geprüfte Spielverzeichnis direkt zu übergeben ersparte eine Suche durch sämtliche Bottles und Volumes.

Nach dem Beenden des Spiels ersetzte der Projekt-Installer den Loader durch den Proxy, sicherte das Original als amd_fidelityfx_loader_dx12_orig.dll und ergänzte den Pfad-Workaround:

TASK_GAME_DIR="/path/to/The Witcher 3"
zsh ./install.command "$TASK_GAME_DIR"

Diese Befehle setzen voraus, dass Quellcode und frisch gebaute DLL zusammenliegen und der Beispielpfad durch das Spielverzeichnis ersetzt wurde. Die Sicherung wurde mit dem Original abgeglichen. Anschließend ging es zurück zum gewöhnlichen Steam-Start: Genau diesen Ablauf wollten wir reparieren.

Für den späteren Rückweg das Spiel beenden und den zugehörigen Uninstaller aus demselben Quellcode-Verzeichnis starten:

TASK_GAME_DIR="/path/to/The Witcher 3"
zsh ./uninstall.command "$TASK_GAME_DIR"

Updates können den Gegner neu spawnen

Ein Spielupdate oder Steams Dateiprüfung kann den Proxy wieder durch den ausgelieferten Loader ersetzen. Wenn das Symptom zurückkehrt, zuerst den Installationszustand und die Eignung des Fixes für den neuen Build prüfen. Eine am 10. Oktober passende Reparatur passt nicht automatisch nach dem nächsten Patch.

Deshalb gehört das Build-Protokoll zum Artikel. Mein zukünftiges Ich sollte eine Karte bekommen und keinen Zettel mit „Ich habe hier irgendwas geändert, und einmal ging es“.

Was ich in die nächste Debugging-Quest mitnehmen würde

Zuerst die fehlerhafte Phase lokalisieren. Die Rückkehr zu „Spielen“, ein schwarzes Fenster und eine kaputte Szene sind drei Beobachtungen mit möglicherweise unterschiedlichen Ursachen. Setup festhalten, einen Teil der Kette verändern und prüfen, welcher Meilenstein sich bewegt. Ein neuer Fehler nach einem Fix kann bedeuten, dass der erste Blocker beseitigt wurde.

Die Erkenntnis reicht weit über Spiele hinaus. Eine Web-App kann ihre Route auflösen und trotzdem beim Laden der Daten scheitern. Ein Dienst kann starten und weiterhin seine Datenbank nicht erreichen. Ein Compiler kann fertig werden und ein Ergebnis erzeugen, das bei der ersten echten Aufgabe scheitert. Die hilfreiche Frage lautet immer: Was hat dieser Test tatsächlich belegt?

Mit der spielerischen Seite von Oberflächen habe ich mich auch beim 3D-Terrarium-Planer im Browser beschäftigt. Diesmal kam die Nebenquest ungefragt. Ihr wertvollster Loot war ein klareres Bild des Systems.