[LeonardoBai12]

Ocarina of Time played in slow motion whenever it ran below 60 fps. Its frame loop (main+0x6e6be0) computes each frame's step as a constant over its target rate and never reads the clock, so one frame is one step however long it took.

gunvalk found this in Lichii PR #216. Lichii is GPL-3, so this was written here from those facts, not copied.

The change

• A stub at main+0x6e6cc4 keeps the game's own step and takes the measured frame time when that is longer, so the step never falls below the original.
• The host writes the frame time at each present, as the mean of the last 8 intervals, with a single stall capped at 0.1 s and the step capped at 4/60 s.
• The host measures only for a main whose stub marks the state page, so other games are not touched.
• DM_FRAME_DELTA=0 turns it off.

If #1497 merges first, the two stubs share FRAME_STEP for this build and patches.py needs a small merge: one function that calls both.

Tested

• On an M1 Pro with 16 GB, in a fork that also carries Scale decoded NDVE movies on Metal and skip matched reconstruction #1331, A GPU-only pool's render targets share one placement heap: Ocarina of Time's 3 GB of render targets fit in 0.7 GB #1453, Add a render-scale ceiling for Ocarina v131072 #1497, AV1 on dav1d decodes frames in parallel, each picture with its packet's timestamp, outside the decoder lock #1377 and AV1 pictures by the movie's clock: a game slower than its movie skips late pictures instead of playing the movie slowly #1379: Link, cutscenes and collision run at normal speed at 20 to 37 fps in Kokiri Forest. Before, the same scenes were in slow motion. Sessions were a few minutes long.
• Alone on main, by PucaVaz on an M4 MacBook Air (see the comment below): game time against wall time was 0.998 to 1.000, against 0.50 at 30 fps without it, with no GPU errors.
• Against Ocarina of Time: frame step in whole vsyncs (fps_target 60, 30 when 60 does not hold) #1584, by PucaVaz on the same M4 with byte-identical shaders (see the comment below): both keep real time. Uncapped, Ocarina of Time keeps real speed below 60 fps: its frame step follows the measured frame time #1543 ran 44–45 fps walking, against 27–30 for Ocarina of Time: frame step in whole vsyncs (fps_target 60, 30 when 60 does not hold) #1584 at its 60 target. At a 30 fps cap the two behave the same.
• t_fstep: 83 checks pass.
• test_oot_real_speed.py runs the emitted stub under Unicorn. It skips without Unicorn, as test_oot_render_scale.py does.
• test_docs.py passes.

Not tested

• scripts/regress.py check was not run: Ocarina of Time is the only game on this Mac.
• The 30 fps mode of the game's fcsel was checked only in the Unicorn test.

🤖 Generated with Claude Code

[PucaVaz]

Tested this change on an M4 MacBook Air (24 GB, macOS 27.2), cherry-picked alone onto main 75c1a8c (no conflicts), in scripted runs from the Kokiri Forest autosave at Link's house: game time against wall time was 0.998–1.000 with the change on, against 0.50 at 30 fps and 0.67–0.70 at 40–42 fps with it off; the same timed walk to the door took 1.5 s at 30 fps and uncapped with the change, 3.0 s without it at 30 fps. No GPU errors, footprint 10.2–10.8 GB.

With the change, DM_FPS_TARGET=30 applies (main's fps_present_cap logs not applied without it), but the launcher doesn't offer a frame-rate choice for this game because its profile's fps_target is 0, so a player can't pick 30 fps from the launcher. In fullscreen on a fixed 60 Hz screen, a 30 fps cap also ran into a display-link problem (#1554, fix in #1555). Full numbers in #1265.

[LeonardoBai12]

Thanks @PucaVaz, this is very helpful, especially testing it alone on main. I added your result to the PR description. I am leaving the launcher frame-rate choice out of this PR to keep it small, since it needs a separate decision about the profile's fps_target. I can look at it in a follow-up if that is useful.

[PucaVaz]

Compared #1543 and #1584 in game on an M4 MacBook Air (24 GB, macOS 27.2, built-in 60 Hz screen).

Setup. Two Mac apps from the same tree: main b2d46b8 + #1544 + #1555, one with #1543 (f301c698; the later commit only changes the test) and one with #1584 (bf5dc97).

• Same shader chain, 5c852d7989ac.
• The shader libraries (all 33,925 metallibs) and the pipeline archive are byte-identical between the two apps, so only the frame step differs.
• Handheld, DM_UPSCALER=game, windowed (2560x1440).

Route. Scripted runs from the Kokiri Forest autosave in Link's house: 60 s in the house, a timed walk to the door, out of the door, Saria's greeting, 8 screenshots on the balcony, then 180 s of scripted stick pushes outside (the walk). The runs alternated between the two apps.

Game speed: both run at real time.

• Ocarina of Time keeps real speed below 60 fps: its frame step follows the measured frame time #1543 (game step from the measured frame time: on): the step rebuilt from the present intervals, as nvn_fdelta_next computes it, gives 0.998–1.000 game s per wall s in every phase.
• Ocarina of Time: frame step in whole vsyncs (fps_target 60, 30 when 60 does not hold) #1584 (frame step cap 0 → 60 fps): the host's frame step: game time lines read 1.000 in every 1,800-present window (the door's included), except the window with the save load (0.977–0.983) and the one with Saria's greeting and the 8 balcony screenshots (0.995). They count state +0x30, which only the controller-output stub increments.
• Timed walk, six 0.5 s stick pushes with a screenshot after each: the door view appeared after 1.5 s of stick in all 10 runs of both. At half speed it took 3.0 s.

Frame pacing (house = 60 s idle, walk = 180 s outside):

	runs	house fps	walk fps	walk frame p50 / p95 / p99	walk frames > 60 ms	walk on-screen 1 / 2 / 3 vsyncs	walk on-screen sd	present → display p50
#1543 uncapped (its default, fps_target 0)	2	51.6–52.1	44.4–45.0	20.9 / 30.1–30.2 / 31.8–31.9 ms	3–5	68% / 29% / 2%	9.3–10.7 ms	58 ms
#1584 at its default (fps_target 60)	3	31.8–32.2	27.3–29.5	33.2–33.5 / 50.6–51.5 / 52.5–53.3 ms	5–8	13% / 61% / 26%	9.6–11.6 ms	76–79 ms
#1543, DM_FPS_TARGET=30	2	30.0	29.9–30.0	33.2 / 34.5–34.6 / 35.6–36.1 ms	3–5	0 / 100% / 0	2.8–3.3 ms	110 ms
#1584, DM_FPS_TARGET=30	1	30.0	29.9	33.2 / 34.5 / 35.2 ms	4	0 / 100% / 0	3.5 ms	110 ms

"Present → display" is the host's game enqueue to target display p50. A 3-vsync hold is 50 ms, so the table counts frames over 60 ms.

At a 30 cap the two behave the same on this Mac: every frame is held 2 vsyncs, and the game runs at real time.

At #1584's default 60 target, this Mac does not hold 60 (21–24 ms of GPU per frame at hold 1).

• The host probes hold 1 six to eight times a minute, and every probe after the title failed (41–43 per run).
• With kmin 1 the hold can also go to 3 (kmax = FSTEP_MAX), and it did in the heavier views: 17–34% of walk frames, 73–89% of frames at the door and in Saria's greeting (20–24 fps), and the balcony at 20 fps, against 32 fps for Ocarina of Time keeps real speed below 60 fps: its frame step follows the measured frame time #1543 uncapped.
• A one-frame pass dump in the house and on the balcony shows the scene at 854x480 with either PR, so the resolution rise described for the M1 Ultra did not happen here.

At the door, #1543 shows the game's one-frame stall (119–146 ms in 3 of 4 runs), as does #1584 at a 30 cap (128 ms). #1584 at its default has no frame over 74 ms there, since it is already at hold 3.

Launcher. #1584's fps_target 60 gives the launcher a Frame rate row (30 / 60). With #1543 the profile's fps_target stays 0, and there is no such row.

No GPU errors, and the same [RED] lines in all runs (the partial-library notes and one texture type mismatch). Footprint peak 10.1–10.8 GB.

Not covered: docked mode, MetalFX, areas past the start of Kokiri Forest, a Mac that holds 60, and code in the game that might use 1/60 directly (#1543's note).

[LeonardoBai12]

Thank you @PucaVaz for the careful side-by-side, especially keeping the shaders and pipeline archive byte-identical so only the frame step differed.

My reading of it:

• Both PRs keep real time. They differ in how they pace below 60: Ocarina of Time keeps real speed below 60 fps: its frame step follows the measured frame time #1543 lets the frame rate float (44–45 fps walking here), and Ocarina of Time: frame step in whole vsyncs (fps_target 60, 30 when 60 does not hold) #1584 holds whole vsyncs, which at its 60 target fell to 27–30 and sometimes 20 fps on this Mac.
• At a 30 fps cap the two behave the same.
• Ocarina of Time: frame step in whole vsyncs (fps_target 60, 30 when 60 does not hold) #1584's launcher Frame rate row is a real advantage for players.

The two could also work together: #1543 for the uncapped default and #1584's fps_target row for players who want a locked 30. I am happy to rebase on #1584 or adjust if maintainers prefer one approach.

I rebased this branch on current main (12ddb1f), so the CI failures from the old base (t_gfx_suspend link and test_dmsh_pool_arrays, both fixed on main) should clear.

[oliverames]

Thanks for this. One finding from the HookLink fork that touches the stub, and a check you may want to add.

In HookLink's tree, #1543's measured-time words were inserted into the frame-step stub that is on main now (frame_step in dm/games/0400486024DEC000/patches.py), which has two fixed branches, cbz w17,orig (+13) and (+11). With the new words in, those offsets landed inside them. An iPhone 18 Pro Max then faulted at x17 + 0x3c with x17 = 0 on the first frame, before the host had decided a step: the block addressed the state page through x17, which the rewriter uses as scratch, so it does not survive a store. HookLink's fix computes the branches to the division and takes the page again into x16, as your sequence does: dsi-hub@b02c7d64 (building on dsi-hub@8b9fc9a8). They also added dm/tools/tests/test_oot_frame_step.py, which runs the stub under Unicorn.

I read your head (4d4f967) and it does not have this problem. Your real_speed at 0x6e6cc4 has no cbz, so there is no fixed offset to land inside anything, and it addresses the page through x16 after its own ADRP. The hazard is only for a merge with main's existing stub, which your description already mentions for #1497 ("one function that calls both"). If that merge happens, the branches need to be computed, not carried over.

One suggestion, not a blocker. HookLink's test has a clobber_x17 run that zeroes x17 after every store, as the rewriter can, and one for "step not decided yet". test_oot_real_speed.py could take the same run, so a later edit that goes back to addressing the page through x17 fails in CI and not on a phone. I have not run your test with it; the phone fault above is HookLink's, and I did not reproduce it.

[oliverames]

If the floor ever meets main's host step, as it does in HookLink's tree, the host's debt has to take what the floor adds to the step. Left as it is, the step pays the same time back again. With the hold off and frames of 1.8 vsyncs the steps go 1, 2, 2, 2, 2 under a floor of 1.8, and a model of the controller runs 9% fast (17% at 1.5 vsyncs). Your stub doesn't have this, because it takes the larger of the game's own step and the frame time and no host step is involved. The fix I'm running is nvn_fstep_moved in oliverames@fd62582d, with t_fstep cases.

[LeonardoBai12]

Thanks @oliverames for reading the stub so closely, and for checking that this head doesn't address the page through x17. The two hazards you describe are worth knowing for anyone who merges a step like this into main's frame_step:

• the fixed cbz offsets land inside the new words;
• the host's debt has to take what a floor adds, or the step pays that time back twice.

main has had its own real-speed step since 7d8dcdf, in whole vsyncs with the launcher's Frame rate row. This branch now conflicts with it. I've played on main's step for the last few days on an M1 Pro, and the game keeps real time there whenever it holds 30 fps. So I'm closing this PR as superseded by main.

The idea came from gunvalk's work in zortos293/Lichii PR #216. Thanks again @PucaVaz for the side-by-side with #1584.