Map 0xFF (summary)

From Glitch City Wiki
Jump to navigation Jump to search
This article is a summary page for different variations of a glitches, etc. when talked about as a whole.
Town Map name: (Blank)

Identifier (HEX) FF
Identifier (DEC) 255
Default track Unknown
Tileset Unknown
Size Unknown
Map type Special map handler,
Freeze glitch map

Map 0xFF is a glitch map in Pokémon Red, Blue, and Yellow. It is often "visited", sometime accidentally, by stepping out of bounds from a map without a connecting map in the appropriate direction, since non-existent map connections are represented by the value 0xFF in the game's data. It usually freezes the game due to its enormous size, which causes a buffer overflow when loading the map block data that corrupts the stack. Furthermore, several of its properties would freeze the game if the game didn't already freeze due to the buffer overflow.

However, the value 0xFF has a special meaning when used as a warp destination from an "indoor" map, indicating that the warp should go back to wLastMap, which is normally the last "outdoor" map the player was in. This is often exploited in glitching, since wLastMap can be easily modified through the expanded item pack.

As a warp destination

As a warp destination, the index 0xFF is an indoor-outside map handler in Pokémon Red, Blue, and Yellow. It often used for the exit warps of buildings, which by design should always go back to the "last outside map" (e.g. leaving a Pokémon Center always returns the player to the "last town").

To elaborate, all warps on the current map is stored in a table wWarpEntries (starting from $D3AF in R/B and $D3AE in Y), where each entry is 4 bytes: Y coordinate, X coordinate, exit index, and map index. The coordinates are for the location of the warp on the current map (e.g. for the exit warp of a building, they may be the coordinates of the exit mat). The map index determines the destination map, and the exit index determines the exact location the player should be warped to on the destination map. In other words, each map that can be warped to have a list of "exit locations" defined.

However, when the game reads 0xFF in the "map index" field, if the current map is an "indoor" map (i.e. any map that the player cannot Fly/Teleport from; this includes some locations that are actually outdoor, such as Viridian Forest and the interior of the Safari Zone), then the map stored in wLastMap ($D365 in R/B and $D364 in Y) is used as the destination map instead[1].

Notably, when the player uses such a warp, the exit index is still respected. This is why gates on routes (which have two different exits that lead to different coordinates on the same outside map) can still use 0xFF warps. This is also why the Safari Zone exit glitch can cause a glitch city: The Safari Zone gate always warps to exit location #4 on wLastMap, which when performing the Safari Zone exit glitch may no longer be Fuchsia City, and not all outside maps have a valid exit location #4 defined.

Detailed data flow

When the game detects the player using a warp, the exit index is copied into wDestinationWarpID ($D42F in R/B and $D42E in Y), and the map index is copied into hWarpDestinationMap ($FF8B). Then, hWarpDestinationMap (the map index) is normally copied to wCurMap, causing the player to warp there. However, when the 0xFF indoor-outside map handler is triggered, wLastMap is copied to wCurMap instead.

Afterwards, wDestinationWarpID (the exit index) is used as a basis for loading relevant data pertaining to the destination map, such as the player's new coordinates, as well as wCurrentTileBlockMapViewPointer ($D35F–$D360 in R/B and $D35E–$D35F in Y). (In order to do this, the game also needs to locate the map header from LoadMapHeader using the pointer table at MapHeaderPointers; this function also loads much of the data pertaining to any map.)

In order for an indoor-outside map to work, the current map must be a "indoor" map, which is defined as any map with a tileset index (wCurMapTileset, $D367 in R/B and $D366 in Y) other than 0 (overworld) or 23 (Indigo Plateau)[2]; hence indoor-outside warps will be ignored in maps (such as towns themselves) with overworld tilesets.

As a glitch map

Main article: AreaDex/RB:255
Main article: AreaDex/Y:255

As a glitch map, it is a common freeze glitch map that the game attempts to put the player in for stepping out of bounds when a certain connection (North, West, South or East) doesn't exist, usually resulting in a freeze. This is because the game typically loads any unused connection entries as map 0xFF.

It is a reliable way of causing the bar freeze in all versions later than Japanese Yellow v1.0. Namely, Japanese Yellow v1.1-1.3, English, French, German, Italian and Spanish Red/Blue/Yellow.

However, in Pokémon Red and Green (both v1.0 and v1.1), Japanese Blue, and Pokémon Yellow (Japanese) v1.0, it can result in an out of bounds Glitch Hell though more specifically involves an exploitable jump to jp F080 (Echo RAM for D080) (arbitrary code execution).

When D365 or D364 is also set to 0xFF, exiting through an indoor exit may cause the game to simply freeze with a white screen. In Spanish Yellow, map 0x0B may warp the player to a map 0xFF that may either serve as a freeze glitch map or redirection glitch map to Team Rocket Hideout B1F (map 0xC7) valid source map Glitch City.

If map 0xFF typically freezes the game, it may still be possible to 'access' map 0xFF by locking/changing any attributes which contribute to its freezes (i.e. its map height/width to not be too large, its sound bank to be one of the valid values 02, 08, 1F, 20 (28 in Japanese Yellow), W_MAPSCRIPTPTR (D36E-F (D36D-E in Yellow) to point to a script which doesn't freeze the game, etc.).

Attribution

  • FutureFractal discovered the exact reason map 0xFF freezes the game by tracing in the debugger, and found a way to explore map 0xFF by suppressing all its properties that would crash the game with GameShark codes and debugger commands.

References