The Witcher 3 and the two-bug side quest.

Steam briefly switched to “Running”, then returned to “Play”. No game window. No useful explanation. This is a broad symptom: a launcher, an unavailable file or an early process failure can all look the same from the library screen.

The first useful move was to establish what was actually installed: the active bottle, the Steam library on the external SSD, the game build and the executable being launched. A folder named “The Witcher 3” does not tell you whether an older troubleshooting guide still applies to its contents.

In this installation the DX12 executable existed in bin/x64_dx12. CrossOver redirected its launch to the older bin/x64 path, which was absent. The request had reached the right house and then followed an outdated sign to a demolished doorway.

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

The distinction matters. A DX12 filename does not prove that DX12 initialization has even begun. Here the process never got that far. Adjusting shadows or swapping graphics backends could not make a missing destination appear.

For a similar investigation, this small read-only check is more useful than an afternoon of toggles. Replace the example path with your actual game directory:

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

The community installer accommodates the old redirect by adding bin/x64 → x64_dx12. That makes the expected path lead to the existing DX12 build; it does not restore a DX11 renderer. Its filesystem fallback copies the directory on volumes that cannot store the link, so a symlink is not the only possible installed state.

During the investigation, bypassing the executable-name-specific redirect with a renamed test executable also helped isolate this first problem. That was a diagnostic experiment. The retained installation used the community fix’s path workaround and the normal Steam entry.

The reward for resolving the first obstacle was a game window. It was black. The quest designer had clearly budgeted for a second encounter.

The first fix opened a window. The second failure lived inside the shader translator.

A visible process and a visible window are different milestones from a rendered interface. The diagnosis now had to move beyond file resolution into graphics startup. The investigation and the community source pointed to a problematic pipeline reaching Apple’s shader-conversion path in D3DMetal.

The community project describes a stream-output pipeline involving a geometry shader and no pixel shader. Its proxy intercepts the relevant graphics-pipeline creation call and rejects that troublesome case before the translator attempts it.

Here is the decision point from the source revision used for the local build. gs and ps describe geometry- and pixel-shader bytecode; soEntries counts stream-output declarations. These names belong to the surrounding source, so this is an excerpt rather than a standalone program.

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);

The condition returns E_INVALIDARG for the intercepted case. Other graphics-pipeline calls continue through the original function. In Microsoft’s D3D12 API, pipeline creation returns an HRESULT; the proxy changes the answer to one request rather than implementing a new renderer.

The DLL also forwards the FidelityFX entry points to the preserved original loader. That combination gives it a useful position in the startup chain: it can observe and adjust the troublesome call while retaining the underlying library.

This is an application-specific workaround. The source’s layout assumptions and device hooks are tied to the environment it was written for. A successful startup can come with a missing visual effect. The presence of “FidelityFX” in the filename also says nothing by itself about whether upscaling or frame generation has been validated.

The next step was a surprisingly small crafting recipe: one C source file, a Windows target and a compiler running on macOS. No Windows desktop was needed for this build.

Zig supports cross-compilation. The recorded target was x86_64-windows-gnu: the output had to fit the Windows x86-64 process inside CrossOver, even though the host Mac used Apple Silicon. Host architecture and output architecture are separate decisions.

For the historical build, I used community commit 436de811fcc8784dd0dfb6c9666077b34ca53d31 and the recorded ziglang version 0.17.0. The sequence below makes those inputs explicit. It builds the DLL; it does not install it into a game.

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 selects the Windows output platform, -shared produces a DLL and -O2 enables optimization. The final command records a SHA-256 fingerprint. My local artifact’s hash is in the downloadable build record.

A hash identifies particular bytes. It does not establish that a binary is trustworthy, and a different compiler environment can produce a different hash from the same source. Keeping the source revision, compiler, output target and test outcome together makes the build easier to examine later.

Install with an address, keep a way home

The Steam library was on an external drive, and the active bottle was not the first directory a default-path guess suggested. Passing the verified game folder directly avoided searching an entire collection of bottles and volumes.

After closing the game, the project’s installer replaced the loader with the proxy, preserved the original under amd_fidelityfx_loader_dx12_orig.dll and applied the path workaround:

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

Those commands assume the source checkout and the freshly built DLL are together, with the game directory substituted for the example. The backup was checked against the original. The retained installation then returned to the ordinary Steam launch, which was the workflow we wanted to repair.

To undo the workaround later, close the game and run the companion uninstaller from the same source checkout:

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

Updates can respawn the encounter

A game update or Steam’s file verification can replace the proxy with the shipped loader. If the same symptom returns, check the installed state and whether the fix still matches the new build before reapplying it. A repair that was appropriate on 10 October is not automatically appropriate after the next patch.

That is why the build record is part of the article. Future-me should get a map, not a note saying “I changed something in this folder and it worked once”.

What I would carry into the next debugging quest

Start by locating the failing stage. A return to “Play”, a black window and a broken scene are three observations with potentially different causes. Preserve the setup details, change one part of the chain and check which milestone moved. When a new error appears after a fix, it may mean the first blocker was removed.

This lesson travels well beyond games. A web app can have a resolved route and still fail while loading data. A service can start and still be unable to talk to its database. A compiler can finish and still produce an artifact that fails its first real workload. The useful question is always: what did this test actually establish?

The playful side of interfaces is something I also explored in Terrarium Studio’s browser-based 3D planner. This time, the side quest arrived without asking. Its most valuable loot was a clearer model of the system.