Eigentlich wollte ich ein Piratenabenteuer. CrossOver hatte einen anderen Vorschlag: DX12 Error 0x80070057. Keine Karibik, kein Entern, nicht einmal eine besonders dramatische Fehlermeldung. Nur ein kleines Fenster mit ausgesprochen wenig Seegang.
Das brauchbare Ergebnis vorweg: Assassin’s Creed Black Flag Resynced erreichte auf diesem M1 Max das Menü und einen kurzen Spieltest mit korrekter Grafik. Dafür lief CrossOver 26.3 in einer separaten App-Kopie mit GPTK 4 Beta 3, ausgewähltem D3DMetal und deaktiviertem MetalFX. Die normale CrossOver-App blieb unangetastet. FPS und längere Stabilität wurden nicht gemessen.
Dieser Test vom 31. Oktober 2026 betrifft Resynced, das Remake von Assassin’s Creed IV: Black Flag. Ältere AC4-Anleitungen zum Spiel von 2013 behandeln ein anderes Ziel. Hier geht es um unseren tatsächlichen Weg – einschließlich einer schwarzen Aufnahme, die uns kurz in die falsche Richtung schickte.
Ausgangspunkt: ein reproduzierbarer DX12-Fehler
Getestet wurde auf einem Apple M1 Max mit macOS 26.6.2, Build 25G83. Installiert war CrossOver 26.3.0.39832 mit dem mitgelieferten D3DMetal 3.0. Das Spiel lag in einer vorhandenen Bottle auf einer externen SSD.
Dieser Ausgangszustand endete bei DX12 Error 0x80070057. Die genaue Meldung ist hilfreicher als die Sammelkategorie „CrossOver stürzt ab“. Ein gescheiterter Grafikstart, ein hängender Prozess und eine fehlerhafte Bildausgabe können vom Sofa aus alle nach „läuft nicht“ aussehen. Für die Diagnose sind es unterschiedliche Fälle.
CodeWeavers beschreibt D3DMetal als CrossOvers Grafikübersetzung für DirectX 11 und 12. Damit war die Grenze zwischen Spiel und Grafiklaufzeit ein sinnvoller nächster Prüfpunkt. Daraus folgt allerdings noch keine Diagnose für einen bestimmten Shader oder eine bestimmte Funktion.
Das Experiment bekommt ein eigenes Schiff
Wir legten eine separate Kopie von CrossOver 26.3 an und installierten dort Apples GPTK-4-Beta-3-Evaluierungslaufzeit nach der mitgelieferten Read-Me-Datei. Die reguläre /Applications/CrossOver.app behielt D3DMetal 3.0. Die Test-App bekam einen eigenen Namen und einen Starter mit eindeutigem Laufzeitpfad.
Die wichtige Einschränkung: Eine separate App ist keine separate Bottle. Beide App-Kopien griffen auf dieselbe vorhandene Bottle, dieselben Spieldateien, Einstellungen und Spielstände zu. Ein Spielstart konnte diese Dateien weiterhin verändern. Deshalb wurden Bottle-Konfiguration, Spielkonfiguration nach dem fehlgeschlagenen Ausgangstest und ein vorhandener Autosave vorher gesichert.
Vor einem Laufzeitwechsel müssen alle Programme der betreffenden Bottle beendet sein. Zwei unterschiedliche Wine-Laufzeiten sollten sie nicht gleichzeitig verwenden. Eine eigene Test-Bottle würde stärker isolieren; in diesem Versuch blieb es ausdrücklich bei der vorhandenen Bottle.
Apple stellt die Evaluierungsumgebung bereit, um Windows-Spiele auf Apple Silicon zu untersuchen. Die Laufzeit sollte von Apple kommen, zusammen mit der Anleitung für genau diesen Build. Dieser Artikel verteilt keine Apple-Bibliotheken und ersetzt deren Installationsanleitung nicht.
Die Konfiguration, die ins Spiel kam
Der erfolgreiche Start verwendete diese drei Einstellungen:
CX_GRAPHICS_BACKEND=d3dmetal
D3DM_ENABLE_METALFX=0
ROSETTA_ADVERTISE_AVX=1
Damit wurde D3DMetal ausdrücklich ausgewählt, MetalFX ausgeschaltet und die AVX-Anzeige des Startprofils aktiviert. Wir haben die drei Variablen nicht einzeln wieder entfernt und gegeneinander getestet. Belegt ist deshalb die funktionierende Kombination, nicht „diese eine Variable allein repariert das Spiel“.
Zusätzlich prüften wir am laufenden Spielprozess, welche D3DMetal- und D3D12-Dateien tatsächlich geladen wurden. Ein App-Symbol, ein Installationsordner und ein ausgewähltes Backend beschreiben zunächst die Absicht. Die geladenen Bibliothekspfade zeigen, welche Laufzeit der Prozess wirklich erreicht hat.
Für eine eigene Diagnose hilft nach Ermittlung der richtigen Prozess-ID beispielsweise diese reine Leseabfrage:
# 12345 durch die Prozess-ID des laufenden Spiels ersetzen.
lsof -p 12345 | rg 'D3DMetal\.framework|apple_gptk/.*/d3d12'
Die vollständigen Pfade sollten zur vorgesehenen App-Kopie passen. Keine Ausgabe ist noch kein Gegenbeweis: Berechtigungen, Dateinamen oder ein bereits beendeter Prozess können das Ergebnis beeinflussen.
Der schwarze Bildschirm war eine schwarze Aufnahme
Mit der neuen Laufzeit verschwand der bisherige DX12-Dialog. Die Aufnahme nur des Wine-Spielfensters blieb allerdings schwarz. Verlockende Schlussfolgerung: wunderbar, immerhin ein neuer Fehler.
Am tatsächlichen Bildschirm waren jedoch Intro beziehungsweise Menü sichtbar. Eine Aufnahme des gesamten Displays zeigte anschließend auch das Menü mit seiner animierten 3D-Figur korrekt. Die Fensteraufnahme hatte das gerenderte Bild nicht erfasst. Ihr schwarzes Ergebnis war kein Beleg dafür, dass das Spiel selbst schwarz renderte.
Im Log stand außerdem AGX: exceeded compiled variants footprint limit, obwohl das Menü sichtbar war. Die Meldung verdient Kontext, aber keine automatische Beförderung zur Fehlerursache. In diesem Lauf bewies sie für sich genommen keinen Absturz. Dieselbe Disziplin half schon bei der Witcher-3-Untersuchung mit CrossOver: dem Fehler folgen, den man tatsächlich nachweisen kann.
Ein Starter, der sich den Kurs merkt
Eine funktionierende Konfiguration sollte beim nächsten Start wieder dieselbe sein. Über die gewöhnliche CrossOver-App wären wir unauffällig zur alten Grafiklaufzeit zurückgekehrt.
Das folgende Beispiel ist eine übertragbare Fassung unseres getesteten Starters, mit Beispielpfaden und einer Bottle namens BlackFlag. Bottle-Verzeichnis, Bottle-Name und Spielordner müssen zur eigenen Installation passen. Die Testlaufzeit muss bereits eingerichtet sein; diese Variablen installieren kein GPTK. Der direkte EXE-Start setzt voraus, dass die eigene Installation ihn unterstützt. Eine erforderliche Store-Anmeldung bleibt Bestandteil des normalen Spielstarts.
#!/bin/zsh
set -eu
runtime="$HOME/Applications/CrossOver-BlackFlag-Test.app/Contents/SharedSupport/CrossOver"
bottle_root="$HOME/Library/Application Support/CrossOver/Bottles"
bottle='BlackFlag'
game_dir="$bottle_root/$bottle/drive_c/Games/BlackFlagResynced"
log_dir="$HOME/Library/Logs/BlackFlag-CrossOver"
[[ -x "$runtime/bin/wine" && -f "$game_dir/ACBlackFlag.exe" ]] || {
print 'Laufzeit oder Spiel fehlt. Zuerst die Pfade prüfen.'
exit 1
}
mkdir -p "$log_dir"
log_file="$log_dir/$(date +%Y%m%d-%H%M%S).log"
CX_BOTTLE_PATH="$bottle_root" "$runtime/bin/wine" \
--bottle "$bottle" \
--env 'CX_GRAPHICS_BACKEND=d3dmetal D3DM_ENABLE_METALFX=0 ROSETTA_ADVERTISE_AVX=1' \
--debugmsg '-all' \
--workdir "$game_dir" "$game_dir/ACBlackFlag.exe" \
>"$log_file" 2>&1
Unser tatsächlicher Test nutzte eine externe SSD und die vorhandene Bottle Mac. Genau deshalb stehen diese Angaben im öffentlichen Beispiel als anpassbare Werte. Ein bereits laufendes Spiel vor einem weiteren Start zuerst beenden. Die reduzierte Wine-Protokollierung eignet sich für normale Starts; ein kurzes oder leeres Log beweist trotzdem keinen erfolgreichen Spielbetrieb.
Ein verlockender Patch blieb an Land
Ein älterer Community-Bytepatch war für GPTK 4 Beta 2 geschrieben. Sein erwartetes Suchmuster passte nicht zur Beta-3-Bibliothek. Wir haben ihn nicht angewendet.
Binäre Offsets und Bytefolgen gehören zu einem bestimmten Build. Wenn das erwartete Muster fehlt, sollte man anhalten und prüfen – nicht die Prüfung entfernen, bis das Skript irgendwo schreiben kann. In unserem Versuch erreichte die Beta-3-Konfiguration das Spiel ohne diesen älteren Patch. Über dessen Wirkung auf dem ursprünglich vorgesehenen Build sagt dieser Test nichts aus.
Eine MetalFX-/DLSS-Brücke wurde ebenfalls nicht eingerichtet oder getestet. D3DM_ENABLE_METALFX=0 gehörte zum geprüften Profil. Performance-Tuning darf später auf eine eigene Expedition gehen, wenn der funktionierende Ausgangspunkt feststeht.
Was dieser Test belegt
| Prüfung | Ergebnis am 31. Oktober 2026 |
|---|---|
| CrossOver 26.3 mit mitgeliefertem D3DMetal 3.0 | DX12-Fehler beim Start. |
| Separate CrossOver-26.3-App mit GPTK 4 Beta 3 | Einrichtung und Menü sichtbar; im mehr als sechs Minuten beobachteten Startlauf kein Startabsturz. |
| Kurzer Spieltest | Spieler bestätigt Spielbetrieb mit korrekter Grafik. |
| FPS, Framezeiten und längere Sitzung | Nicht gemessen. |
| MetalFX-/DLSS-Brücke | Nicht installiert oder getestet. |
| Andere Macs, Spielupdates und Laufzeit-Builds | Von diesem Test nicht abgedeckt. |
Die Buildnummer des Spiels wurde nicht festgehalten. Das Ergebnis ist deshalb ein datierter lokaler Test, keine Zusage für jedes Update. Start und kurze Spielrunde auf diesem Gerät sind belegt. „60 FPS“, „vollständig stabil“ oder „läuft auf jedem Apple-Silicon-Mac“ wären Aussagen, für die uns die Messungen fehlen. Das Meer hat durchaus noch Platz für eine zweite Überraschung.
Wenn derselbe DX12-Fehler auftaucht
Zuerst die genaue Spielausgabe, macOS-Version, CrossOver-Build und das Backend festhalten. Relevante Bottle-Konfiguration und Spielstände sichern. Dann einen bekannten Ausgangszustand mit einer eindeutig benannten Testkonfiguration vergleichen, die geladenen Bibliotheken prüfen und die Bildausgabe unabhängig von einer einzelnen Aufnahmemethode beurteilen.
Scheitert das Experiment, zuerst sämtliche Programme der Bottle beenden und dann zur regulären CrossOver-App zurückkehren. Damit wechselt man zur ursprünglichen Laufzeit. Einstellungen oder Spielstände in der gemeinsam verwendeten Bottle werden dadurch nicht zurückgesetzt. Dafür gezielt die benötigten gesicherten Dateien wiederherstellen.
Das schöne Ende war hier erfreulich unspektakulär: ein sichtbares Menü, eine bestätigte kurze Spielrunde und ein Starter, der seine Laufzeit kennt. Das Piratenschiff konnte endlich ablegen. Die Auslaufpapiere waren diesmal eben ein Shellskript.
Quellen und verwandte Notizen
- Apple: Game Porting Toolkit und Evaluierungsumgebung – offizielle Bezugsquelle; im lokalen Test wurden der Beta-3-Download und dessen Anleitung verwendet.
- CodeWeavers: Erweiterte Grafikeinstellungen in CrossOver 26 – Definitionen und Geltungsbereich der Backends.
- Ubisoft: Assassin’s Creed Black Flag Resynced – das hier untersuchte Remake.
- The Witcher 3 und die Nebenquest mit zwei Bugs – ein weiterer Fall, bei dem die konkrete Diagnose den brauchbaren Fix bestimmte.
Ergebnisse, Screenshots und Startprofil stammen aus unserem eigenen Test vom 31. Oktober. Das Titelbild ist eine redaktionelle Illustration; die beiden Diagnosebilder sind echte Aufnahmen.
