Skip to content

Stairs - #6964

Open
serprex wants to merge 2 commits into
HarbourMasters:developfrom
serprex:stairs-hooks
Open

Stairs#6964
serprex wants to merge 2 commits into
HarbourMasters:developfrom
serprex:stairs-hooks

Conversation

@serprex

@serprex serprex commented Jul 22, 2026

Copy link
Copy Markdown
Member

Heap pressure simulator. Mirrors every ZeldaArena/GameState allocation into a shadow arena sized like N64 heap

Cleaned up #3863

Build Artifacts

Comment thread soh/soh/SohGui/SohMenuEnhancements.cpp Outdated
Heap pressure simulator. Mirrors every ZeldaArena/GameState allocation into a shadow arena sized like N64 heap
@djevangelia

Copy link
Copy Markdown
Contributor

Hmm... size doesn't match sZeldaArena, this is spawning Like likes in Hyrule Field.
Like likes take up a lot of space due to their char unk_3C4[0x2000] member.
23 likelikes

23 Like likes with N64 simulation. (Even more without)

7 likelikes

7 Like likes on decomp NTSC 1.0 with a few debug modifications (no PAL object space reduction).
0x36270 = sZeldaArena.size, 94.7% usage.
Top row sZeldaArena space, bottom row object space usage (size is fixed in z_scene.c)

Likewise Kakariko is 0x4f650 in 1.0 (~10 Like likes), 0x78029 in SoH (31 Like likes).

@djevangelia

djevangelia commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

These are all GameState_Alloc() I could find and they match up with the final sZeldaArena size, remain is THA_GetRemaining().
This is my super crashed decomp build that always crashes on Hyrule Field entry, but intro screen has Hyrule Field sZeldaArena.size as 0x2e780 which matches allocation log below. Checked Zora's River and it matches too.
Is some allocation missing from the simulation? (or, realloc arena init size not matching)
(old log removed)

@serprex

serprex commented Jul 23, 2026

Copy link
Copy Markdown
Member Author

I didn't track realloc since oot never actually uses realloc

@serprex

serprex commented Jul 23, 2026

Copy link
Copy Markdown
Member Author

will probably go with inspectredc#4 when @inspectredc opens new PR

@djevangelia

djevangelia commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

I didn't track realloc since oot never actually uses realloc

For some reason it uses GameState_Realloc in Play_Init and with fixed value 0x1D4790 so that was ok.
I did some more digging and my guess is that most z_bgcheck allocations are missing, as they are not called by GameState_Alloc but by calling the THA functions directly. I did the size math on this one and it matches up.
(old log removed)

@djevangelia

djevangelia commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Did the same checks in SoH. The alloc == 0 check doesn't seem to work (or rather doesn't check size).

[heap_sim.cpp:581] [info] heap sim: simulated zelda heap size=000000 (game allocs deducted 02e785 from 02e785)

SoH alloc log for Hyrule Field (intro screen).
Notably the Play_LoadFile allocations are moved to z_play_otr.cpp, so sceneFile and some other file size check must be done there.
Size mismatch from z_effect_soft_sprite.c was surprising, is some custom data added there? Could probably be added as static data size?
(old log deleted)

@djevangelia

djevangelia commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

I've gotten somewhat close to getting the Hyrule Field sZeldaArena size right (real 0x2e780 mine 0x2ab40). Problems:

  • Scene Play_LoadFile: Scenes are loaded through the resource manager. Is the real scene size still available there? Otherwise scene sizes must be scraped from NTSC 1.2 .map file and put into table.
  • SSNodeList_Alloc: The size of CollisionContext needs to be manually adjusted (0x1464). (For some reason colCtx->colHeader->numPolygons is about 3 times lower than decomp (512 vs 1579)? I can't find a reason for this. <-- disregard this, I read line output wrong)
  • Navi Play_LoadFile: Same as for scene Play_LoadFile.
  • z_vr_box: For some reason the vrbox 3 size 12 * 150 * sizeof(Gfx) is twice the decomp size, I think the Gfx size has doubled but didn't check (edit: checked and this is correct - so must be halved for every use). There are a lot of allocation calls in z_vr_box (not findable in SoH) that need some smart way of solving them. 3 calls are missing for this reason and manually added at the end.

Edit: After fixing numPolygons and Gfx size is now 0x2e790. So if scene and Navi loading size + z_vr_box can be solved it seems it's possible to recreate the sZeldaArena size.

Every call:

[z_kaleido_manager.c:74] [info] kaleido/player += 35510 (remain: 19f280)
Static, can be taken from .map file, I used 0x35510 to match my decomp build (0x26980 in mini-modified build)
[z_construct.c:192] [info] textbox seg += 2200 (remain: 19d080)
Static
[z_effect_soft_sprite.c:26] [info] effects table += 1fe0 (remain: 19b0a0)
Should be static, still don't know why it's larger than decomp
[z_play_otr.cpp:47] [info] hyrule += 2a220 (remain: 170e80)
☢️ Problem, see above
[z_scene.c:78] [info] object space += fa000 (remain: 76e80)
Static depending on scene (size determined in code)
[z_bgcheck.c:1580] [info] colctx lookup += 1800 (remain: 75680)
Non-static, did not need editing, seems OK
[z_bgcheck.c:1631] [info] ssnode list += 85ec (remain: 6d0a0)
Non-static, matches after fix after noticing line output mistake (size 81d0 remain 6d4b0), seems OK
[z_bgcheck.c:2487] [info] ssnode numpolys += 62b (remain: 6ca80)
Non-static, did not need editing, seems OK
[z_bgcheck.c:2623] [info] dyna poly list += 2000 (numPoly 1024 sizeof 10) (remain: 6aa80)
Non-static, needs to be run before numPoly is SoH-multiplied by 2, otherwise seems OK
[z_bgcheck.c:2642] [info] dyna vtx list += c00 (numVtx 1024 sizeof 6) (remain: 69e80)
Non-static, needs to be run before numVtx is SoH-multiplied by 2, otherwise seems OK
[z_bgcheck.c:113] [info] dyna ss node += fa0 (remain: 68ee0)
Non-static, did not need editing, seems OK
[z_scene_otr.cpp:112] [info] navi += 70 (remain: 68e70)
☢️ Problem, see above
[z_vr_box.c:924] [info] vrbox 3 += 7080 (remain: 61df0)
☢️ Problem, see above
[z_vr_box.c:938] [info] vrbox 5 += a00 (remain: 613f0)
Non-static, did not need editing, maybe OK?
[z_room.c:570] [info] max room += 15230 (remain: 4c1c0)
Non-static, did not need editing, seems OK
[z_construct.c:66] [info] parameter size += 3b00 (remain: 486c0)
Static
[z_construct.c:76] [info] action tex += 480 (remain: 48240)
Static
[z_construct.c:89] [info] icon seg += 4000 (remain: 44240)
Static
[z_map_exp.c:540] [info] map_exp += 1000 (remain: 43240)
Static
[sys_matrix.c:36] [info] matrix += 500 (remain: 42d40)
Static

[heap_sim.cpp:577] [info] gTotalAlloc final size = 191a50
[heap_sim.cpp:579] [info] gTotalAlloc + vrbox extra (0x18200) = 1a9c50
[heap_sim.cpp:581] [info] arena alloc = 2ab40

@djevangelia

djevangelia commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Ok, this should give the right sizes now for indoor, outdoor and dungeons.
djevangelia@d710880

  • Scene sizes and player size are from NTSC 1.0
  • In vanilla, allocation of Navi message data occurs in the middle of the allocations but occurs before kaleido/player here, so I left it in z_play_otr (also difficult to find which size it should be from the outside)
  • This also made it harder to find out where to zero gTotalAlloc, which ideally should occur in the heap sim
  • Kept doing all static size allocations individually for testing/logging, but could be merged together
  • The unorthodox naming convention is to make it more easy to find and replace
  • Kept draw screen text for scene size and spawn Like likes on D-up for testing
  • Didn't make the actual heap sim size the final Zelda arena mimic size because it always crashed
  • My decomp sZeldaArena visualization fails because size has been dropped from the struct (but it is there in all N64 versions) and it crashed when I tried to re-add it.

This is my contribution for now to this project, as I don't think I can do much more right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants