ac-odyssey
Verified
Download JSON
Improve this profile
- Layer
- D3DMetal
- Windows
- win10
- Sync
- msync
- DXVK
- false
- AVX
- true
- Executables
- acodyssey.exe
- Winetricks
- vcrun2019, vcrun2022
Notes
UPDATE 17 Sep 2026: Connect sign-in is recovered and the game plays on D3DMetal again. Measured tonight from the Wyn tile: launch record ac-odyssey / d3dmetal / 383 s started 20:53:27; Steam App Running 20:53:27-20:59:50; Connect Play session (1) started 20:53:26 with a heartbeat at 20:58:58 and a clean delete at 20:59:50; ACOdyssey.ini AdapterVendorID=4098 (AMD Compatibility Mode = D3DMetal; DXVK reports 4318); ManualSave02 written 20:58:48; no crash directory and no RtlpWaitForCriticalSection in the Wine log. A second clean run on 16 Sep 01:17:58-01:25:45 wrote ManualSave01. STILL OPEN, unrelated to Connect: the startup wedge. 3 of 6 recorded D3DMetal launches (10 Sep 01:29 and 18:24, 15 Sep 23:37) deadlocked before the game sized its window - 0.1% CPU, 49 threads, a 1x1 main window, and err:sync:RtlpWaitForCriticalSection on Wine's loader_section. Wedged runs also stop after 'xinput1_4.dll hooked' in Connect's overlay_log while every run that reached a world logged 'D3D11 device created' there; that is a correlation across six runs, not a proven cause. CORRECTION 15 Sep 2026: the shared Connect profile prevents Windows-user divergence, not session expiry or blocked web sign-in. The link was intact during the 14 Sep failure. Wyn gates game launch on account-startup evidence, now also on Connect's ownership connection, and reports both. VERIFIED 10 Sep 2026 on M4 16GB, macOS 26.5.1: played to a loaded map on the game-host tree (winecx 11.15) and exited clean. Layer confirmed by lsof on the live process, not by profile intent — libd3dshared=3, winemetal=0, so D3DMetal drove the RHI while the DXMT payload sat resident-and-unselected in system32. That makes Odyssey the first non-Unreal confirmation of the §5 coexistence work. Log: ~/wyn-handovers/play-ac-odyssey-20260910-004217.log. CAVEAT ON THIS CLAIM: no launch record exists, because the session was started from the `wyn play` CLI and only WynApp (the GUI) ever calls LaunchRecordStore.append — the CLI has no writer at all. Play it from the app for >60s (LaunchObserver.minimumUptime) and a record appears; nothing needs fixing first. No frame count either, and that one is structural: SessionPerformance requires profile.unrealProject and Odyssey is AnvilNext, so Wyn's measurement path cannot see it. Use the game's own built-in benchmark. The evidence here is a person and a log, not a measurement. AnvilNext DX11 on Apple Silicon. Old winecx path used CX_GRAPHICS_BACKEND=d3dmetal and ACOdyssey AppDefaults d3d*=b; current stack is the same D3DMetal builtins via translationLayer d3dmetal + WINEDLLOVERRIDES d3d11,dxgi,d3d12,d3d10,atidxx64,nvapi64,nvngx=b. In-game 1080p low–med ~70% scale. Ubisoft Connect required, and its credentials live per WINDOWS user: winecx 11.15 resolves to `crossover`, wine 11.0 to the macOS user, so a sign-in on one tree is invisible to the other. An unsigned-in game-host Connect does not show a sign-in prompt — its UI is transparent — it silently lands on Ubisoft's bot-check page. ConnectLauncher.shareConnectProfileAcrossWineUsers links the two to prevent that specific profile divergence. Connect CEF: win10; winhttp=b,n; dwrite=builtin (NOT empty — empty breaks libcef import); d2d1/d3d10core=d; Mac Driver RetinaMode=N Decorated=Y AllowOpenGL=Y. DO NOT re-add libEGL/libglesv2=d: a 9 Aug AppDefaults set caused the gl_factory_win.cc(63) NOTREACHED storm. Removed 12 Aug. MetalFX/HUD stay off.
Environment
WINEDLLOVERRIDES | d3d11,dxgi,d3d12,d3d10,atidxx64,nvapi64,nvngx=b |
|---|---|
MTL_HUD_ENABLED | 0 |
D3DM_ENABLE_METALFX | 0 |
D3DM_SHOW_HUD_STATS | 0 |
Agents: GET /api/v1/profiles/ac-odyssey.json or GET /api/v1/games/ac-odyssey.json.