*Potential issues with this release on SteamVR, please DO NOT USE and update to latest!!!

OFXR Bridge v0.2.13.3 (V452)

A patch release: one fix on top of v0.2.13.2. Since v0.2.13.1, on Pimax
OpenXR and other runtimes that are not SteamVR, OFXR could report the full
refresh rate while the headset showed no extra frames at all. Reported with
MSFS 2024 on a Pimax Crystal Super, and confirmed fixed by the reporter on a
test build. Everything else is v0.2.13.2, and its notes still apply.

🛠️ 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.3

The generated frames arrive in time to be shown

Who was affected. Anyone running OFXR through Pimax OpenXR, Virtual
Desktop or another runtime that is not SteamVR, with a game that needs
most of the time available between two of its frames: a demanding game at a
high resolution, 3X Frame Gen above all. The report that found it was MSFS
2024 on a Pimax Crystal Super at its full resolution, with 3X Frame Gen at
72 Hz, on an RTX 5090. SteamVR users were never affected.

What you saw. OFXR's overlay said you were at your headset's refresh rate,
in green, but the headset did not look any smoother than without OFXR: it
showed the game's own frame rate. Lowering the resolution helped only a
little. The same game and settings on v0.2.12.2 worked. In the reporter's
log, 996 of every 1,000 generated frames were handed to the headset before
they were finished, so the headset showed the previous image instead.

Why. OFXR lets the game start its next frame at a chosen moment in each
cycle of the headset's refresh. Where that moment falls decides how much
time the GPU has to finish the game's frame and the generated frames
before they are due. Up to v0.2.12.2 the moment was wherever the session
happened to land, and it moved every time generation restarted, so a
session could end up in the right place by chance; the reporter's own
v0.2.12.2 log spent its first nine seconds in the wrong one before a
restart moved it. The hangar fix in v0.2.13.1 removed that chance: after
every restart the moment was fixed in the latest possible place, which is
also the one with the least time to spare. On a game that already uses
most of the cycle, nothing was ready on time.

What changed. OFXR now checks, about once a second, whether the
generated frames were finished when they were due. If two or more of the
last thirty were not, it lets the game start a step earlier; if all of them
were finished with a whole refresh to spare, it lets the game start a step
later, so you get the lowest latency the game and GPU allow. On the
reporter's machine it settles in about four seconds and stays there. The
v0.2.13.1 hangar fix is unchanged: in a light scene the moment stays where
v0.2.13.1 put it. SteamVR is unchanged.

What to expect. Where the game has time to spare, nothing changes. Where
it does not, latency returns to what v0.2.12.2 had on the same machine, and
the generated frames are shown again. On the reporter's machine the share of
generated frames handed over unfinished went from 99.6% to about 8% in the
same flight, down to 4% after a few minutes, and the headset ran smoothly.
The remaining few percent are the GPU at its limit at that resolution:
MSFS 2024 at 6572×6502 per eye in 3X leaves it about one millisecond to
spare per cycle. If you still see occasional skipped frames at a very high
resolution, pick the NVIDIA Fast backend or go one step down in your
headset's render resolution; that is where the headroom comes from.

If you are on Virtual Desktop and your game ran well on v0.2.13.2,
nothing should change for you, and if anything does, please send a flight
log: this fix was confirmed on Pimax OpenXR and tested in OFXR's own test
suite, but it has not yet been run on Virtual Desktop in a headset.

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 in v0.2.13.2 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\v452\. Read the
troubleshooting guide first: most problems are
solved there in a few minutes.