Difference between revisions of "Data spoofing"

From ALttP Speedrunning Wiki
Jump to: navigation, search
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

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

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:

  1. These game mode changes are done via incrementation
  2. 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 fieldWikipedia logo.svg in 3 main addresses in WRAM:

Address $0401
BitNameDescriptionValue
7D0Door 0 opened27$80
6D1Door 1 opened26$40
5D2Door 2 opened25$20
4D3Door 3 opened24$10
3uUnused23$08
2uUnused22$04
1uUnused21$02
0uUnused20$01
Address $0403
BitNameDescriptionValue
7HHeart container obtained/Boss killed27$80
6KKey obtained26$40
5cUnused 6th chest or 2nd key25$20
4C5Chest 5 opened
Rupee tiles grabbed
24$10
3C4Chest 4 opened23$08
2C3Chest 3 opened22$04
1C2Chest 2 opened21$02
0C1Chest 1 opened20$01
Address $0408
BitNameDescriptionValue
7uUnused27$80
6uUnused26$40
5uUnused25$20
4uUnused24$10
3Q4North-west quadrant visited23$08
2Q3North-east quadrant visited22$04
1Q2South-west quadrant visited21$02
0Q1South-east quadrant visited20$01

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.

Address $7EF000, X
BitNameDescriptionValue
15D0Door 0 opened215$8000
14D1Door 1 opened214$4000
13D2Door 2 opened213$2000
12D3Door 3 opened212$1000
11HHeart container obtained/Boss killed211$0800
10KKey obtained210$0400
9cUnused 6th chest or 2nd key29$0200
8C5Chest 5 opened / Rupee tiles grabbed28$0100
7C4Chest 4 opened27$0080
6C3Chest 3 opened26$0040
5C2Chest 2 opened25$0020
4C1Chest 1 opened24$0010
3Q4North-west quadrant visited23$0008
2Q3North-east quadrant visited22$0004
1Q2South-west quadrant visited21$0002
0Q1South-east quadrant visited20$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