diff options
| -rw-r--r-- | Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md | 329 |
1 files changed, 148 insertions, 181 deletions
diff --git a/Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md b/Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md index 183edc3..bf34f1b 100644 --- a/Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md +++ b/Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md @@ -13,19 +13,20 @@ This tutorial will show you how to switch from per-tile \*_palette_map.asm files ## Contents -1. [Create \*_attributes.bin files from \*_palette_map.asm and \*_metatiles.bin files](#1-create-_attributesbin-files-from-_palette_mapasm-and-_metatilesbin-files) -2. [Remove the old files and include the new ones](#2-remove-the-old-files-and-include-the-new-ones) -3. [Store attribute pointers in tileset metadata](#3-store-attribute-pointers-in-tileset-metadata) -4. [Start changing how tile attributes are loaded](#4-start-changing-how-tile-attributes-are-loaded) -5. [Declare space in WRAM for on-screen tile attributes](#5-declare-space-in-wram-for-on-screen-tile-attributes) -6. [Continue changing how tile attributes are loaded](#6-continue-changing-how-tile-attributes-are-loaded) -7. [Finish changing how tile attributes are loaded](#7-finish-changing-how-tile-attributes-are-loaded) -8. [Remove unreferenced code in home/ to make room](#8-remove-unreferenced-code-in-home-to-make-room) +1. [Review how tilesets and VRAM work](#1-review-how-tilesets-and-vram-work) +2. [Create \*_attributes.bin files from \*_palette_map.asm and \*_metatiles.bin files](#2-create-_attributesbin-files-from-_palette_mapasm-and-_metatilesbin-files) +3. [Remove the old files and include the new ones](#3-remove-the-old-files-and-include-the-new-ones) +4. [Store attribute pointers in tileset metadata](#4-store-attribute-pointers-in-tileset-metadata) +5. [Start changing how tile attributes are loaded](#5-start-changing-how-tile-attributes-are-loaded) +6. [Declare space in WRAM for on-screen tile attributes](#6-declare-space-in-wram-for-on-screen-tile-attributes) +7. [Continue changing how tile attributes are loaded](#7-continue-changing-how-tile-attributes-are-loaded) +8. [Finish changing how tile attributes are loaded](#8-finish-changing-how-tile-attributes-are-loaded) +9. [Remove unreferenced code in home/ to make room](#9-remove-unreferenced-code-in-home-to-make-room) -## 1. Create \*_attributes.bin files from \*_palette_map.asm and \*_metatiles.bin files +## 1. Review how tilesets and VRAM work -First, a quick overview of how tilesets work: +Here's a quick overview of how tilesets work: - The [gfx/tilesets/\*.png](../tree/master/gfx/tilesets/) files are the tileset graphics. Each tile is 8x8 pixels, and a tileset can have up to 192 tiles. (Although they can be [expanded to 255](Expand-tilesets-from-192-to-255-tiles).) - The [gfx/tilesets/\*_palette_map.asm](../tree/master/gfx/tilesets/) files assign a color to each tile. There are eight possible colors, declared at the bottom of [constants/tileset_constants.asm](../blob/master/constants/tileset_constants.asm), although `TEXT` is not useful since it's reserved for textboxes. @@ -35,9 +36,7 @@ First, a quick overview of how tilesets work: (The \*.bin and \*.blk files are binary data, so unlike \*.asm files, a text editor won't work for them. You'll need a hex editor, or a program like [Polished Map](https://github.com/Rangi42/polished-map) that can edit maps and tilesets.) -Anyway, we're going to create **data/tilesets/\*_attributes.bin** files that assign attributes to the blocks. Each block will have 16 bytes declaring the attributes for each of its tiles, from top-left to bottom-right. - -As described in [the `PRIORITY` color tutorial](Allow-map-tiles-to-appear-above-sprites-\(so-NPCs-can-walk-behind-tiles\)-with-PRIORITY-colors), attributes control more than just color. Here's what the eight bits of an attribute byte mean: +However, this tileset system doesn't use the full potential of the GBC hardware. Specifically, each tile on the screen has an **attribute** byte (as described in [the `PRIORITY` color tutorial](Allow-map-tiles-to-appear-above-sprites-\(so-NPCs-can-walk-behind-tiles\)-with-PRIORITY-colors)) that controls more than just its color. Here's what the eight bits of an attribute byte mean: - **Bits 0–2 ($00–$07):** The color. You can see the color values in [constants/tileset_constants.asm](../blob/master/constants/tileset_constants.asm). - **Bit 3 ($08):** The tile bank. The way pokecrystal's tileset system works, tile IDs $80–$FF need this bit set. @@ -48,7 +47,31 @@ As described in [the `PRIORITY` color tutorial](Allow-map-tiles-to-appear-above- For example, the attribute byte $A9 = $80 + $20 + $08 + $01. It has the priority bit, X flip bit, and tile bank bit set, and its color is 1 (`RED`). -To start with, we're going to generate the \*_attributes.bin by automatically correlating the \*_palette_map.asm and \*_metatiles.bin files. The end result will *not* take advantage of X/Y flip or eliminate redundant tiles; it will just enable you to do that manually. +Let's take a closer look at the tile bank bit. We can understand it better by looking at [BGB](http://bgb.bircd.org/)'s VRAM viewer: + + + +VRAM is divided into six areas, each 128 tiles large. The top and middle four can be used by sprites, and the bottom and middle four can be used by background tiles. + +At the hardware level, here's how things go: + +- Tile IDs $00-$7F with bank 0 use the lower-left area. +- Tile IDs $80-$FF with bank 0 use the middle-left area. +- Tile IDs $00-$7F with bank 1 use the lower-right area. +- Tile IDs $80-$FF with bank 1 use the middle-right area. + +But here's how pokecrystal's data works: + +- Tile IDs $00-$7F use the lower-left area; the palette map sets their bank to 0. +- Tile IDs $80-$FF use the lower-right area; the palette map sets their bank to 1. +- The middle areas can't be used for map tilesets. + + +## 2. Create \*_attributes.bin files from \*_palette_map.asm and \*_metatiles.bin files + +To start with, let's change the tileset data files to work like the GBC hardware. We'll create **data/tilesets/\*_attributes.bin** files that assign attributes to the blocks, just like how \*_metatiles.bin assign tile IDs. We'll change the \*_metatiles.bin files to only use IDs from $00 to $7F; any tiles that were using $80 to $FF will instead have their bank bit set to 1 in the corresponding \*_attributes.bin file. + +We'll generate \*_attributes.bin and modify \*_metatiles.bin by automatically correlating the \*_palette_map.asm and \*_metatiles.bin files. The end result will *not* take advantage of X/Y flip or eliminate redundant tiles; it will just enable you to do that manually. Save this as **palmap2attr.py** in the same directory as main.asm: @@ -98,14 +121,22 @@ for palette_map_name in palette_map_names: tile_colors[tile_index] = tile_attr tile_index += 1 - print('... to', attributes_name.split('/')[-1]) + print('... to', attributes_name.split('/')[-1], '...') + metatile_bytes = b'' with open(metatiles_name, 'rb') as metatiles: with open(attributes_name, 'wb') as attributes: for block_tiles in iter(lambda: metatiles.read(16), b''): block_attrs = list(tile_colors.get(t, (t >= 0x80) << 3) for t in block_tiles) attributes.write(bytes(block_attrs)) + metatile_bytes += block_tiles + + print('... and modify', metatiles_name.split('/')[-1], '!') + + with open(metatiles_name, 'wb') as metatiles: + for t in metatile_bytes: + metatiles.write(t & 0x7f) ``` Then run `python3 palmap2attr.py`, just like running `make`. It should output: @@ -113,10 +144,12 @@ Then run `python3 palmap2attr.py`, just like running `make`. It should output: ``` $ python3 palmap2attr.py Convert aerodactyl_word_room_palette_map.asm ... -... to aerodactyl_word_room_attributes.bin +... to aerodactyl_word_room_attributes.bin ... +... and modify aerodactyl_word_room_metatiles.bin ! ... Convert underground_palette_map.asm ... -... to underground_attributes.bin +... to underground_attributes.bin ... +... and modify underground_metatiles.bin ! ``` (If it gives an error "`python3: command not found`", you need to install Python 3. It's available as the `python3` package in Cygwin.) @@ -124,7 +157,7 @@ Convert underground_palette_map.asm ... If you followed [the `PRIORITY` color tutorial](Allow-map-tiles-to-appear-above-sprites-\(so-NPCs-can-walk-behind-tiles\)-with-PRIORITY-colors) before this one, that's okay; palmap2attr.py supports `PRIORITY` colors too. If you haven't followed it, that's even better, because it's totally redundant with this one. :P -## 2. Remove the old files and include the new ones +## 3. Remove the old files and include the new ones Now that all the \*_attributes.bin files are created, delete all the \*_palette_map.asm files. Also delete [gfx/tileset_palette_maps.asm](../blob/master/gfx/tileset_palette_maps.asm). @@ -134,16 +167,16 @@ Edit [gfx/tilesets.asm](../blob/master/gfx/tilesets.asm): ... SECTION "Tileset Data 8", ROMX - + TilesetHoOhWordRoomMeta: INCBIN "data/tilesets/ho_oh_word_room_metatiles.bin" - + TilesetKabutoWordRoomMeta: INCBIN "data/tilesets/kabuto_word_room_metatiles.bin" - + TilesetOmanyteWordRoomMeta: INCBIN "data/tilesets/omanyte_word_room_metatiles.bin" - + TilesetAerodactylWordRoomMeta: INCBIN "data/tilesets/aerodactyl_word_room_metatiles.bin" + @@ -269,7 +302,7 @@ All we're doing here is `INCBIN`-ing each of the \*_attributes.bin files with an Also, notice that cave_attributes.bin is being used for the `cave` *and* `dark_cave` tilesets. That's because they already shared cave_metatiles.bin and cave_collision.asm. The only reason dark_cave_metatiles.bin and dark_cave_collision.asm exist is so programs like Polished Map can easily render tilesets and maps. -## 3. Store attribute pointers in tileset metadata +## 4. Store attribute pointers in tileset metadata Edit [data/tilesets.asm](../blob/master/data/tilesets.asm): @@ -304,7 +337,7 @@ And edit [wram.asm](../blob/master/wram.asm): Now each tileset will be associated with the correct attribute data. -## 4. Start changing how tile attributes are loaded +## 5. Start changing how tile attributes are loaded We just removed the `wTilesetPalettes` pointer and the \*_palette_map.asm data it pointed to, so it's time to see how they were being used and update that code to use the \*_attributes.bin files instead. @@ -336,12 +369,43 @@ Edit [home/palettes.asm](../blob/master/home/palettes.asm): Finally, we need to edit [home/map.asm](../blob/master/home/map.asm); but it's pretty long, and we need to do something else first. -## 5. Declare space in WRAM for on-screen tile attributes +## 6. Declare space in WRAM for on-screen tile attributes Edit [wram.asm](../blob/master/wram.asm) again: ```diff -+SECTION "Surrounding Attributes", WRAMX +-NEXTU ; c608 +-; surrounding tiles +-wSurroundingTiles:: ds SURROUNDING_WIDTH * SURROUNDING_HEIGHT +``` + +```diff + wTileset:: + wTilesetBank:: db ; d1d9 + wTilesetAddress:: dw ; d1da + wTilesetBlocksBank:: db ; d1dc + wTilesetBlocksAddress:: dw ; d1dd + wTilesetCollisionBank:: db ; d1df + wTilesetCollisionAddress:: dw ; d1e0 + wTilesetAttributesBank:: db + wTilesetAttributesAddress:: dw + wTilesetAnim:: dw ; bank 3f ; d1e2 + wTilesetEnd:: ++ ++wTilesetDataAddress:: dw +``` + +```diff +- ds 3 ++ ds 2 + + wLinkBattleRNs:: ds 10 ; d1fa +``` + +```diff ++SECTION "Surrounding Data", WRAMX ++ ++wSurroundingTiles:: ds SURROUNDING_WIDTH * SURROUNDING_HEIGHT + +wSurroundingAttributes:: ds SURROUNDING_WIDTH * SURROUNDING_HEIGHT + @@ -355,16 +419,16 @@ And edit [pokecrystal.link](../blob/master/pokecrystal.link): ```diff +WRAMX 4 -+ "Surrounding Attributes" ++ "Surrounding Data" WRAMX 5 "GBC Video" ... ``` -As we'll see next, `wSurroundingTiles` stores the tile IDs of all the blocks surrounding the player on-screen. (It gets updated when the player moves, of course.) The screen is 20x18 tiles, so 6x5 blocks are needed to cover it; each block has 4x4 tiles, so that's 480 bytes of tile data. Now that each of those tiles can have its own attributes, we need to introduce `wSurroundingAttributes` to play a similar role for attribute data. However, `wSurroundingTiles` is in WRAM0 and there's not enough free space there, so we have to put `wSurroundingAttributes` in a different bank; WRAMX 4 is conveniently unused. +As we'll see next, `wSurroundingTiles` stores the tile IDs of all the blocks surrounding the player on-screen. (It gets updated when the player moves, of course.) The screen is 20x18 tiles, so 6x5 blocks are needed to cover it; each block has 4x4 tiles, so that's 480 bytes of tile data. Now that each of those tiles can have its own attributes, we need to introduce `wSurroundingAttributes` to play a similar role for attribute data. However, there's not enough free space in WRAM0 for both `wSurroundingTiles` and `wSurroundingAttributes`, so we have to put `wSurroundingAttributes` in a different bank, and for convenience we move `wSurroundingTiles` to the same bank. WRAMX 4 happens to be unused, so that's where they go. -## 6. Continue changing how tile attributes are loaded +## 7. Continue changing how tile attributes are loaded Now we can edit [home/map.asm](../blob/master/home/map.asm). Let's go over it piece by piece. @@ -378,11 +442,11 @@ OverworldTextModeSwitch:: LoadMapPart:: ldh a, [hROMBank] push af - + ld a, [wTilesetBlocksBank] rst Bankswitch - call LoadMetatiles + ld a, "■" hlcoord 0, 0 ld bc, SCREEN_WIDTH * SCREEN_HEIGHT @@ -395,7 +459,7 @@ OverworldTextModeSwitch:: ld a, BANK(_LoadMapPart) rst Bankswitch call _LoadMapPart - + pop af rst Bankswitch ret @@ -407,19 +471,35 @@ Anyway, `LoadMapPart` calls `LoadMetatiles` to load certain data from the \*_met ```diff LoadMetatiles:: ++ ld hl, wSurroundingTiles ++ ld de, wTilesetBlocksAddress ++ jr _LoadMetatilesOrAttributes ++ ++LoadMetatileAttributes:: ++ ld hl, wSurroundingAttributes ++ ld de, wTilesetAttributesAddress ++ ; fallthrough ++ ++_LoadMetatilesOrAttributes: ++ ld a, [de] ++ ld [wTilesetDataAddress], a ++ inc de ++ ld a, [de] ++ ld [wTilesetDataAddress + 1], a ++ ; de <- wOverworldMapAnchor ld a, [wOverworldMapAnchor] ld e, a ld a, [wOverworldMapAnchor + 1] ld d, a - ld hl, wSurroundingTiles +- ld hl, wSurroundingTiles ld b, SURROUNDING_HEIGHT / METATILE_WIDTH ; 5 - + .row push de push hl ld c, SURROUNDING_WIDTH / METATILE_WIDTH ; 6 - + .col push de push hl @@ -429,7 +509,7 @@ Anyway, `LoadMapPart` calls `LoadMetatiles` to load certain data from the \*_met and a jr nz, .ok ld a, [wMapBorderBlock] - + .ok ; Load the current wSurroundingTiles address into de. ld e, l @@ -445,18 +525,24 @@ Anyway, `LoadMapPart` calls `LoadMetatiles` to load certain data from the \*_met add hl, hl add hl, hl add hl, hl - ld a, [wTilesetBlocksAddress] +- ld a, [wTilesetBlocksAddress] +- ld a, [wTilesetDataAddress] add l ld l, a - ld a, [wTilesetBlocksAddress + 1] +- ld a, [wTilesetBlocksAddress + 1] +- ld a, [wTilesetDataAddress + 1] adc h ld h, a - ++ ++ ldh a, [rSVBK] ++ push af ++ ld a, BANK(wSurroundingTiles) ; aka BANK(wSurroundingAttributes) ++ ldh [rSVBK], a + ; copy the 4x4 metatile rept METATILE_WIDTH + -1 rept METATILE_WIDTH ld a, [hli] -+ and $7f ld [de], a inc de endr @@ -469,10 +555,13 @@ Anyway, `LoadMapPart` calls `LoadMetatiles` to load certain data from the \*_met endr rept METATILE_WIDTH ld a, [hli] -+ and $7f ld [de], a inc de endr ++ ++ pop af ++ ldh [rSVBK], a ++ ; Next metatile pop hl ld de, METATILE_WIDTH @@ -498,114 +587,9 @@ Anyway, `LoadMapPart` calls `LoadMetatiles` to load certain data from the \*_met ret ``` -This routine copies data from \*_metatiles.bin (pointed to by `[wTilesetBlocksAddress]`) into `wSurroundingTiles`. We've made two small changes to it. - -One, [the bug that only allowed 128 blocks](../blob/master/docs/bugs_and_glitches.md#loadmetatiles-wraps-around-past-128-blocks) is fixed, since you'll probably need 256 to take advantage of this block attribute system. - -Two, tile IDs in \*_metatiles.bin have their high bit masked out. That used to be done with `res 7` in `SwapTextboxPalettes` and `ScrollBGMapPalettes`, but we deleted those. +The `LoadMetatiles` routine copies data from \*_metatiles.bin (pointed to by `[wTilesetBlocksAddress]`) into `wSurroundingTiles`. We've reused most of its code for `LoadMetatileAttributes`, which copies data from \*_attributes.bin (pointed to by `[wTilesetAttributesAddress]`) into `wSurroundingAttributes`. Since `wSurroundingTiles` and `wSurroundingAttributes` are not in WRAM0, we have to switch banks at one point. -(Strictly speaking, we could just store values $00–$7F in \*_metatiles.bin to begin with, and rely on bit 3 of the values in \*_attributes.asm to indicate which tile range is being used ($00–$7F or $80–$FF, VRAM bank 0 or 1). But that would break compatibility with Polished Map even worse than it already is, and it would necessitate editing the \*_metatiles.bin files too.) - -```diff - LoadMetatiles:: - ... - ret -+ -+LoadMetatileAttributes:: -+ ; de <- wOverworldMapAnchor -+ ld a, [wOverworldMapAnchor] -+ ld e, a -+ ld a, [wOverworldMapAnchor + 1] -+ ld d, a -+ ld hl, wSurroundingAttributes -+ ld b, SURROUNDING_HEIGHT / METATILE_WIDTH ; 5 -+ -+.row -+ push de -+ push hl -+ ld c, SURROUNDING_WIDTH / METATILE_WIDTH ; 6 -+ -+.col -+ push de -+ push hl -+ ; Load the current map block. -+ ; If the current map block is a border block, load the border block. -+ ld a, [de] -+ and a -+ jr nz, .ok -+ ld a, [wMapBorderBlock] -+ -+.ok -+ ; Load the current wSurroundingAttributes address into de. -+ ld e, l -+ ld d, h -+ ; Set hl to the address of the current metatile attribute data ([wTilesetAttributesAddress] + (a) tiles). -+ ld l, a -+ ld h, 0 -+rept 4 -+ add hl, hl -+endr -+ ld a, [wTilesetAttributesAddress] -+ add l -+ ld l, a -+ ld a, [wTilesetAttributesAddress + 1] -+ adc h -+ ld h, a -+ -+ ldh a, [rSVBK] -+ push af -+ ld a, BANK(wSurroundingAttributes) -+ ldh [rSVBK], a -+ -+ ; copy the 4x4 metatile -+rept METATILE_WIDTH + -1 -+rept METATILE_WIDTH -+ ld a, [hli] -+ ld [de], a -+ inc de -+endr -+ ld a, e -+ add SURROUNDING_WIDTH - METATILE_WIDTH -+ ld e, a -+ jr nc, .next\@ -+ inc d -+.next\@ -+endr -+rept METATILE_WIDTH -+ ld a, [hli] -+ ld [de], a -+ inc de -+endr -+ -+ pop af -+ ldh [rSVBK], a -+ -+ ; Next metatile -+ pop hl -+ ld de, METATILE_WIDTH -+ add hl, de -+ pop de -+ inc de -+ dec c -+ jp nz, .col -+ ; Next metarow -+ pop hl -+ ld de, SURROUNDING_WIDTH * METATILE_WIDTH -+ add hl, de -+ pop de -+ ld a, [wMapWidth] -+ add 6 -+ add e -+ ld e, a -+ jr nc, .ok2 -+ inc d -+.ok2 -+ dec b -+ jp nz, .row -+ ret -``` - -`LoadMetatileAttributes` is very similar to `LoadMetatiles`: it copies data from \*_attributes.bin (pointed to by `[wTilesetAttributesAddress]`) into `wSurroundingAttributes`. However, `wSurroundingAttributes` is not in the same RAM bank as `wTilesetAttributesAddress` (whereas `wSurroundingTiles` is), so we have to switch banks at one point. +We also fixed [the bug that only allowed 128 blocks](../blob/master/docs/bugs_and_glitches.md#loadmetatiles-wraps-around-past-128-blocks), since you'll probably need 256 to take full advantage of this block attribute system. ```diff ScrollMapDown:: @@ -618,7 +602,7 @@ Two, tile IDs in \*_metatiles.bin have their high bit masked out. That used to b + ld de, wBGMapPalBuffer + call BackupBGMapRow ... - + ScrollMapUp:: hlcoord 0, SCREEN_HEIGHT - 2 ld de, wBGMapBuffer @@ -629,7 +613,7 @@ Two, tile IDs in \*_metatiles.bin have their high bit masked out. That used to b + ld de, wBGMapPalBuffer + call BackupBGMapRow ... - + ScrollMapRight:: hlcoord 0, 0 ld de, wBGMapBuffer @@ -640,7 +624,7 @@ Two, tile IDs in \*_metatiles.bin have their high bit masked out. That used to b + ld de, wBGMapPalBuffer + call BackupBGMapColumn ... - + ScrollMapLeft:: hlcoord SCREEN_WIDTH - 2, 0 ld de, wBGMapBuffer @@ -656,13 +640,18 @@ Two, tile IDs in \*_metatiles.bin have their high bit masked out. That used to b `FarCallScrollBGMapPalettes` used to update `wBGMapPalBuffer` when the screen was scrolled. We deleted it, so now have to update it the same way as `wBGMapBuffer`. -## 7. Finish changing how tile attributes are loaded +## 8. Finish changing how tile attributes are loaded One more thing: edit [engine/overworld/load_map_part.asm](../blob/master/engine/overworld/load_map_part.asm): ```diff _LoadMapPart:: ld hl, wSurroundingTiles ++ decoord 0, 0 ++ call .copy ++ ld hl, wSurroundingAttributes ++ decoord 0, 0, wAttrMap ++.copy: ld a, [wMetatileStandingY] and a jr z, .top_row @@ -677,35 +666,11 @@ One more thing: edit [engine/overworld/load_map_part.asm](../blob/master/engine/ inc hl .left_column - decoord 0, 0 -+ call .copy -+ -+ ld hl, wSurroundingAttributes -+ ld a, [wMetatileStandingY] -+ and a -+ jr z, .top_row2 -+ ld bc, SURROUNDING_WIDTH * 2 -+ add hl, bc -+ -+.top_row2 -+ ld a, [wMetatileStandingX] -+ and a -+ jr z, .left_column2 -+ inc hl -+ inc hl -+ -+.left_column2 -+ decoord 0, 0, wAttrMap +- decoord 0, 0 + ldh a, [rSVBK] + push af -+ ld a, BANK(wSurroundingAttributes) ++ ld a, BANK(wSurroundingTiles) ; aka BANK(wSurroundingAttributes) + ldh [rSVBK], a -+ call .copy -+ pop af -+ ldh [rSVBK], a -+ ret -+ -+.copy: ld b, SCREEN_HEIGHT .loop ld c, SCREEN_WIDTH @@ -724,13 +689,15 @@ One more thing: edit [engine/overworld/load_map_part.asm](../blob/master/engine/ .carry dec b jr nz, .loop ++ pop af ++ ldh [rSVBK], a ret ``` -This routine initializes `wSurroundingTiles` with the relevant area of map data. Here we've updated it to also initialize `wSurroundingAttributes`, which is slightly complicated by the need to switch banks when doing so. +The `_LoadMapPart` routine initializes `wSurroundingTiles` with the relevant area of map data. Here we've updated it to also initialize `wSurroundingAttributes`, and switch to the new WRAM bank that both of them are in. -## 8. Remove unreferenced code in home/ to make room +## 9. Remove unreferenced code in home/ to make room We're almost done, but if you run `make` now, it gives an error: @@ -738,7 +705,7 @@ We're almost done, but if you run `make` now, it gives an error: error: Unable to place 'Home' (ROM0 section) at $150 ``` -Turns out that `LoadMetatileAttributes` was too large to fit in ROM0. We'll need to remove something else from that bank to make room. Luckily, Game Freak left some unused code here and there, and it's all been labeled as `Unreferenced`. +Turns out that our additions to [home/map.asm](../blob/master/home/map.asm) were too large to fit in ROM0. We'll need to remove something else from that bank to make room. Luckily, Game Freak left some unused code here and there, and it's all been labeled as `Unreferenced`. - `Unreferenced_Function2816` in [home/map.asm](../blob/master/home/map.asm) (again) - `Unreferenced_Function3d9f` in [home/audio.asm](../blob/master/home/audio.asm) |