[stan69b]

Ocarina of Time now plays on an iPhone 17 and an M1 iPad Pro (both 8 GB), and on the Mac it fills any window shape, resized live: no bars, no stretching. The iPhone holds 27–30 fps in Kokiri Forest, and frames just over the 30 fps cap now show at the next vsync instead of waiting a full 33 ms tick. The iPad holds 20 fps where the views are light, but 5–12 fps, GPU-bound, in heavier rooms of the Great Deku Tree. Follows #1829.

Rebased onto main 0c078130 (2026-11-12)

Rebased onto main 0c078130 (head 4283410d, 40 commits): first onto e6048dea, then onto 0f19bdf7 for main's a2514d7d, which removed the profile key render_cond (the host now evaluates conditional rendering for every game): the profile drops its render_cond on line and keeps screen_aspect any. The rebase onto 547c5db6 met main's compute dispatch barriers (#2250): its compute-dispatch counts and this branch's clock-wait line are both new log lines at the same place in power_line (hle_nvn.c), and both are kept. The last rebase, onto 0c078130, met main's queued residency changes (0c078130: res_add / res_remove queue their change, and the commit applies the queue outside g_res_mu); see the residency item below. No commit was dropped: none was empty after the rebase. Authors and dates are unchanged, and each re-fitted commit says what changed in a paragraph at the end of its message.

Five commits needed real re-fitting:

• File pages wired before a residency commit (file_wire). With main's queue, res_add_at wires a buffer's file pages before it queues the change, and res_commit takes the wired ranges together with the queue, so each commit gives back after itself exactly the ranges of the buffers it made resident. A range wired for a change queued later waits for that change's own commit, so no commit pages the guest's files in from the GPU driver's path, where the M1 iPad froze. The placement-heap commit records the adding line beside the queued change and sets no g_res_dirty, which the queue replaced.
• GPU-only textures share bytes under 8 GB (window_texture). It now uses main's pool table and owner. The virtual pool's runs are tagged after mtl_pool_replace, and a texture's storage range for res_top is kept before own_alias_publish (nvn_owner.m). A span's heap is an NvImageHeap with window set. Main's family-heap search (own_alias_at_locked) skips it, and it is freed with its last texture instead of waiting in rh_wait's free list. The rendering.md entry keeps main's Fix and Check wording and adds the window heap.
• The title movie at its own speed (cv_due). Main moved the decoder onto its own thread (cv_worker). The clock now runs in fill(), both on the guest's release and on the decoder's thread. Pictures it drops reach ready() the same way a packet taken does. t_codec_video's paced player waits for the decoder's thread (settle). With cv_due disabled, the test still fails.
• Frame step: late frames with the GPU idle do not step up, and a longer hold the GPU does not explain is probed #1942's frame step (uncraftablexd's commit). Main's average rule (1e3fd031) still applies: idle-GPU late frames and FSTEP_RUN late frames in a row both step up only when the frames at the hold fall short of it on average. The new hold is the cheapest of the three late frames' cost, and a fixed step is held within the stub's smax.
• DM_NVN_GPUPROF's CPU timeline. Its park reasons sit beside main's 5 s queue-wait warnings in nvn_queue.inc.

The other conflicts were in the game notes, docs_patches.py (main's OTHER_SPAN with this branch's step_max), the iOS bridging header (DmRotation.h with save_sync.h) and t_fstep.c. The symptom index is regenerated. This PR changes no shader chain file; the chain is main's (a5e7fb6e4fa4 since main's 596d719c).

Tests on the rebased head (M4 Mac):

• Graphics, make -C dm/gfx/tests GAME=0400486024DEC000 check_<t>, every test this PR adds or changes, all passing: t_addr_known 20, t_capture_live, t_copy_alias 126, t_cpu_tex 102, t_file_wire 10, t_fstep 114, t_gpuprof 43, t_large_mdi, t_linear_readback 61, t_link_ticks 43, t_mesh_first_use 53, t_mip_extent 22, t_pool_notes 91, t_present_crop 120, t_present_snap 13, t_queue_lifetime 38, t_queue_origin 398, t_readback 218, t_render_counter_overlap 37, t_render_enable_queue 62, t_rt_lifetime 9, t_sparse_tiles 4,253, t_sub_overlap 8, t_wait_event 103, t_window_alias 25, t_rt_recycle 22 (and off). Main's tests for the code under the re-fits pass too: t_res_commit 8, t_upload_src 41, t_serial_owner 176, t_pso_archive 343, t_dispatch_barrier 31.
• Host: t_clockwait, t_codec_video, t_nro, t_symbols: all pass.
• Python: test_docs, test_env_switches, test_oot_aspect (20), test_game_profile, test_nsp_chain: all OK.
• make -C dm/host GAME=0400486024DEC000 builds.
• All of the above ran again on the final head 4283410d (base 0c078130).

The device and regress results below are from before this rebase.

What

iPhone and M1 iPad

1. Freeze over the guest's files (file_wire, t_file_wire): the residency commit paged the guest file in from the GPU driver's path and hung on an APFS lock. File-backed buffers are now mlocked before the commit. No change for anonymous memory (every Mac run by default). If growing the list of wired ranges fails, the new range is unlocked at once, so nothing writes through a null pointer (clang-tidy).
2. GPU-only textures share bytes under 8 GB of working set (window_texture, t_window_alias): with 7f50222's per-target heaps the iPad ran out of GPU memory at an outdoor save load (5,184 of 5,461 MB). Placed per 32 MB span at the NVN offset × 9/8, no lossless compression. Only where recommendedMaxWorkingSetSize < 8 GB; DM_NVN_WINDOW_ALIAS=0/1 forces it.
   • 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 found that sharing this pool corrupts the fog on a Mac. I don't claim this avoids that. On the iPad and the iPhone the picture looked clean (Kokiri Forest, Deku Tree), for reasons not known, and the alternative there is out of memory.
3. Shader-code pools stay out of the raw pool table (hle_nvn.c nvnMemoryPoolGetBufferAddress, nvn_mtl.m mtl_pool_addressed_by, t_addr_known): the game asks for each shader-code pool's address to place its programs, so the raw pool table wired all 223 of them (317 MB), though the GPU never reads shader code here. On the 8 GB iPhone that left too little room for the guest's file pages, which were read back all the time: 14–17 fps, 117 ms frames on average with 27 ms of GPU. A shader-code pool's own address now keeps it out of the table, and a buffer made in such a pool still puts it in. Holds for every game.
4. Title in slow motion (nvn_fstep.h, hle_nvn.c, t_fstep): the frame step took the boot screens' GPU time (0.4 ms) as its reference, so the title's 40 ms always read as a slowed GPU and probes of hold 1 never stopped. The step now calls the GPU slowed only against a reference that measured the same work: the same draws and, since the title is mostly compute, the same dispatches.
5. The title movie plays at its own speed (hle_codec_video.c, t_codec_video): a movie the player reads one picture per game frame follows its own clock, so pictures behind it are dropped instead of the movie slowing with the frame step.
6. Clock waits in the power line (dm_clock_top, t_clockwait): a diagnostic only. It shows Ocarina makes no clock waits, so 8bdfcb7 is not behind its slow motion. The cause is GPU time.
7. Game note: "For an iPhone or iPad build", with the iPhone's results.

Any window or screen shape (screen_aspect any)

8. The present takes the crop's shape (nvn_mtl.m present_shape / present_fit, t_present_crop): a crop whose width / height matches the shape the host asked for is shown in that shape instead of 16:9.
9. screen_aspect any (game.py, loader.c, hle_oe.c, front_mac.m, front_ios.m, settings.tsv): a profile's stubs follow any shape from 0.25 to 6, portrait included, while the game runs. The loader writes the ratio, the size factors, a change count and the camera multipliers to the state page. The Mac reports the window's shape once a resize settles; iOS reports the space the picture has: the screen in landscape, and upright the whole screen or the part above the controls (item 12). The Picture shape setting defaults to auto. Front ends get two new calls, front_view_aspect and dm_screen_view_changed; until a front end provides them, these profiles render 16:9.
10. Ocarina's stubs, all function-matched others of its frame-step rule:
    • Output size, window textures, camera, live resize: the output size takes the shape, the window textures grow when the crop needs it, the cached camera matrix takes the shape every frame, and a live resize makes the game recompute its size.
    • HUD: every layout file holds a 3840×2160 screen size, and each screen copies its 2D projection to the GPU every frame. The stub reshapes that copy at the HUD's pixel size, and the game's conversions between layout and screen get the same size.
    • The rule: wider than 16:9 keeps the vertical angle, between 1:1 and 16:9 the horizontal one, and upright takes the scale of the same screen turned landscape.
11. Probe diagnostics (probe.c), for values a game caches:
    • DM_PROBE_FP prints float arguments.
    • DM_PROBE_FINDMAT scans guest memory for perspective matrices, and DM_PROBE_FINDF for a pair of floats.
    • DM_PROBE_WATCH=@xN+<offset> arms the write watch on an object a probe reaches.
    • DM_PROBE_XREG dumps any register's memory.
12. Upright on the iPhone (front_ios.m, DmLayout.h, DmRotation.h, main.m, DmHostingController.swift, Launcher.swift, DmGamepad.m, settings.tsv, settings.py):
    • Rotation (Automatic / Landscape / Portrait, DM_ROTATION), on the settings screen and in the in-game menu, locks the orientation, so an iPhone can be played upright.
    • Portrait layout (DM_PORTRAIT_LAYOUT, only for screen_aspect any profiles): Full screen (the default) fills the screen with the touch controls over the picture; Picture above controls fills the space above them. Either way the game renders that shape.
    • Other games keep a 16:9 picture above the controls. With a controller and no touch controls shown, the picture takes the whole screen.
13. Upright cap (loader.c, DM_SCREEN_UPRIGHT_FOV, default 1): an upright picture shows no more height than a square would (79° against about 90° without the cap), so a phone no longer looks up into parts of the world the game never builds. 0 turns it off.
14. Docs:
    • The game note gets a "Screen shape" section.
    • memory.md: shader-code pools wired by the raw pool table. rendering.md: a camera that caches its projection. movies.md: the movie's own clock.
    • The screen_aspect key, DM_SCREEN_ASPECT's any range, and the new switches.
    • game-patches.md regenerated: docs_patches.py's dry run spaced a rule's other functions 16 MB apart, so the ninth was out of a branch's reach; now 4 MB.

Frame pacing at the 30 fps cap

15. Frame step: late frames with the GPU idle do not step up, and a longer hold the GPU does not explain is probed #1942's frame step is carried here (uncraftablexd's commit, unchanged from Frame step: late frames with the GPU idle do not step up, and a longer hold the GPU does not explain is probed #1942 except one conflict resolved in fstep_tick): late frames with the GPU idle do not step up, and a longer hold the GPU does not explain is probed. The pacing below builds on it. If Frame step: late frames with the GPU idle do not step up, and a longer hold the GPU does not explain is probed #1942 merges first, drop that commit from this PR.
16. Late frames at a 30 fps cap are shown at the next vsync (nvn_fstep.h fine, hle_nvn.c nvn_game_fps, t_fstep): at a 30 fps cap the hold is at most 2 vsyncs, and the display link runs at 30 Hz. A frame a little over 33.3 ms (the iPhone's 36.5 ms in Kokiri Forest) missed its tick and waited for the next one, so about 1 frame in 10 stayed 66.7 ms on screen. When frames are late at the longest hold the cap allows (the same 3 late frames in a row that would otherwise step up), the 60 Hz link runs instead: each frame is still held its two vsyncs, and a late one shows at the next vsync, 50 ms. It is never faster than 30. The 30 Hz link comes back after 8 s with no late frame. Both switches are logged.
17. That 60 Hz link runs at frame latency 2 (nvn_mtl.m link_latency): at latency 1 on a ProMotion screen it took frames whose GPU work was still running, and held the iPad's 40 ms title frames at 50 ms. Latency 2 gives the same lead the 30 Hz link has at latency 1, so input lag is unchanged.
18. The frame step's log lines name the cap, the longest hold it allows and why, and the on-screen lines count gaps at the hold, one vsync longer, and two or more longer.
19. Docs: a frame-rate.md entry, "Late frames at a 30 fps cap on the 30 Hz display link", with the measurements, and a pacing bullet in the game note.
20. A smoke route for Ocarina (dm/games/0400486024DEC000/smoke.tsv), so regress.py check boots it: an empty save to the title, no input, 400 s. Quick mode pays the cold pipeline prepare, 130–270 s for 14,748 pipelines on an M4, before the first frame.

The iPhone 17 frame on the GPU

21. A submission's end no longer waits for the encode thread (nvn_mtl.m mtl_sub_commit, t_sub_overlap): with Metal encoding on its own thread (the iOS default), each submission waited for the encode thread to finish the previous one. Ocarina makes about 30 submissions a frame, so on the iPhone 17 frame 3600 spanned 34.9 ms for 20.2 ms of GPU work, 13.6 ms of it gaps before a submission's first encoder, and the replay waited 36 times a frame (10 ms). The records now go to the encode thread with a note of their fence, and the replay goes on; a present still waits for the submissions before it. DM_NVN_SUB_DRAIN=1 restores the old wait. Holds for every game with the encode thread on. On the iPhone it halved the GPU's idle gaps; the frame rate did not change, because gameplay there is CPU-bound (16–20 fps at thermal state 2, GPU p50 21–24 ms).
22. DM_NVN_GPUPROF logs the host's CPU timeline beside a profiled frame's encoders (nvn_mtl.m, nvn_queue.inc, t_gpuprof): each submission's encoding, each commit, every blocking CPU wait for the GPU by its site, and the NVN queue worker's parks, on the encoders' clock. A diagnostic, off by default.
23. DM_NVN_GPUPROF_GEOM: split each render pass's GPU time into geometry and pixels #1751's DM_NVN_GPUPROF_GEOM is carried here (nvn_mtl.m, gpuprof.py): item 22 builds on it. Off by default. If DM_NVN_GPUPROF_GEOM: split each render pass's GPU time into geometry and pixels #1751 merges first, drop that commit from this PR.

Checked

• iPhone 17 (A19, 8 GB, iOS 26.6.1), on 04811a6 (chain 39eb2f781d07), the owner playing from a save in Kokiri Forest, the launcher's 30 fps cap and Dynamic resolution on. For testing, the build also held Ocarina of Time: opt-in task isolation (DM_NVN_ISOLATE_TASK), the Hi-Z task a5288 in command buffers of its own, a workaround for its GPU hangs on an M1 #1842, The game's compute dispatches with no game barrier between them run side by side (profile key dispatch_overlap, on for Ocarina of Time): Kokiri Forest GPU p50 15.63 → 14.76 ms #1901, Frame step: late frames with the GPU idle do not step up, and a longer hold the GPU does not explain is probed #1942 and DM_NVN_GPUPROF_GEOM: split each render pass's GPU time into geometry and pixels #1751.

  • Before item 3: 14–17 fps, 6,000–15,600 page-ins every 10 s, 122 of 300 frames dropped. An earlier build without these fixes ended in a kernel panic after the save loaded.
  • With it: 27 fps standing, 27–30 walking, frame p50 36.5 / p95 40 ms, GPU p50 32 ms, 100–400 page-ins every 10 s, about 30 of 300 frames dropped. The title holds 30 fps with its movie at full speed.

• iPad Pro 11" 3rd gen (M1, 8 GB, iPadOS 27.0.1), on 7ffa63c (chain dedc9391c30b), no switches needed. Two 32-minute runs at the Deku Tree's entrance: 20.0 fps in every window, GPU 34–35 ms, game speed 0.97–1.00, residency 3.2 GB, headroom ≥ 5.87 GB. No crash, hang, GPU error or panic.

• Screen shape on an M4 Pro Mac, at chain dedc9391c30b:

  • six window shapes resized live while playing: iPhone and iPad, upright and landscape; 1700×478; 16:9;
  • the pause menu, the "A Open" prompt, and the Kokiri Forest cutscene with its location card, at 2.2.

• On this branch (04811a6, chain 39eb2f781d07; its shader libraries now exist, built with no compile failures):

  • items 3–5: the host builds; t_addr_known 20/20 (fails without item 3), t_fstep 84/84, test_docs.py; t_codec_video passed on the test build that carries the same change;
  • before items 3–5 (16f5a3d): every host test passed;
  • test_oot_aspect.py 18/18 (unicorn), plus the rewriter tests and test_patches.py;
  • t_present_crop 120/120, t_file_wire, t_window_alias, t_image_alias, t_clockwait;
  • Python lint and clang-tidy (LLVM 21; CI uses 23) on 16f5a3d: 0 new findings; not re-run for items 3–5.

• Upright on the iPhone 17: six 3-minute runs into Kokiri Forest, no crash. Full screen rendered 1200x2600, capped; Picture above controls 1.07:1; landscape 2.18:1. The frame rate was the same upright and in landscape. Duo harness on the Simulator: 42 tests, 0 failures, including a real rotation to portrait. test_oot_aspect 20/20, test_launcher_settings, test_docs.

• Pacing at the 30 fps cap, M1 iPad Pro (Deku Tree save, Dynamic resolution on, 9,000 frames of camera turns per run):

  Build	fps	gaps of 33 / 42 / 50 / 67 ms	66.7 ms gaps per 300	on-screen p99
  30 Hz link (before)	27.9	88.6 / 3.8 / 0 / 7.5 %	22.8	66.7 ms
  60 Hz link, latency 2 (this PR)	27.7	81.0 / 2.3 / 16.7 / 0.1 %	0.2	50.0 ms

  Game time stayed at 1.000 of real time.

• Pacing at the 30 fps cap, iPhone 17 (Kokiri Forest, camera turns): first gameplay at thermal state 1 showed 1,098 / 997 / 1 gaps at the hold / one vsync longer / two or more (p99 45.8–50 ms, game time 0.999), where before about 30 of every 300 frames had a 66.7 ms gap. Later, at thermal state 2, gameplay ran CPU-bound at 13–22 fps and game time fell to 0.73. Those frames are longer than the 3 vsyncs a frame step can carry, so no hold changes that.

• Tests on the rebased head: t_fstep 106/106, t_nvn 277/277, t_copy_alias 126/126, t_sub_overlap 8/8, test_docs; earlier t_thermal 21/21, present_rescue 101/101.

• Regress: scripts/regress.py check --quick --games 0400486024DEC000 on an M4 Mac (macOS 27.2, Xcode 27.2). Baseline: upstream main c4ffb9df. Candidate: 404a6dd3, which is this PR's content before its last rebase onto three newer main commits and its two lint fixes, plus the route below.

  • Games: regress.py impact names Breath of the Wild, Pokémon Scarlet and Tears of the Kingdom as affected, and Hades through a broad rule. None of them has a Mac build here, so they are unchecked. Ocarina of Time is the game this PR is about, and the only one booted. It boots with a new smoke route, dm/games/0400486024DEC000/smoke.tsv: an empty save to the title, no input.
  • Result: regress.py reports REGRESSION, from two screenshots only, and it is not one. Both show the title rendered correctly. They differ in the title movie's position: at 385 s the candidate is at the field shot and main still at the forest shot, because the movie now follows its own clock.
    • Shaders: 42,848 / 42,848 on both, no MSL change, no interface finding, no new [RED].
    • Frames: 19.8 → 33.1 fps, frame p50 / p99 49.96 / 114.64 → 33.27 / 34.67 ms.
    • Game time: 0.955 → 1.000 of real time. Main holds 3 vsyncs most of the time with 26 probes and 30 failed trials; the candidate holds 1–2.
    • Peak footprint: 2,778 → 2,765 MB. Cold pipeline prepare: 128 → 142 s.
    • These are single runs, with replay noise not measured.
  • The movie: main reads one picture per game frame, so at 20 fps the title movie plays at about a third of its speed. The candidate drops pictures behind the movie's clock instead (600 pictures dropped to the movie's clock, 780 put in), so it plays at its own speed. Both runs recorded frames.tsv the same way, and nothing else ran on the Mac.
  • Setup: OoT's local Mac build folders hold a shader package split before records carried keys, so the harness ran from a folder that links the build to its keyed re-split.

Related PRs, to merge with this one

None of them is needed for this PR to build or work, and this PR is not needed for them. The iPhone 17 build above carried the first four.

PR	What	Measured gain	In the iPhone build	Merging after this PR
#1901	The game's compute dispatches with no game barrier between them run side by side (dispatch_overlap, on for Ocarina)	Kokiri Forest GPU p50 15.63 → 14.76 ms (Mac)	yes	one conflict in nvn_mtl.m dispatch_enc: keep #1901's body and this PR's g_stat_disp++ beside g_gp_disp++
#1942	Frame step: late frames with the GPU idle do not step up; a longer hold the GPU does not explain is probed	after a warm start, no more ~1,470 presents held at 20 fps or below (Mac)	yes	carried in this PR (the pacing builds on it); drop it here if #1942 merges first
#1842	Opt-in task isolation (DM_NVN_ISOLATE_TASK) for the Hi-Z task a5288	the M1 GPU hangs after an area change (about 15 of 16 walks without it) did not happen with it; off by default, a workaround	yes, off	clean
#1751	DM_NVN_GPUPROF_GEOM: a render pass's GPU time split into geometry and pixels	diagnostic: Ocarina's colour pass with its 11 mesh draws is 5.8 ms of geometry, 0.2 ms after	yes, off	carried in this PR (item 22 builds on it); drop it here if #1751 merges first
#1903	Ocarina takes the launcher's Render scale	Kokiri Forest docked at 0.75: GPU p50 15.77 → 14.31 ms, 60 fps held (Mac)	no	not tried
#1752	Raw global memory loads through one pointer resolve their pool once (chain change)	the colour-pass mesh shaders: frame p50 22.1 → 18.8 ms, p95 38.9 → 22.6 ms	no	needs a full shader build
#1833 (draft)	Raw global memory at Metal's own GPU addresses, opt-in per game	Kokiri Forest at 854x480: GPU 39.4 → 27.4 ms, frame 33.2 → 23.6 ms (M1 Pro)	no	needs a full shader build

#1906 (iOS builds link without IOBluetooth) is already in main as 9983d65.

Open

• iPhone stutter at the 30 fps cap: fixed for frames just over 33 ms (above). Still open: the iPad's title shows uneven 29–50 ms gaps, its movie gets a new picture on only about 210 of 300 frames, and the power cost of 60 link callbacks a second while late frames are paced is not measured.
• GPU time in heavy views on the iPad (54–67 ms a frame). Next to try: The game's compute dispatches with no game barrier between them run side by side (profile key dispatch_overlap, on for Ocarina of Time): Kokiri Forest GPU p50 15.63 → 14.76 ms #1901, Raw global memory loads through one pointer resolve its pool once, and the pool table search is a loop: Ocarina of Time's colour-pass mesh shaders stop looking up the pool table per word (chain 723dc3a3e17d) #1752, Ocarina of Time takes the launcher's Render scale: the 3D views at that fraction of the game's own size, the dynamic resolution held at its top level (Kokiri Forest docked at 0.75: GPU p50 15.77 → 14.31 ms, 60 fps held) #1903 (above).
• More memory headroom on 8 GB devices: about 1.2 GB of pools are wired only because the raw pool table lists them; smaller textures where the working set is under 6 GB. For a later PR.
• A GPU hang on an earlier build, in the draws of Ocarina of Time: opt-in task isolation (DM_NVN_ISOLATE_TASK), the Hi-Z task a5288 in command buffers of its own, a workaround for its GPU hangs on an M1 #1842's M1 hangs (a5288d0a6c4971fd).
• The HUD's edges:
  • The UI system places every pane relative to the screen's centre and doesn't anchor anything to the edges. So the HUD keeps its 16:9 arrangement in the middle: in wide shapes the hearts sit at the edge of the 16:9 band, and upright the HUD sits around mid-height, smaller (in Full screen, under the touch controls).
  • Full-screen panes (fades, the menu backdrop) cover only the 16:9 middle.
  • Moving the edge groups and stretching those panes needs the UI's per-frame pane transform, not found yet.

[lunks]

In the screen-shape size stub, the scratch word is state +0xb0, which is the game's dynamic-resolution flag, so any non-16:9 window turns dynamic resolution on whatever the setting. A free word fixes it (we moved it to +0xe0).

[stan69b]

In the screen-shape size stub, the scratch word is state +0xb0, which is the game's dynamic-resolution flag, so any non-16:9 window turns dynamic resolution on whatever the setting. A free word fixes it (we moved it to +0xe0).

Any thing i should do on my PR based on this comment ?

oh, my brain just brained, i'm using a reserved flag if i understand correctly, i'll see to change it

[stan69b]

Thanks, moved the size stub's scratch to state +0xe0 in 5f03fe5 (test_oot_aspect updated). In this tree I couldn't find a reader of +0xb0 as the dynamic-resolution flag, so the move is a no-op here, but it keeps us in line with your layout.

[webdz9r]

I was trying to OOT early on on the Vision Pro but was limited by the memory limits. I'm wondering if this might solve that issue

[stan69b]

This PR adds some nice optimizations, but its not a fully playable build. the repo move so fast, i need a slot to merge that part as soon as possible.

i working on a new PR with reduced textures and other memory optimization. those might help even more ;)

EDIT
A new PR is in the works, i got the iPhone running at (30)60fps during the whole first part of the game with metal frame generation, acceptable heat, played for about 40minutes without issues. I just got an issue when getting out of the woods, first time seeing the open world landscape and the app got killed by iOS, too much ram. I'm working on it today. I'm eager to know if you manage to get it running on the vision pro, that would be awesome. I expect the first boss to be doable if it has the same specs or better than my iPhone.

the iPhone 17 holds Ocarina of Time's 30 fps cap through the first dungeon: smaller textures, staging released and MetalFX for its upscaler on small devices - #2270