Search the Community

Experiment report: Mesa GL-on-D3D12 / zink for KOTOR 1 in CrossOver on Apple Silicon (negative result, fully mapped) TLDR: I tried replacing KOTOR's OpenGL path with modern Mesa (mesa-dist-win) inside a CrossOver bottle on an M3 MacBook Pro, hoping to bypass Apple's deprecated OpenGL driver. Mesa's WGL layer itself works with KOTOR, but both GPU backends (d3d12 and zink) fail at device creation in 32-bit. Software rendering (llvmpipe) runs the game, proving where the wall is. If you were considering this route: here's where it breaks, so you can save an evening. Setup M3 MacBook Pro, macOS (Darwin 25.5.0) CrossOver, Windows 10 bottle, wine build wine-11.0-8726-g2e2f5fca349 KOTOR 1, GOG Windows version, 32-bit exe Mods: K1CP, UniWS 1920x1200, ndix UR HR Menus, HQ Skyboxes II, High Quality Blasters Game fully playable as-is (windowed, Frame Buffer Effects and Soft Shadows off, Disable Vertex Buffer Objects=1). Some scenes lag because KOTOR's fixed-function GL 1.x goes through Apple's deprecated OpenGL driver. Hypothesis Inspired by the ostriv-macos repo (maksymenkoml), which drops Mesa's libgallium_wgl.dll next to a game exe in a CrossOver bottle: route KOTOR's GL through modern Mesa instead of Apple GL. Chain would be Mesa WGL -> gallium d3d12 driver -> D3D12 -> Metal, or alternatively Mesa -> zink -> Vulkan -> MoltenVK -> Metal. Method Downloaded mesa-dist-win prebuilt release (pal1000's repo, release-msvc.7z). Copied from the x86 folder (KOTOR is 32-bit): opengl32.dll, libgallium_wgl.dll, dxil.dll next to swkotor.exe. (Note: libglapi.dll no longer exists in recent releases, glapi was merged into the main DLL.) Wine Configuration -> Libraries -> opengl32 -> Native then Builtin. Launched from Terminal with GALLIUM_DRIVER set explicitly per run, logging via tee. Results Run 1: GALLIUM_DRIVER=d3d12. Black fullscreen window, then access violation (c0000005), null pointer at address 00000000. Key log lines: vkd3d:err:d3d12_device_init Cannot load DXIL conversion library, DXBC-TPF shaders won't be supported Mesa: error: GL User Error: glGetFloatv called without a rendering context Mesa: error: GL User Error: glClearColor called without a rendering context [... many more GL calls without context ...] wine: Unhandled page fault on read access to 00000000 at address 00000000 Surprise finding: D3D12 inside this bottle is served by Wine's vkd3d (D3D12-on-Vulkan-on-MoltenVK), not D3DMetal, at least for this 32-bit exe. vkd3d cannot load the DXIL conversion library, so it cannot consume the shaders Mesa's d3d12 backend produces. Device init fails, context creation returns null, the game calls GL blind and dereferences null. Run 2: GALLIUM_DRIVER=zink. Identical crash signature, no vkd3d lines, no evidence of a Vulkan device being found. Same "GL User Error: called without a rendering context" cascade, same null-pointer crash. Zink found no usable 32-bit Vulkan device through MoltenVK in this bottle. Run 3: GALLIUM_DRIVER=llvmpipe (control). The game runs. Extremely slowly, as expected for software rendering on an emulated x86 CPU, but it renders and reaches the game. Diagnosis Mesa's WGL layer is compatible with KOTOR under CrossOver: contexts get created and the game renders when a device exists (llvmpipe proves this). The failure is specifically 32-bit GPU device creation through the macOS translation stack: d3d12 backend: blocked by vkd3d's missing DXIL support. zink backend: no 32-bit Vulkan device available via MoltenVK in the bottle. No environment variable fixes this; there is no 32-bit GPU device to hand Mesa. What might change this in the future CrossOver routing 32-bit D3D12 through D3DMetal (or D3DMetal gaining whatever this path needs). vkd3d shipping working DXIL conversion in CrossOver's build. A working 32-bit Vulkan/MoltenVK path inside the bottle for zink. If any of those land, this experiment is worth rerunning; the Mesa side of the equation already works. Rollback Complete and clean: delete the copied DLLs next to swkotor.exe, remove the opengl32 override in Wine Configuration, done. Game back to its known-good state in two minutes. Conclusion Negative result, but precise. KOTOR on Apple Silicon via CrossOver remains playable with the usual setup (windowed, FBE and Soft Shadows off, VBOs disabled), with some scene lag. And worth remembering: part of that lag (Taris streets, Dantooine grass) stutters even on native Windows. Logs available if anyone wants the full output. May the Force be with you.