VectorXR v0.20.0

VectorXR 0.20.0 - Faster, Sharper Frame Generation, Turbo on SteamVR, and Eleven Languages

A major Frame Generation release. Generated frames cost noticeably less GPU time and keep cockpit detail sharper, Dynamic Interpolate can now use NVIDIA's hardware optical flow with an automatic fallback, and Frame Generation is far more careful about the depth games provide. Turbo now works on SteamVR, where it used to switch itself off. The app, tray, On-Screen Display and installer are available in eleven languages. This release also includes every fix prepared for 0.19.4.

Frame Generation

• Less GPU work per real frame. Matching motion and preparing generated frames now take less GPU time. In replays on an RTX 5090 at 5424x5356 per eye, Frame Generation's GPU time fell by about 20%, or 0.7-1.2 ms per real frame. In a DCS flight at 2x with shader flow, it measured about 0.6 ms per real frame.
• Sharper cockpits. Generated frames now use cubic resampling for nearby content in games that provide usable depth. In MSFS replays, cockpit fine detail in generated frames rose from 83-88% to 92-98% of the real frames'. Interpolate also keeps more valid cockpit motion through small movements.
• Dynamic Interpolate can use NVIDIA hardware optical flow. Choosing NVIDIA hardware as the motion source now applies in Dynamic too. A new option under Motion source, Fall back to Shader when hardware flow can't keep up (on by default), switches Interpolate to shader flow when hardware flow repeatedly can't keep pace, and tries hardware again later. Turn it off to stay on hardware flow. The OSD shows which source is active, and the log records why it switched. GPUs without supported NVIDIA optical flow use shader flow. In a 16-minute MSFS flight, Dynamic Interpolate on hardware flow held about 90 fps.
• Auto gives a lower multiplier a fair trial. A failed step-down attempt no longer disrupts the game for a full settle period, and a short burst of late frames during the switch no longer rules out a multiplier the game can sustain. Changes to settings, the runtime's clock or the output images still get the full settle.
• The OSD shows when depth is helping. While generated frames use the game's depth, the line under the Frame Generation row ends with "uses depth". Depth that a game sends but that fails the checks is not noted.
• An adaptive lead ceiling, on by default. When Frame Generation times the game so far ahead that new captures replace images it still needs, the ceiling brings that lead down. It checks the result and backs out a lowering that keeps making frames late, so each game settles on its own limit instead of one fixed value.

Game depth

• Empty depth is never used. A depth image cleared to a single value no longer becomes a false near surface that warps the whole view. Depth a game leaves clear in menus keeps being checked until real scene depth arrives. Corrections to near/far range and scale now need clear evidence, and sparse but usable depth can still be accepted.
• Depth from one eye can help both. When a game supplies useful depth for only one eye, Frame Generation can use it for the other eye too.
• Steadier depth decisions. Depth contradicted by the other eye is rejected, and depth that was dropped must show sustained good readings before it returns. A usable replacement can take over directly.

Turbo

• Turbo works on SteamVR. SteamVR rejects a frame whose display time is older than its previous frame's, and Turbo's frame pipelining could submit such frames, most often in DCS. SteamVR dropped them, and after three in a row VectorXR switched Turbo off for the session ("XR_ERROR_TIME_INVALID" in the log). VectorXR now never submits a display time SteamVR will refuse, and gives the game the timing of the refresh its frame will actually reach, in both Async and Sequenced pacing. In a 15-minute DCS flight on SteamVR with Turbo, no frame was rejected. Runtimes that accept such frames, such as Pimax's, behave as before.

Languages

• The app, tray, OSD and installer in eleven languages: English, Simplified Chinese, Traditional Chinese, Japanese, Korean, German, French, Spanish (Spain), Portuguese (Brazil), Polish and Russian. Choose the app language under Settings. The OSD can follow the app or use its own language, and its columns fit the translated labels. The translations began as machine translations, and native-speaker corrections are welcome. Patch notes remain in English.

Quadviews eye tracking

• Eye tracking can continue while another window has focus. On SteamVR, a desktop or app window floating in VR (for example on Steam Frame) takes input focus from the game, which stopped Quadviews eye tracking until you returned to the game. VectorXR now keeps using your gaze in that state whenever the runtime still provides it. When it doesn't, the focus area centres on your head as before and follows your eyes again once the game has focus.
• The log says when the eye tracker sends nothing. If the runtime connects eye gaze but no gaze arrives for 10 seconds while the game has focus, the log says the headset's eye tracker isn't delivering data and suggests checking its software. Toggling eye tracking off and on in the headset's software can restart a stuck tracker.

VectorXR Enabled

• Off now turns everything off. Switching VectorXR Enabled off hides the OSD and stops its bindings, sounds and performance sampling, Frame Generation toggles, head prediction, the Quadviews visualization and focus sharpening. Starting a game with it off also leaves eye-gaze input untouched. Switching it off during a session stops generated frames at once; the session's four-view layout, Frame Generation pacing and graphics bridge stay until the game restarts.

DCS

• No more ghosts in menus with hardware flow. DCS menus could show shifted copies of the menu in the black surround, and the Mission Editor could show ghost tiles on plain backgrounds. Hardware optical flow now keeps flat and black areas still when the image calls for it.

Fixes from GitHub issues

• Games using the REAL VR mod start with Frame Generation on (#118). REAL VR wraps the game's Direct3D 11 device, and the wrapper refuses the shared images Frame Generation's Direct3D 11 bridge needs; VectorXR only found out after the game had its swapchains, so the game failed to start (seen in Avatar: Frontiers of Pandora). VectorXR now tests the device first and, if it can't share images, runs Frame Generation directly on the game's Direct3D 11 device, with somewhat more latency than the bridge.

Status file for other tools

• A public, documented status file. Tools can read %LOCALAPPDATA%\VectorXR\api\status.json, a versioned interface that only gains fields over time, separate from VectorXR's internal relay. It identifies the game and session and includes Frame Generation's state and rates, the game's target rate, refreshes per real frame, runtime frame holding and Auto's step thresholds. Targets account for runtimes that hold frames to every second refresh, fields no longer freeze after generation stands down, and the file is removed when its session ends, without touching another game's file. See docs/status-api.md.

Other fixes

• Safer Vulkan shutdown. The graphics bridge waits for the game's last rendering before destroying its images, keeps them alive if it can't confirm that work finished, and no longer hands an image back to a game that is already shutting down.
• Startup with stacked OpenXR layers. An extension check no longer reaches OpenXR Toolkit through a layer between them, such as OpenKneeboard, before the game's OpenXR instance exists, which could crash at startup.
• Input reconnects after unusual session endings. Missing input devices return to normal reconnect checks after a session ends, and a runtime that refuses to end a session no longer reintroduces periodic hitches.
• Video memory reports include cached hardware-flow images kept after a motion-quality or view-layout change.
• Capture requests can be repeated without the capture script waiting indefinitely.
• More useful support logs: Frame Generation summaries show the lead and prediction horizon reported to the game, and pacing diagnostics record slow runtime submissions and Turbo display times the runtime rejects.
• For developers, the local signing helper refuses outdated sources and mismatched staged manifests or sounds.

Known issues

• In helicopters, Interpolate can show artifacts around the rotors and in the sky behind them.
• On Varjo headsets with Quadviews, focus sharpening is off in DCS while Frame Generation runs.
• On Varjo headsets with Quadviews, overlays such as OpenKneeboard are drawn at the Peripheral resolution outside the focus area, and can look jagged there at low Peripheral settings. Raise Peripheral (1.0 matches Varjo's default) if overlays matter more than the performance gain.
• Star Citizen's depth images currently arrive empty, so Frame Generation runs without depth there.
• Turbo prevents runtime reprojection such as SteamVR Motion Smoothing from working. Use one or the other.