Underworld:Important Hex Addresses/Object Data - Revision history

Tatters: /* Subtype 3 Objects */

2017-12-24T00:21:11Z

‎Subtype 3 Objects

Tatters: /* Subtype 2 Objects, 1st, 2nd, & 3rd bytes */

2017-12-24T00:20:49Z

‎Subtype 2 Objects, 1st, 2nd, & 3rd bytes

Tatters at 00:19, 24 December 2017

2017-12-24T00:19:58Z

Tatters: Created page with "{{subpage|Underworld:Important Hex Addresses}} ==Data location== * {{$|0F8000}} to {{$|0F83BF}} = Pointer Table, 3 byte long addresses, indexed by room ID. * {{$|01EBA0}} to {..."

2017-12-24T00:17:39Z

Created page with "{{subpage|Underworld:Important Hex Addresses}} ==Data location== * {{$|0F8000}} to {{$|0F83BF}} = Pointer Table, 3 byte long addresses, indexed by room ID. * {{$|01EBA0}} to {..."

New page

{{subpage|Underworld:Important Hex Addresses}}
==Data location==
* {{$|0F8000}} to {{$|0F83BF}} = Pointer Table, 3 byte long addresses, indexed by room ID.
* {{$|01EBA0}} to {{$|01FFF4}} = Data
* {{$|050000}} to {{$|053729}} = Data
* {{$|0F8780}} to {{$|0FFF4D}} = Data

==Byte layout==
* Byte 0: {{red|aaaa}} {{blue|bbbb}}.
**The a bits are transformed to {{red|aaaa}}{{hex|0000}} and select the type of empty space to fill in. Hyrule Magic calls this 'Floor 1' - Gets stored to {{$|7E0490}}
**The b bits are transformed to {{blue|bbbb}}{{hex|0000}} and are the what Hyrule Magic calls 'Floor 2' - Gets stored to {{$|7E046A}}

* Byte {{hex|1}}: {{red|aaa}}{{blue|b bb}}{{green|c}}{{purple|d}}
** The {{red|a}} bits are unused and should not be used
** The {{blue|b}} bits determine the room's layout type, ranging from {{hex|0}} to {{hex|7}}.
** The {{green|c}} and {{purple|d}} bits are unknown, but I have a feeling it's related to {{$|AA}} and {{$|A9}}

After that the bytes come in {{hex|3}} or {{hex|2}} byte object structures, used by routine {{$|01:88E4}}. Objects are loaded until an object with value {{0x|FFFF}} occurs. If a value {{0x|FFF0}} is loaded, the game will start loading Type 2 objects and will not go back to loading Type 1 objects until it is time to load the next layer. (Layer as in HM, not to be confused with the SNES' Backgrounds.) A value of {{0x|FFFF}} will also terminate the loading of Type 2 objects. The routine immediately terminates if that happens during the loading of either object type.

===Type 1 Object structure: (3 bytes)===

* Byte {{hex|3}}: Routine to use. If this byte is ≥ {{0x|F8}} and < {{0x|FC}}, then it is a subtype 3 object. If the index is ≥ {{hex|FC}}, it is a subtype 2 object. If not, it is a subtype 1 object.

* Subtype 1 Objects, first and second byte
** High Byte: {{brown|yyyy yy}}{{green|cc}}
** Low Byte: {{grey|xxxx xx}}{{red|aa}}
*** The {{red|a}} bits are stored to {{$|B2}}
*** The {{green|c}} bits are stored to {{$|B4}}
*** The {{grey|x}} and {{brown|y}} bits are transformed into: {{hex|000}}{{brown|y yyyy y}}{{grey|xxx xxx}}{{hex|0}} - This is a tilemap address that indexes into {{$|7E2000}} and / or {{$|7E4000}}

Use Byte {{hex|3}} * 2 as an index into the table at {{$|8200}}. This is the routine that is used to draw and otherwise handle the object. Subtype 1 objects have a maximum width and height of 4. Width and height are measured in terms of 32 {{x}} 32 pixels. (⟸ last part is questionable)

====Subtype 2 Objects, 1st, 2nd, & 3rd bytes====
** Byte {{hex|3}}: {{white|ff}}{{purple|dd dddd}}
** Byte {{hex|2}}: {{pink|eeee}} {{green|cccc}}
** Byte {{hex|1}}: {{red|aaaa aa}}{{blue|bb}}
***The {{red|a}} bits are unused, but after all they are the marker for this type of object subtype.
***The {{blue|b}}, {{green|c}}, {{pink|e}}, and {{white|f}} bits are transformed into a VRAM tilemap address: {{hex|000}}{{green|c ccc}}{{white|f}} {{white|f}}{{blue|bb}}{{pink|e eee}}{{hex|0}}

Might I add this is one messed up format? The {{purple|d}} bits are used as an index into the table at {{$|8470}}. Since such indices are going to be even, the {{purple|d}} bits are transformed into: {{hex|0000 0000 0}}{{purple|ddd ddd}}{{hex|0}}.

====Subtype 3 Objects====
**Similar to Subtype 1, with a few small exceptions.
**The vram address is calculated the same way. However, {{$|B2}} and {{$|B4}} are not used as length or width dimensions here. The routine that is used is determined as follows:
**Take the original index (times two) that a Subtype 1 would have used. AND that with {{0x|000E}}. Then shift left 3 times to produce {{hex|0000 0000 0}}{{pink|eee}} {{hex|0000}}. Then, OR in {{$|B2}} and {{$|B4}} and shift left once, so the final result is: {{hex|0000 0000}} {{pink|eee}}{{red|a a}}{{blue|bb}}{{hex|0}}.
**Also, this value indexes into {{$|85F0}} instead of {{$|8200}}.

===Type 2 Object Structure: (2 bytes)===
*High Byte: {{green|cccc cccc}}
*Low Byte: {{blue|bbbb}} {{purple|dd}}{{red|aa}}
**The {{red|a}} bits form a 2-bit value ({{hex|0000 0}}{{red|aa}}{{hex|0}}) that determines the routine to use for the object. In Hyrule Magic, corresponds to the "direction" of the door.
**The {{blue|b}} bits are transformed into {{hex|000}}{{blue|b bbb}}{{hex|0}} and stored to {{$|02}} ⟹ X. Corresponds to "Pos" of door objects in the Hyrule Magic. Note that these range from {{0x|00}} to {{0x|16}} (always even) which if you halve those values is 0 - 11 in decimal. This is easily verifiable in Hyrule Magic.
**The {{green|c}} bits are shifted into the lower byte and stored to {{$|04}} ⟹ A and {{$|0A}}. This is later used to grab the tiles used to draw the door and the area below it. In Hyrule Magic, corresponds to "type". Note the type is 1/2 of the number listed here. This is because to avoid using an ASL A command, the {{green|c}} bits are always even.
**The {{purple|d}} bits are unused.

Next I'll go into the nitty gritty of the various types (the value of {{$|04}}). Again note that we'll only be dealing with even values {{blue|b}}/{{green|c}} that's what you'll see in the code. To convert between here [as well as the code] and Hyrule Magic, take the hex value here and divide by two. Convert to decimal and that's your Hyrule Magic "type."

*Types:
{|{{Prettytable}}
! ID
! Description
|-
|{{0x|00}}
|Basic door. Index = {{$|0460}}
|-
|{{0x|02}}
|Normal door?
|-
|{{0x|04}}
|???
|-
|{{0x|06}}
|???
|-
|{{0x|08}}
|Waterfall door (only used in Swamp palace; in one room at that!)
|-
|{{0x|0A}}
|???
|-
|{{0x|0C}}
|Trap door (probably other types but this seems to be most common)
|-
|{{0x|12}}
|Adds a property to some doors allowing you to exit to the overworld (this is accomplished by writing to the tile attribute map)
|-
|{{0x|14}}
|Transition to dark room?
|-
|{{0x|16}}
|Toggles the target BG Link will emerge on. '''Ex.''' if Link starts on BG0 in the next room he'll be on BG1.
|-
|{{0x|20}}
| rowspan="2"|Locked door specifically for BG0.
|-
|{{0x|22}}
|-
|{{0x|24}}
| rowspan="2"|Locked door for either BG0 or BG1
|-
|{{0x|26}}
|-
|{{0x|30}}
|Large exploded pathway resulting from a switch being pulled (unusual to have as a door as it's huge)
|-
|{{0x|32}}
|Sword activated door. '''Ex.''' Agahnim's room with the curtain door you have to slash.
|-
|{{0x|46}}
|warp door?
|}

{{toc}}

@@ Line 41: / Line 41: @@
 ====Subtype 3 Objects====
-**Similar to Subtype 1, with a few small exceptions.
+*Similar to Subtype 1, with a few small exceptions.
-**The vram address is calculated the same way. However, {{$|B2}} and {{$|B4}} are not used as length or width dimensions here. The routine that is used is determined as follows:
+*The vram address is calculated the same way. However, {{$|B2}} and {{$|B4}} are not used as length or width dimensions here. The routine that is used is determined as follows:
-**Take the original index (times two) that a Subtype 1 would have used. AND that with {{0x|000E}}. Then shift left 3 times to produce {{hex|0000 0000 0}}{{pink|eee}} {{hex|0000}}. Then, OR in {{$|B2}} and {{$|B4}} and shift left once, so the final result is: {{hex|0000 0000}} {{pink|eee}}{{red|a a}}{{blue|bb}}{{hex|0}}.
+*Take the original index (times two) that a Subtype 1 would have used. AND that with {{0x|000E}}. Then shift left 3 times to produce {{hex|0000 0000 0}}{{pink|eee}} {{hex|0000}}. Then, OR in {{$|B2}} and {{$|B4}} and shift left once, so the final result is: {{hex|0000 0000}} {{pink|eee}}{{red|a a}}{{blue|bb}}{{hex|0}}.
-**Also, this value indexes into {{$|85F0}} instead of {{$|8200}}.
+*Also, this value indexes into {{$|85F0}} instead of {{$|8200}}.
 ===Type 2 Object Structure: (2 bytes)===

@@ Line 32: / Line 32: @@
 ====Subtype 2 Objects, 1st, 2nd, & 3rd bytes====
-** Byte {{hex|3}}: {{white|ff}}{{purple|dd dddd}}
+* Byte {{hex|3}}: {{white|ff}}{{purple|dd dddd}}
-** Byte {{hex|2}}:  {{pink|eeee}} {{green|cccc}}
+* Byte {{hex|2}}:  {{pink|eeee}} {{green|cccc}}
-** Byte {{hex|1}}: {{red|aaaa aa}}{{blue|bb}}
+* Byte {{hex|1}}: {{red|aaaa aa}}{{blue|bb}}
-***The {{red|a}} bits are unused, but after all they are the marker for this type of object subtype.
+**The {{red|a}} bits are unused, but after all they are the marker for this type of object subtype.
-***The {{blue|b}}, {{green|c}}, {{pink|e}}, and {{white|f}} bits are transformed into a VRAM tilemap address: {{hex|000}}{{green|c ccc}}{{white|f}} {{white|f}}{{blue|bb}}{{pink|e eee}}{{hex|0}}
+**The {{blue|b}}, {{green|c}}, {{pink|e}}, and {{white|f}} bits are transformed into a VRAM tilemap address: {{hex|000}}{{green|c ccc}}{{white|f}} {{white|f}}{{blue|bb}}{{pink|e eee}}{{hex|0}}
 Might I add this is one messed up format? The {{purple|d}} bits are used as an index into the table at {{$|8470}}. Since such indices are going to be even, the {{purple|d}} bits are transformed into: {{hex|0000 0000 0}}{{purple|ddd ddd}}{{hex|0}}.

@@ Line 1: / Line 1: @@
-{{subpage|Underworld:Important Hex Addresses}}
+{{subpage|Underworld:Important Hex Addresses#Object_Data}}
 ==Data location==
 * {{$|0F8000}} to {{$|0F83BF}} = Pointer Table, 3 byte long addresses, indexed by room ID.