[monsterlag]

Requesting more than 60 native frames per second must also change the timestep consumed by the game. This experimental change couples effective pacing to a valid committed clock input and caps pacing at 60 while movie pictures are active.

The default remains 60 Hz. HOS_FPS_TARGET=61 through 120 opts in with Real time and normal VI pacing; Per frame and disabled VI pacing retain the 60 Hz policy. No private clock override is required. The hook preserves the original load/conversion/quotient/downstream calls and changes only the low four vector bytes when a valid committed sample exists.

Standalone generation installs one verified, idempotent MAIN hook. Missing, multiple or altered targets fail before writes; stale generated code is rejected. No generated game code, SDK/reference functions, binaries, profiles, captures or game data are included.

Current head 38ecf72 normally merges upstream 4cfa08f, including the accepted API4 aspect change. Native policy, clock patch, movie handling and tests are byte-identical to runtime-tested 3b4cf65. The six-case runtime numbers below belong specifically to 3b4cf65/API3 on released device-lost-fix/ff10b2d.

Validation:

• All four checks passed at 38ecf72: Windows/Linux source checks, SPIR-V validation and AppImage build. These do not replace runtime validation.
• Nine clock/window/policy regressions and the upstream text-speed check passed with audited GNU Clang 23.1.5. The window-aware implementation preserves upstream default 5 and clamps1–5. Earlier strict MSVC/Clang checks include original-load negative, register preservation, transitions, idempotence and stale-generation rejection.
• Fresh normal generation installed the hook without private generated edits. The latest released-source matching build reused that generation only after proving identical actual transformation/model/HLE/runtime/profile inputs and all 7,403 tool/dependency bytes; changed version/renderer objects rebuilt successfully.
• Windows/RTX 5090, Real time, Auto resolution, FG off, identical private checkpoint: all five single runtime guards passed. Controls measured 60.0/60.0/60.0 FPS; requested 70 measured 69.9 FPS, requested 75 measured 70.9 FPS. The guard remains at least 92% of the requested rate and actual above 60 for high-rate cases. Late route checks measured 69.6/70 and 69.2/75.
• Requested 75 movie playback visibly progressed through the opening story and sleeping/awake Link. Effective pacing stayed 60 Hz; PTS/wall slopes were 1.000043 and 1.000343, with maximum logged offset 0.02 s. Physical audio was not verified.
• All six sessions closed normally. Walking was observed in several runs; an airborne jump was captured in requested 75 and the final60 control. Earlier jump transients and the final control's walk transient were missed.
• A separate local API4 integration (587a638, this head plus vulkan: initialize presentation upscaling independently of frame generation #417) built successfully with matching host/renderer interfaces. A fixed-100%-resolution, FG-off requested-70 pilot measured 69.2 FPS and visibly moved to the path short of Mido, with no dialogue or visible NPC contact. It closed normally. The rock-to-path transition was not continuously captured, and this unmeasured pilot does not establish speed or physics fidelity; it also includes vulkan: initialize presentation upscaling independently of frame generation #417 beyond this PR.
• A subsequent, separately frozen 587a638 fixed-resolution 60/70/60 short-route comparison completed with guards 60.0/68.0/60.0 FPS and late checks 59.7/69.4/60.0. Each session used the same one-second input, fresh checkpoint, screenshot cohorts and 10-snapshot observation cadence, and closed normally. No sampled NPC contact/dialogue/fall/reset/collision appeared; continuous terrain clearance remains unverified.

This remains a draft. The three 60-control displacement measurements span 1.45%. Requested 70/75 distances were 1.20%/2.00% below the control mean, both outside the observed control range. Mido interaction may constrain endpoints, and UI capture timing differed, so these measurements do not establish game-speed or physics fidelity. No stable 75 FPS, 120 FPS performance, wider progression or exact jump-timing claim is made.

The newer short-route weighted displacements were 4.216292/4.068889/4.216342 pixels. The 70 estimate is 3.50% below the two-control mean and outside their observed span, but all three nearest-integer-centroid distances are identical at 4.123106 pixels. Map-registration correlations are weak (0.247–0.399), and fractional centroids have no calibrated subpixel accuracy. This does not establish either a speed change or precise speed/physics fidelity. The measurements and their limitations are preserved; no displacement acceptance tolerance was invented.

Physical controls/audio, wider progression, AMD/Intel/Linux runtime, handheld mode and current-source Per-frame/no-pacing runtime behavior remain unverified. A longer unobstructed route or a better calibrated state measurement is still needed for fidelity. Keep the feature opt-in and experimental with the default 60 path intact.

[NotRexed]

Closing to keep the queue clear — please rebase on current main and reopen; thanks!