An unofficial build on
tig3rmast3r's v0.2.1.
A follow-up to 0.2.3_beta2 — one fix, nothing else changed.
Short version
If a game crashed at start-up on SteamVR since 0.2.3_beta1, take this build.
Assetto Corsa was the reported case: it crashed within a few seconds every time
on SteamVR, while working normally on VDXR. It now runs.
If nothing was crashing for you, this changes nothing you can see. Frame
delivery, pacing, the overlay and every setting behave exactly as in
0.2.3_beta2.
What was wrong
Since 0.2.3_beta1 the bridge opens a second, background connection to SteamVR
in order to read the compositor's own delivered-frame counters — that is what
made the overlay tell the truth and what the pacing is steered by.
That connection was opened and closed per OpenXR session. Most games create
one session and keep it, so the connection was opened once and closed at exit,
and nothing went wrong. Assetto Corsa creates and destroys its session three
times while starting up. It does that on every runtime, and it is perfectly
legal.
SteamVR ships its OpenXR runtime and its OpenVR client in the same binary,
vrclient_x64.dll. Opening our background connection into that binary and then
closing it left the next xrCreateSession through it reading a null
pointer, inside SteamVR's own runtime, with the bridge doing nothing but
forwarding the call.
Captured with a debugger: the fault is in vrclient_x64, and every session
created before our connection attached succeeded while the first one after
it died. In one run the connection attached three seconds later than usual and
the crash moved three seconds later with it.
The fix
The connection is now opened once per process and never closed. Sessions
after the first share it instead of opening their own, so there is no longer an
open-and-close cycle for a game's session churn to trip over.
Nothing else changed — the counters, the overlay, the pacing and the adaptive
margin all work exactly as before.
Who this affects
- Any title that recreates its OpenXR session while running, on SteamVR.
Assetto Corsa is the confirmed case; OpenVR-era titles reaching OpenXR
through a translation layer are the likely group. - Not VDXR, Oculus or PimaxXR — the bridge never opens this connection
outside SteamVR, which is exactly why Assetto Corsa always worked there. - Not single-session titles, which is almost everything else. For those the
only difference is that a connection which used to be closed at game exit is
now left for the process to take with it.
Known issues
- If SteamVR is restarted while a game is running, the bridge keeps its
original connection rather than making a new one, and the delivery counters
may stop being meaningful until the game is restarted. Restarting SteamVR
under a running game was never well supported; this makes it a little worse.
Report it if you hit it. - Hogwarts Legacy still sits around 81 rather than 89, unchanged from
0.2.3_beta2 and still under investigation. - The D3D11 fix from 0.2.3_beta2 is measured, not proven. The fault it
addresses is probabilistic, so a clean session does not demonstrate much. If
a D3D11 game still crashes inside the runtime, please report it. - Very high per-eye resolutions remain the hard limit, unchanged. Above
roughly 9 megapixels per eye the generated frame cannot be finished early
enough to be shown. - Selecting the NVIDIA backend without an NVIDIA card silently does nothing.
On AMD or Intel leave the backend on FidelityFX, the shipped default.
Everything else is unchanged from 0.2.3_beta2
The frame delivery work, the D3D11 fix, the NVIDIA backend recommendation, the
odd-looking frame times in fpsVR and the optical flow resolution setting are all
as described in the 0.2.3_beta2 notes.
Installing
Unzip anywhere and run OFXRBridgeTray.exe, then Arm bridge. Keep
OFXRBridgeTray.exe and the ofxr folder together. If you have an earlier
version armed, disarm it first.
Tested
- Assetto Corsa on SteamVR — the reported crash, now fixed
- Skyrim VR through OpenComposite, with the FUS modlist
- The Callisto Protocol and Hogwarts Legacy (UEVR)
on SteamVR with a Pimax Crystal Super OLED, on the NVIDIA OFA backend.
This is an experimental beta and compatibility is not universal. Please report
results — working and not — on this fork's GitHub Issues, with
an OFXR flight log where you can. Enable one by setting logging_enabled=1
under [diagnostics] in ofxr_bridge.ini; logs are written next to the armed
layer under %LOCALAPPDATA%\OFXR Bridge\RuntimeLayer\v271\.