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...") |
|||
| (3 intermediate revisions by the same user not shown) | |||
| 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 == | ||
| Line 20: | Line 23: | ||
Room flags are stored as a {{WP|bit field}} in 3 main addresses in [[WRAM]]: | Room flags are stored as a {{WP|bit field}} in 3 main addresses in [[WRAM]]: | ||
{| | {| | ||
| − | | | + | | style="vertical-align: top" | |
{{Bit field | {{Bit field | ||
|title=Address $0401 | |title=Address $0401 | ||
| Line 32: | Line 35: | ||
|name0=u|desc0=Unused | |name0=u|desc0=Unused | ||
}} | }} | ||
| − | | | + | | style="vertical-align: top" | |
{{Bit field | {{Bit field | ||
|title=Address $0403 | |title=Address $0403 | ||
| Line 44: | Line 47: | ||
|name0=C<sub>1</sub>|desc0=Chest 1 opened | |name0=C<sub>1</sub>|desc0=Chest 1 opened | ||
}} | }} | ||
| − | | | + | | style="vertical-align: top" | |
{{Bit field | {{Bit field | ||
|title=Address $0408 | |title=Address $0408 | ||
| Line 118: | Line 121: | ||
| Reuses chest 5 as a flag for whether or not the wall has been moved | | Reuses chest 5 as a flag for whether or not the wall has been moved | ||
|} | |} | ||
| + | |||
| + | === Dungeon Prizes === | ||
| + | Crystals and pendants don't set any bit in room data when collected, but they do specifically check for the Key bit before they spawn. This is likely vestigial behavior from an earlier point in development, but the consequence of it is that spoofing a collected key into a boss room will prevent its prize from being dropped. | ||
| + | |||
| + | [[Category:Major Glitches]] | ||
Latest revision as of 12:02, 27 August 2021
 | 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 |
Dungeon Prizes
Crystals and pendants don't set any bit in room data when collected, but they do specifically check for the Key bit before they spawn. This is likely vestigial behavior from an earlier point in development, but the consequence of it is that spoofing a collected key into a boss room will prevent its prize from being dropped.
