Difference between revisions of "Data spoofing"
Line 1: | Line 1: | ||
{{Technical}} | {{Technical}} | ||
'''Data spoofing''' is a common door glitch effect that writes data from one supertile to another. | '''Data spoofing''' is a common door glitch effect that writes data from one supertile to another. | ||
+ | |||
+ | == Layman explanation == | ||
+ | Data for rooms is stored in memory as flags that are either on or off. Whenever the room ID changes, this data is written to Save RAM. Under normal conditions, data for the next room is then loaded from Save RAM and overwrites the old data for the previous room. With certain door glitches, the save is performed, but the load is not, because it was interrupted by the transition not happening. When this happens, the old room data is still there but with the current room pointing to the new room. Thus, when the room ID is changed again from any sort of transition or glitch, it will write the original room's data into Save RAM. | ||
== Mechanics == | == Mechanics == |
Revision as of 10:23, 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
Layman explanation
Data for rooms is stored in memory as flags that are either on or off. Whenever the room ID changes, this data is written to Save RAM. Under normal conditions, data for the next room is then loaded from Save RAM and overwrites the old data for the previous room. With certain door glitches, the save is performed, but the load is not, because it was interrupted by the transition not happening. When this happens, the old room data is still there but with the current room pointing to the new room. Thus, when the room ID is changed again from any sort of transition or glitch, it will write the original room's data into Save RAM.
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 |