Out of bounds: Difference between revisions
Jump to navigation
Jump to search
Content added Content deleted
>Bbbbbbbbba m (→Accessing out of bound areas: Added an anchor.) |
>Bbbbbbbbba m (→Technical Explanations: Minor grammar fix.) |
||
| Line 40: | Line 40: | ||
====Technical Explanations==== |
====Technical Explanations==== |
||
The properties of the base map in out of bound areas is related to the "tile block map". To save on space, the map data in the ROM is actually not stored as tiles, but as "tile blocks", which are 2*2 |
The properties of the base map in out of bound areas is related to the "tile block map". To save on space, the map data in the ROM is actually not stored as tiles, but as "tile blocks", which are 2*2 blocks of tiles. Each tile block is represented by a single byte, and they are translated into tiles only when they are displayed on screen. The translation rules depend on the current tileset. |
||
The tile block map must be loaded into the RAM, because it may be changed by the player cutting down trees. Furthermore, there is a 3 block "padding" in each direction, so that the player doesn't see invalid data when they stand near the boundary of the in bound area. If there are any map connections, the "preview" of connecting maps are also loaded into the tile block map. Therefore, each row in the tile block map consists of (w/2 + 6) bytes, where w is the width of the map in tiles. |
The tile block map must be loaded into the RAM, because it may be changed by the player cutting down trees. Furthermore, there is a 3 block "padding" in each direction, so that the player doesn't see invalid data when they stand near the boundary of the in bound area. If there are any map connections, the "preview" of connecting maps are also loaded into the tile block map. Therefore, each row in the tile block map consists of (w/2 + 6) bytes, where w is the width of the map in tiles. |
||