From ZeldaHacking Wiki
The oracles have several mechanisms allowing for dynamic changes to tiles. This page documents the order of those changes.
When Link is about to enter a room, the game goes through the following steps:
- It loads the room's base layout to
- If on an overworld and bit 0 of the room flags is set, the game loads the room layout from the corresponding underwater room instead.
- It calls
applyAllTileSubstitutions (04:5fef), which applies all necessary changes to
applySingleTileChanges (04:62de)is called, which replaces tiles in various rooms depending on what room flags are set.
applyRoomSpecificTileChanges (04:642c)is called, which is similar to
applySingleTileChanges, except it is much more flexible. Complex changes to room layouts, such as bridge creation and vine sprouts, are handled here.
- This probably corresponds to "map scripts" in ZOLE.
- Chests that have been opened are replaced with tile
$f0(the opened chest tile).
- Red/blue toggleable blocks are raised or lowered if necessary.
- And more.
wRoomLayoutis copied to
w3RoomLayoutBuffer (3:df00). This isn't used very often, but it might be related to remembering what's underneath Cane of Somaria blocks, and things like that?
- The contents of
wRoomCollisions (ce00)are loaded based on the contents of
wRoomLayout. This is a basic solidity map; more complex behaviours (like doors) are sort of hard-coded based on tile indices.
- The contents of
w3VramAttributes (3:dc00)are loaded based on the contents of
wRoomLayout. These are the tile map and attribute map, respectively, that will be copied directly to the gameboy's VRAM.
applyRoomSpecificTileChangesAfterGfxLoad (02:7a88)is called. It is similar to
applyRoomSpecificTileChanges, but since it is called later, it does not affect graphics or collisions by writing to
wRoomLayout. Instead, it usually makes changes directly to
w3VramTiles, or it modifies
wRoomLayoutto change the tile's behaviour without changing its graphics.