Map 0xFF (summary): Difference between revisions
No edit summary |
Restructured the page. |
||
(11 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{Summary page}} |
{{Summary page}} |
||
{{ |
{{MapInfoGenIOld|(Blank)|Map FF Town Map.png|FF|255|Unknown|Unknown|Unknown|Special map handler,<br>[[Freeze glitch map]]}} |
||
'''Map 0xFF''' is a glitch map in {{RBY}}. It is often "visited", sometime accidentally, by [[Freeze tile|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. |
|||
'''Map 0xFF''' is an indoor-outside map handler in {{RBY}}. When the game locates it, it [https://github.com/pret/pokered/blob/8349bfd8e646002105dfd6a7f997c26cf0e0624b/home/overworld.asm indoor-outside map handler] does not load map 0xFF itself; rather upon following the warp, the actual map loaded is replaced with wLastMap (D365 in R/B and D365 in Y). This handler is stored as a map in wWarpEntries (D3AF onward (D3AE onward in Yellow) and each entry is stored as Y coordinate, X coordinate, exit index, map (or FF handler)). |
|||
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 <code>wLastMap</code>, which is normally the last "outdoor" map the player was in. This is often exploited in glitching, since <code>wLastMap</code> can be easily modified through the [[expanded item pack]]. |
|||
The coordinates typically pertain to the exit mats in buildings when the player bumps into the wall to leave the map (the way for instance, leaving a Pokémon Center returns the player to the 'last town'). The exit index is a single byte as an index number. |
|||
== As a warp destination == |
|||
⚫ | |||
As a warp destination, the index 0xFF is an indoor-outside map handler in {{RBY}}. 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 <code>wWarpEntries</code> (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. |
|||
For example, exit index 0 can be seen as 'position to place the player in the new map #0', index 1 as 'position to place the player in the new map #1' and so on. This is the reason why different exit warps each make the player step down from different buildings, and the cause of [[Safari Zone exit glitch]] when wLastMap is no longer Fuchsia City and wWarpEntries still pertains to the Safari Zone gate. |
|||
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 <code>wLastMap</code> ($D365 in R/B and $D364 in Y) is used as the destination map instead<ref>The lines of code to [https://github.com/pret/pokered/blob/e076ee0a40b2a21183e2cc535519e64b706b5407/home/overworld.asm#L509-L511 check whether the warp destination is 0xFF] and [https://github.com/pret/pokered/blob/e076ee0a40b2a21183e2cc535519e64b706b5407/home/overworld.asm#L531-L532 use <code>wLastMap</code> as the destination map if so]</ref>. |
|||
In order for an indoor-outside map to work, W_CURMAPTILESET (D367 in R/B and D366 in Y) must be greater than 0 (overworld tileset); hence indoor-outside warps will be ignored in maps (such as towns themselves) with overworld tilesets. |
|||
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 <code>wLastMap</code>, 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 <code>wDestinationWarpID</code> ($D42F in R/B and $D42E in Y), and the map index is copied into <code>hWarpDestinationMap</code> ($FF8B). Then, <code>hWarpDestinationMap</code> (the map index) is normally copied to <code>wCurMap</code>, causing the player to warp there. However, when the 0xFF indoor-outside map handler is triggered, <code>wLastMap</code> is copied to <code>wCurMap</code> instead. |
|||
⚫ | Afterwards, <code>wDestinationWarpID</code> (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 <code>wCurrentTileBlockMapViewPointer</code> ($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 <code>LoadMapHeader</code> using the pointer table at <code>MapHeaderPointers</code>; 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 (<code>wCurMapTileset</code>, $D367 in R/B and $D366 in Y) other than 0 (overworld) or 23 (Indigo Plateau)<ref>[https://github.com/pret/pokered/blob/e076ee0a40b2a21183e2cc535519e64b706b5407/home/overworld.asm#L705-L711 The function to check whether the player is in an "outdoor" map or an "indoor" map]</ref>; hence indoor-outside warps will be ignored in maps (such as towns themselves) with overworld tilesets. |
|||
==As a glitch map== |
==As a glitch map== |
||
{{main|AreaDex/RB:255}} |
|||
As a [[Glitch City|glitch map]], it is a common [[freeze glitch map]] that player attempts to put the player in for stepping [[out of bounds]] when an x or y connection doesn't exist, usually resulting in a freeze. It is a reliable way of causing the [[game freeze#bar freeze|bar freeze]] in all versions prior to Japanese Yellow v1.1. For {{RG}} and {{JY}} v1.0, it can result in an [[out of bounds Glitch Hell]] though more specifically involves an exploitable jump to <code>jp F080</code> (Echo RAM for D080) ([[arbitrary code execution]]). |
|||
{{main|AreaDex/Y:255}} |
|||
As a [[Glitch City|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 [[game freeze#bar freeze|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 {{RG}} (both v1.0 and v1.1), Japanese Blue, and {{JY}} v1.0, it can result in an [[out of bounds Glitch Hell]] though more specifically involves an exploitable jump to <code>jp F080</code> (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 (Spanish Yellow)|map 0x0B]] may warp the player to [[Map 0xFF (Spanish Yellow)|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]]. |
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 (Spanish Yellow)|map 0x0B]] may warp the player to [[Map 0xFF (Spanish Yellow)|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.). |
|||
{{clr}} |
|||
== 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 == |
|||
<references /> |
|||
[[Category:Glitch areas]] |
[[Category:Glitch areas]] |
Latest revision as of 12:56, 4 January 2023
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.