[givethesourceplox]

Ocarina v131072 now honors the existing host render-scale setting as a ceiling on the scale chosen by the game. For example, a 50% ceiling caps a game-selected 75% scale at 50%, while allowing the game's dynamic resolution to drop below that ceiling. The default 100% setting preserves the game's selected scale.

The game profile checks build ID e0f3ccfaf50065ae4ea01eb5aeb13b1a and the original instruction at main+0x31d3f48 before patching the final scale store. The stub preserves all integer and SIMD registers, the stack pointer, and condition flags. It uses the existing host state and advertises RENDER_SCALE so the current launcher control becomes available. Frame timing and the shader translation path are unchanged; no shader rebuild is needed.

Validation:

• Render-scale tests: 2 passed, including ARM64 execution across 160 combinations of caps, game scales, and flags, with register and memory guards checked.
• Rewrote the actual v131072 main successfully and executed its patched site in ARM64 emulation at 50% and 100% ceilings.
• Patch, docs, settings, and environment-switch suites: 31 tests passed.
• Python lint against main: zero new findings. Diff whitespace checks passed.

An earlier version of the cap was exercised on an M1 Pro through the house-to-forest route. This isolated implementation was verified with the actual rewritten image and ARM64 execution; sustained performance gains, later areas, and iOS remain unmeasured.

[FifteenPen]

On v131072 the scale store at main+0x31d3f48 runs only in a frame where the dynamic-resolution update answers status 0, a new scale. Its caller tests the status byte at main+0x31d3ee4 (ubfx x8,x0,#32,#8). Status 0 sets bit 3 of [x20+0xe2c], and the store is skipped while that bit is clear (tbz w8,#3 at main+0x31d3f30).

At a steady frame rate the update never answers 0, and on current main the level stub (7de11da) holds the top level by default. So a stub at the store alone changes nothing until the game comes under load. That is what we saw with the same single-site approach before adding a second stub.

#1903 adds that second stub at the status test (once, until the host scale has been applied). It is placed by the view-size update's fingerprint rather than the build ID. It takes the setting as a fraction of the game's own size, as Breath of the Wild and Tears of the Kingdom do, rather than a ceiling. The numbers are in its description. If the ceiling semantics are wanted instead, the status stub is what makes either one apply.