Difference between revisions of "Data spoofing"
(Created page with "{{Technical}} '''Data spoofing''' is a common door glitch effect that writes data from one supertile to another. == Mechanics == === Conflict === The main conflict arises wh...") |
(No difference)
|
Revision as of 09:56, 16 May 2019
This article goes into very technical detail. The information is presented with the assumption that the reader has at least basic knowledge of hexadecimal, bitwise operations, SNES memory, and/or SNES assembly. |
Data spoofing is a common door glitch effect that writes data from one supertile to another.
Contents
Mechanics
Conflict
The main conflict arises when a door glitch triggers the game mode change for supertile transitions. The important information to know is 2 part:
- These game mode changes are done via incrementation
- The data loading routine is done immediately, from within the default submodule
The first problem explains why we are able to perform many door glitches in the first place. The second problem explains why data spoofing happens when it does. Let's look at 2 pairs quick examples:
Example 1: YBAs
Using a red YBA on a subtile door, we corrupt the game mode to $0E
/$05
. Using it on a super tile door, we get $0E
/$06
. The subtile YBA only corrupted the red potion game mode with a subtile transition; ditto for the supertile YBA. Only the supertile YBA will result in a data spoof.
Example 2: Somaria
When we perform a somaria juke on a subtile door, we corrupt the game mode to $07
/$03
. This is by having the game run the subtile transition set up (+1) followed by the supertile transition set up (+2). When performing a somaria juke on a supertile door, we get the same game mode, but from a different order. In those cases, we get a supertile set up first (+2), then then subtile set up (+1). In both cases, we get the same corrupted game mode. We also touched the supertile set up for both, so both somaria jukes will result in data spoofs.
Organization of data
Room flags are stored as a bit field in 3 main addresses in WRAM:
|
|
|
When a new room is loaded, these values are transferred to SRAM, creating a new bit field. In the table caption below, X
is equal to 2×Room ID.
Bit | Name | Description | Value | |
---|---|---|---|---|
15 | D0 | Door 0 opened | 215 | $8000 |
14 | D1 | Door 1 opened | 214 | $4000 |
13 | D2 | Door 2 opened | 213 | $2000 |
12 | D3 | Door 3 opened | 212 | $1000 |
11 | H | Heart container obtained/Boss killed | 211 | $0800 |
10 | K | Key obtained | 210 | $0400 |
9 | c | Unused 6th chest or 2nd key | 29 | $0200 |
8 | C5 | Chest 5 opened / Rupee tiles grabbed | 28 | $0100 |
7 | C4 | Chest 4 opened | 27 | $0080 |
6 | C3 | Chest 3 opened | 26 | $0040 |
5 | C2 | Chest 2 opened | 25 | $0020 |
4 | C1 | Chest 1 opened | 24 | $0010 |
3 | Q4 | North-west quadrant visited | 23 | $0008 |
2 | Q3 | North-east quadrant visited | 22 | $0004 |
1 | Q2 | South-west quadrant visited | 21 | $0002 |
0 | Q1 | South-east quadrant visited | 20 | $0001 |
Unique uses
Several rooms use the room flags slightly differently:
ID | Room | Bit | Function |
---|---|---|---|
$37
|
Swamp switch 1 | C4 | Reuses chest 4 as a flag for whether the room has been (un)flooded |
$35
|
Swamp switch 2 | ||
$66
|
Swamp switch 3 | ||
$65
|
Thieves' Town attic | C5 | Reuses chest 5 as a flag for whether or not the bombable floor has been broken |
$1B
|
Palace of Darkness moving wall | C4 | Reuses chest 4 as a flag for whether or not the wall has been moved |
$43
|
Desert Palace moving wall | ||
$97
|
Misery Mire torches | C5 | Reuses chest 5 as a flag for whether or not the wall has been moved |