Open Framegen before a live test. The tool preserves existing FPS limits and image-quality settings by default. The refresh rate is read from the headset software (Pimax Play's runtime as it runs, or SteamVR's setting on the Sboys route); the number field is only for setting it by hand.
OFXR (the djules75 fork 0.2.9.1 with DCS Control's patches) produces one (2×) or two (3×) generated frames per rendered frame, or switches between them (Auto). Its OpenXR presenter handles display pacing. The manager uses DCS's real graphics.maxFPS option for a rendered-frame cap; it does not write a fictitious OFXR limiter key. OFXR is optical-flow frame generation, separate from NVIDIA DLSS Frame Generation.
| FPS limit mode | DCS change | Intended use |
|---|---|---|
| Preserve existing DCS limit | No change to graphics.maxFPS |
Keep an existing setup; the detected cap appears in the frame-rate summary. |
| Runtime pacing | Set cap to 300 FPS | Leave DCS cap headroom while investigating OpenXR pacing. This is not an unlimited mode. |
| Match refresh | Refresh / 2 with OFXR; full refresh with framegen off | Explicit comparison of a matched rendered cap. A 90 Hz selection writes 45 FPS with OFXR and 90 FPS without it. |
| Custom rendered-frame cap | User value, 30–300 FPS | Fine-tune real game FPS independently of display refresh. Fractional values are preserved. |
The supported range matches the installed DCS MissionEditor/modules/Options/optionsDb.lua: graphics('maxFPS'), slider 30–300, default 180. This version does not assume that zero means unlimited. The original value, including a missing field, is backed up and restored. Match refresh recalculates when framegen is enabled or disabled; the wizard shows that derived cap in Review.
A cap is a ceiling, not a performance guarantee. For a 90 Hz headset, 45 rendered FPS can supply up to 90 fresh frames/s with one intermediate frame per rendered frame. A 30 FPS cap can supply at most 60 before other bottlenecks. GPU/CPU load, failed synthesis, gaze/composition work and runtime presentation can reduce fresh output. A 300 FPS DCS cap does not force a 300 FPS render loop through OpenXR.
- Disable DCS desktop VSync explicitly writes
graphics.sync = false. Leaving it off preserves the original value. This does not disable OpenXR synchronization or rotational timewarp. - NVIDIA / RTSS / other limiters are a check you do yourself, listed by preflight: inspect NVIDIA global and DCS program Max Frame Rate and Background Application Max Frame Rate, plus the DCS RTSS profile. The tool does not read or modify these driver settings, so it no longer asks you to report them (earlier versions did; those saved answers are ignored). An external cap's position relative to OFXR must be established live.
- Runtime motion smoothing (Pimax Smart Smoothing, SteamVR motion smoothing) is likewise a preflight check you do yourself when frame generation is on: establish OFXR cadence with this second interpolation stage disabled first. The tool does not change the runtime.
- Legacy autoexec.cfg is detected beside the chosen options.lua. Simple
max_fpsassignments are reported without executing Lua. Unsupported commands remain unknown. The file is preserved; creating or changing it after Apply invalidates the saved launch check so pacing cannot silently change. - Detected RTSS processes are reported as process facts. Their presence does not prove a cap is active, and their absence does not prove driver caps are off.
Use Run preflight for fresh detected settings and warnings. Review files lists the exact previous and next DCS scalar values, including caps and VSync. Launch DCS (or Apply without launching) writes those values with the launch configuration. Launch checks treat an edit to an owned cap as a change: the profile is restored and applied again, and a conflicting edit stops at Recovery. Recovery preserves conflicting user edits and reports them.
- Confirm the actual headset mode and enter its refresh rate. Keep all image-quality values fixed.
- Check external/background caps and runtime interpolation. Begin with one cap strategy at a time.
- Compare Preserve or Runtime pacing against Match refresh in the same cockpit scene. Match refresh is an optional test, not an automatic optimization. If either a runtime or another layer already reduces application cadence, do not add a second half-rate mechanism blindly.
- Measure real application frame time, fresh synthetic frames, dropped frames, HUD clarity, head-motion latency and comfort. OFXR's output overlay counts accepted OpenXR submissions, including possible presenter repeats; a 90 FPS overlay alone does not prove 90 fresh images reached the panel.
- Exit DCS, restore, then repeat for framegen, foveation and the combined neural pipeline. Export a fresh diagnostic report with the cap and refresh recorded.
Framegen → Smooth mouse cursor (off by default; smooth_cursor=1 in the profile's ofxr_bridge.ini, OFXR fork patches 0010 and 0011). In the cockpit DCS draws its VR mouse cursor as a spot about 2° across along the mouse ray (enlight.dll's RayCursor, built by CockpitBase.dll with a 1° half-angle; shader Bazar\shaders\enlight\rayCursor.fx): the current cursor image (the yellow cross or the green sight), lit by the scene's exposure, brighter at its centre, mixed into the frame before tone mapping and DLSS with 30 % of the panel still showing under it. On a Pimax Crystal Super's 5424-px eye image that is about 65 px, twice the 32-px image. The menus use a plain white dot (149). Optical flow cannot carry either: each generated pixel takes the motion found at its own position, and a cursor that moves further than its own size between two real frames has no motion vector that lands on it, so a generated frame shows it faded at both places.
With the option on, and only while the Windows cursor moved within the last 5 s, OFXR finds the cursor in both real frames of each pair and in both eyes (a few compute passes on the GPU, no read-back), then redraws a small area around both positions in every generated frame: the cursor is taken out of both real frames there and drawn once more at its position for that frame's moment (half way in 2×, one and two thirds in 3×), copied pixel for pixel from the newer real frame. The rest of the generated frame is untouched, and so are the real frames. The cursor images are DCS's own, read from bin\Visualizer.dll in the running game (or from DCS.exe's folder written as cursor_templates): the cockpit's yellow cross (147) and green sight (145), and the menus' white dot (149). The control markers DCS shows over a switch are left out (0011): they last only while the mouse rests on a switch, when there is nothing to smooth, and every image searched costs a pass and is one more possible look-alike. Nothing of DCS is shipped; a plain arrow stands in if no image is found. The match allows the cockpit spot's colour shift (yellow arriving orange counts as yellow; grey or another primary does not) and sizes from 0.4 to 3.2 times the image; from twice the image up, the final placement compares each image texel's whole footprint, so the redraw lands on the exact pixel.
A pair is redrawn only when every check passes: a confident match in both frames and both eyes, no look-alike within 48 px scoring nearly as well, the same cursor at the same size and a consistent vertical offset in both eyes, both eyes moving by the same amount, and no movement while the mouse was still. Otherwise the generated frames are exactly what they would be without the option.
Measured on an RTX 5090 (NVIDIA optical flow, 50 % input, 2 × 2560×2560 and 2 × 3200×3200): finding the cursor costs about 0.05 ms per pair while it is tracked and 0.17–0.22 ms on the pair that first finds it; it runs while the optical-flow engine works, so a whole pair took only 0.02–0.03 ms longer. The redraw adds nothing measurable to the composition (0.16 / 0.26 ms with and without).
To check it in a flight, turn on OFXR log and fly once with the option on and once off, moving the mouse over the cockpit and over a switch (the cursor changes to a green marker there). The log has one op=smooth_cursor result=1 line a second while it is on: a holds four 16-bit counts, pairs judged (bits 0–15), redrawn (16–31), searched from scratch (32–47) and tracked (48–63); b the pairs left alone because the cursor was not found (0–15), matched too weakly (16–31), had a look-alike near it (32–47) or the eyes disagreed (48–63); c an impossible jump (0–15), too much moving to search (16–31), pairs with the mouse idle (32–47) and the detection's mean GPU time in µs (48–63). op=smooth_cursor result=2 once per swapchain says how many cursor images were loaded and from where (b: 1 the game, 2 cursor_templates, 3 the built-in arrow). op=smooth_cursor result=3 (0011), in a second with matches too weak, gives their mean score ×1000 (a, 720 is needed), their mean size step ×100 (b; steps 0–9 are 0.4, 0.5, 0.63, 0.79, 1, 1.26, 1.59, 2, 2.52 and 3.17 times the image) and the latest rejected match packed in c (image bits 0–7, size step 8–15, score ×255 16–23, best look-alike ×255 24–31). Redrawn should be close to judged while you move the mouse over the cockpit; a run of "not found" or "matched too weakly" means DCS draws the cursor in a way the matching does not recognise — please send that log.
In the first flight with 0010 (2026-10-06) only 87 of 8286 pairs were redrawn: 6576 matched too weakly. The matching expected a sprite drawn as the image is, and the colour check alone cut every orange-lit yellow cross to a score of 0; the cockpit spot was also at the very top of the size range. 0011's offline tests draw the spot as DCS does (radial brightness, 30 % of the panel under it, orange) at 2× in 2X and 2.5× in 3X: both are redrawn exactly, with nothing left at either real position.
Diagnostic captures (0011): with the OFXR log on, the smooth cursor also saves up to 8 captures a session, at least 5 s apart, while the mouse moves, next to the log: cursor-capture-<pid>-<n>-previous.bmp and -current.bmp (384×384 px of the left eye around each real frame's best match), -overview.bmp (the left eye at an eighth of its size) and -info.txt (each frame's match: status, position, image, size step, score, look-alike score). The log gets op=smooth_cursor result=4 per capture. They show what the matching actually sees, for the cases the scores alone cannot explain.
Video memory in the log (0011): with VRAM in the headset panel on, the OFXR log also gets op=vram_status result=1 once a second, the panel's figures in MiB: a this process's resident use (bits 0–31) and the budget DXGI gives it (32–63), b every process's use of the GPU's dedicated memory (0–31) and its size (32–63), c 1 while DCS's window is in the foreground (Windows gives a background process a smaller budget).
The release's manager and actual WebView2 tests cover both runtime routes, custom/derived caps, precise numeric values, preview invalidation, applied launch checks, restoration and the combined pipeline with the supplied signed DLSS-NR runtime. Native tests exercise OFXR's SteamVR continuous presenter while the application deliberately pauses below the half-refresh target. The exact bundled V116 DLL also passes this delayed-application fixture: presentation continues and frame order is retained. Repeated presentation during a pause is not fresh frame generation.
These fixtures do not establish DCS's actual limiter placement, the live Pimax/Sboys compositor, physical scanout or latency. No real game files or driver settings were changed during this verification.
Primary references: OFXR source and documentation, OFXR overlay semantics, NVIDIA Max Frame Rate and background-limit reference. DCS's cap and desktop VSync fields were verified directly in this PC's installed options database.