Advertisement
Guest User

Untitled

a guest
Nov 21st, 2019
133
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.93 KB | None | 0 0
  1. Three things are loaded into the part of the heap that we're interested in:
  2. 1. Heap nodes (have size 0x10 in MM)
  3. 2. Actor instances (labelled "AI" in spectrum)
  4. 3. Actor Overlays (labelled "AF")
  5.  
  6. ===HEAP NODES===
  7. Heap nodes are size 0x10 files that sit between all loaded actors, and surround gaps that new actors can be allocated into. In this way, nodes are used to keep track of the size of gaps in the heap for easy allocation.
  8.  
  9. Whenever an instance or overlay loads into the heap, the nodes are checked. The first node is checked first, if it has enough free space directly after it then it will allocate there. If not, it will go onto the next node and check there - and so on until it finds a spot.
  10.  
  11. Once it finds a spot, the file will allocate there and will check if it needs to place a node. Nodes will always stick around if there is a file allocated either directly before them or directly after them (or both). So you will never find a file which isn't sandwiched by two nodes, even if there's a gap in the heap.
  12.  
  13. For example, let's say the heap looks like this:
  14.  
  15. Node
  16. Actor0 (Size 0x100)
  17. Node
  18. Free space (Size 0x120)
  19. Node
  20. Actor0 (Size 0x100)
  21. Node
  22.  
  23. And let's say we want to load another Actor0 into the heap. The first available node would be the one before the free space, and an Actor0 instance would fill up 0x100 of the space. A node would then be placed on the end of Actor0 and we would end up with:
  24.  
  25. Node
  26. Actor0 (Size 0x100)
  27. Node
  28. Actor0
  29. Node
  30. Free space (Size 0x10)
  31. Node
  32. Actor0 (Size 0x100)
  33. Node
  34.  
  35. But let's say we wanted to load in the actor Actor1 which has size 0x110. Clearly there's enough room there, but if we try to place a node directly after it, we would end up with two nodes next to each other, which is pretty useless as there's no space between them.
  36.  
  37. What happens instead is that the node before the new actor will essentially just treat the actor as if it has size 0x120 instead of 0x110, so that it perfectly fits in the gap. In this way we can find inconsistencies in the amount of space actors take up on the heap.
  38.  
  39. ===OVERLAYS===
  40. Overlays contain a lot of the functions for how actors should run. An overlay will always allocate in earlier (in time) than the instance - essentially the overlay being on the heap is a prerequisite for the instance.
  41.  
  42. There are three types of allocation for overlays:
  43. 0: The overlay allocates into the earliest spot it can on the heap
  44. 1: The overlay allocates into the end of the heap, as far as it can go
  45. 2: The overlay allocates to the end, and will never deallocate until you reload a scene.
  46.  
  47. For types 0 and 1, the overlay will de-allocate if all the instances disappear. 2 will not. Most actors have type 0 overlays, but most actors that are spawned by link (bombs, chus, quickspin effect) will have type 2.
  48.  
  49. The one exception is the item pickup actor which (at least in OoT) doesn't actually have an overlay because it checks some static code elsewhere in memory instead.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement