OFXR Bridge v0.2.13.2 (V443)

A maintenance release on top of v0.2.13.1, with four fixes. On SteamVR,
games that restart generation often, MSFS 2024 above all, no longer drop to
half the headset's refresh rate because of a change v0.2.13.1 made.
D3D11 games that stuttered in one eye, reported with IL-2 Great Battles
without OpenXR Toolkit, now get both eyes from the same moment of the
frame. Windows and HUD panels that appear inside the headset, such as
CheekyFoveatedDLSS's settings or Skyrim VR's HUD, no longer pause frame
generation, and on Virtual Desktop they no longer cost frame rate for the
rest of the session. And the long dips to about 50 fps reported on a Steam
Frame are gone. Each fix was confirmed by its reporter on a test build.
Everything else is v0.2.13.1.

Built on
tig3rmast3r's v0.2.1.

🛠️ Not working, or not feeling smoother?

➡️ Read the troubleshooting guide first

It checks in one step whether OFXR is running in your game, then lists the
usual causes and fixes: OpenVR games, running as administrator, the game's
frame rate, frame smoothing in your VR software, and running out of VRAM.

New in v0.2.13.2

SteamVR: MSFS 2024 no longer drops to half rate

Reported with MSFS 2024 and 3X Frame Gen at 90 Hz through SteamVR, on an
AMD RX 9070 XT and on an RTX 5090 with a Pimax Dream Air: lower frame rates
and stutter on v0.2.13.1 than on the builds before it. In the logs, the
game fell from about 30 frames a second to 16 to 19, and SteamVR spent most
of the session at half the refresh rate.

v0.2.13.1 fixed hangars and menus dropping to 60 fps by pacing the first
frame after generation starts over. MSFS 2024 starts over several times a
second on SteamVR, and right after those paced frames SteamVR's own frame
submission stalled for many milliseconds, several times a second. SteamVR
read that as a game that could not keep up, and halved the refresh rate.

On SteamVR, the first frame after a restart is now let through as it was
before v0.2.13.1. Virtual Desktop, Pimax OpenXR and every other runtime keep
the v0.2.13.1 hangar fix unchanged. On the test build, the Dream Air
reporter is back to 90 fps with 3X Frame Gen.

D3D11 games: no more stutter in one eye

Reported with IL-2 Great Battles on a Quest 3 through Virtual Desktop:
stutter in the left eye only, which disappeared as soon as OpenXR Toolkit
was enabled.

IL-2 hands its first eye over almost 4 ms before it finishes the frame.
D3D11 games reach your headset through OFXR's D3D11 bridge, which copied
each eye when the game handed it over. For the first eye that copy could
come too early and show the eye one frame late. OpenXR Toolkit hid the
problem because it hands both eyes over itself at the very end of the
frame.

The bridge now copies both eyes when the game ends its frame, for every
D3D11 game, as v0.2.12.2 already did for D3D12 games such as MSFS 2024.
Vulkan games are unchanged. The reporter confirmed on the test build that
IL-2 runs without the stutter, with or without OpenXR Toolkit.

There is no menu entry. To go back to the earlier behaviour for diagnosis,
close the tray, set capture_at_end_frame=0 under [tray] in
%LOCALAPPDATA%\OFXR Bridge\tray.ini, and start the tray again. That
switch covers D3D12 and D3D11 games together.

Virtual Desktop: overlay windows no longer cost frame rate

Reported with IL-2 Great Battles on Virtual Desktop and
CheekyFoveatedDLSS:
as soon as Cheeky's settings window was opened with F8, the game fell from
111 to 94 fps and its latency rose from 5 to 12 ms, and it stayed there
after the window was closed.

Two things went wrong. Opening a window like that inside the headset made
OFXR pause generation for about a second while the new window's images
were set up; that pause is gone now, for every game and on every runtime
(see the Steam Frame fix below). And after any pause, OFXR is meant to go
back to the mode the game was running in. In IL-2 it did not: early in
every session IL-2 moves its frame loop from one thread to another, and
that move made OFXR keep the game in its slower mode for good once
anything had paused generation.

OFXR now goes back to the mode the game had before the pause. This change
applies only on Virtual Desktop, and only to a game OFXR had already put in
its faster mode in that session; it never changes the mode a game starts
in. In the reporter's logs from the test build, with the window open,
repeated frames fell from about 6 a second to under 2.

Steam Frame: no more long dips to about 50 fps

Reported with Skyrim VR (Mad God's Overhaul) on a Steam Frame at 72 Hz
through SteamVR, with the NVIDIA backend: the game dropped to about 50 fps
in episodes that grew longer until they no longer ended. The logs showed
two separate causes.

Waiting instead of starting over. Some episodes started when OFXR went to save a
frame and found the GPU still reading the previous frame from the same
place. OFXR used to start generation over at that point, and starting over
is what made the next frames arrive in a bunch and the GPU fall further
behind, so it happened again a moment later. OFXR now waits for the GPU to
finish, for at most one refresh period, and only starts over if it still is
not done. In the reporter's test build this cause was gone, and the game
ran at a steady 36 real and 36 generated frames a second until the second
cause appeared.

HUD panels. In some scenes the game adds and removes small HUD panels
every second or two, each one a new image the game creates. OFXR paused
generation for a full second every time an image like that was created,
and on SteamVR it also left its faster mode each time, so in those scenes
generation was off most of the time and the headset showed the game's own
45 to 50 frames a second. Creating an image no longer pauses anything.
Removing one still makes OFXR start over, for a single frame, as it did
before, and so does the game using a new image for its main view, as when
it changes resolution. This applies to every runtime and game, and it is
also what removes the pause when CheekyFoveatedDLSS's window opens.

With both fixes the reporter played for half an hour without a dip. If you
still see dips like these, on any headset, switch the flight recorder on
while it happens and send us the log.

Known issues

• SteamVR: light scenes are no longer paced after a restart. Without
  the v0.2.13.1 pacing on SteamVR, a scene the game renders very quickly,
  such as a hangar, a menu or a loading screen, could fall back into the
  60 fps loop described in the v0.2.13.1 notes. The wait added for the
  Steam Frame fix removes the step that kept that loop going, but it has
  not been tested in a hangar on SteamVR. If you see a light scene stuck
  below your refresh rate, please send a flight log.
• Your game has to reach half your headset's refresh rate, with some
  headroom (45 fps at 90 Hz, 50 at 100 Hz), for every frame to come out
  evenly. Generating frames costs GPU time too: No Man's Sky ran at 94 fps
  without OFXR on our test machine and reached an even 100 at 100 Hz, but
  113 to 115 at 120 Hz. If your number stops short of the refresh rate,
  choose a lower refresh rate, or lower the per-eye resolution or the
  optical-flow resolution. The
  troubleshooting guide
  has the details.
• Pausing is not the same as disarming. A paused game still runs through
  OFXR, and on SteamVR that can cost frame rate in games such as MSFS 2024.
  To rule OFXR out of a problem, disarm it and restart the game.
• Check your real per-eye resolution. SteamVR's global resolution and a
  per-game resolution multiply: 200% global with 200% for the game gives
  four times the pixels, and OFXR's memory grows with them. The
  troubleshooting guide explains how to read the real value from a flight
  log.
• SteamVR: turn off Motion Smoothing and "fixed frame rate at half" for
  the game in SteamVR's per-application video settings. They fight with
  OFXR's own pacing.
• No FPS overlay in Vulkan games, so no pause symbol there either. The
  tray entry still shows whether generation is paused.

Installing

Unzip anywhere and run OFXRBridgeTray.exe. It arms the bridge by itself.
Keep OFXRBridgeTray.exe and the ofxr folder together; it holds the OpenXR
layer, its settings and the Vulkan layer. If an earlier version is armed,
disarm it and close its tray first.

Please report results, working or not, on this fork's
GitHub Issues, with an OFXR flight log where you can. To
record one, enable Bridge flight recorder in the tray, reproduce the
problem, then use Open bridge logs. Logs are written under
%LOCALAPPDATA%\OFXR Bridge\RuntimeLayer\v443\. Read the
troubleshooting guide first: most problems are
solved there in a few minutes.