Anonymous user
Map 0xFF (summary): Difference between revisions
Restructured the page.
>Torchickens (Created page with "{{Summary page}} {{MapInfoGenI|(Blank)|Map FF Town Map.png|FF|255|Unknown|Unknown|Unknown|Special map handler,<br>Freeze glitch map}} '''Map 0xFF''' is a game mechanic in...") |
(Restructured the page.) |
||
| (16 intermediate revisions by 3 users not shown) | |||
Line 1:
{{Summary page}}
{{
'''Map 0xFF''' is a
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]].
As a [[Glitch City|glitch location]], it is a common [[freeze 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 but possibly an [[out of bounds Glitch Hell]] in {{RG}} and {{JY}} v1.0.▼
== As a warp destination ==
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]] which doesn't immediately freeze the game, but still results in a freeze it regardless.▼
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.
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>.
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==
{{main|AreaDex/RB:255}}
{{main|AreaDex/Y:255}}
▲As a [[Glitch City|glitch
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
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 ==
<references />
[[Category:Glitch areas]]
| |||