Difference between revisions of "Underworld:Important Hex Addresses/Object Data"

From TLoZ: ALTTP Hacking Resources
Jump to: navigation, search
m
m (→‎Subtype 3 Objects)
 
(One intermediate revision by the same user not shown)
Line 32: Line 32:
  
 
====Subtype 2 Objects, 1st, 2nd, & 3rd bytes====
 
====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}}.
 
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====
 
====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)===
 
===Type 2 Object Structure: (2 bytes)===

Latest revision as of 01:21, 24 December 2017

This is a subpage of Underworld:Important Hex Addresses#Object_Data

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: aaaa bbbb.
    • The a bits are transformed to aaaa0000 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 bbbb0000 and are the what Hyrule Magic calls 'Floor 2' - Gets stored to $7E046A
  • Byte 1: aaab bbcd
    • The a bits are unused and should not be used
    • The b bits determine the room's layout type, ranging from 0 to 7.
    • The c and d bits are unknown, but I have a feeling it's related to $AA and $A9

After that the bytes come in 3 or 2 byte object structures, used by routine $01:88E4. Objects are loaded until an object with value 0xFFFF occurs. If a value 0xFFF0 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 0xFFFF 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 3: Routine to use. If this byte is ≥ 0xF8 and < 0xFC, then it is a subtype 3 object. If the index is ≥ FC, it is a subtype 2 object. If not, it is a subtype 1 object.
  • Subtype 1 Objects, first and second byte
    • High Byte: yyyy yycc
    • Low Byte: xxxx xxaa
      • The a bits are stored to $B2
      • The c bits are stored to $B4
      • The x and y bits are transformed into: 000y yyyy yxxx xxx0 - This is a tilemap address that indexes into $7E2000 and / or $7E4000

Use Byte 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 ‍×​ 32 pixels. (⟸ last part is questionable)

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

  • Byte 3: ffdd dddd
  • Byte 2: eeee cccc
  • Byte 1: aaaa aabb
    • The a bits are unused, but after all they are the marker for this type of object subtype.
    • The b, c, e, and f bits are transformed into a VRAM tilemap address: 000c cccf fbbe eee0

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

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 0x000E. Then shift left 3 times to produce 0000 0000 0eee 0000. Then, OR in $B2 and $B4 and shift left once, so the final result is: 0000 0000 eeea abb0.
  • Also, this value indexes into $85F0 instead of $8200.

Type 2 Object Structure: (2 bytes)

  • High Byte: cccc cccc
  • Low Byte: bbbb ddaa
    • The a bits form a 2-bit value (0000 0aa0) that determines the routine to use for the object. In Hyrule Magic, corresponds to the "direction" of the door.
    • The b bits are transformed into 000b bbb0 and stored to $02 ⟹ X. Corresponds to "Pos" of door objects in the Hyrule Magic. Note that these range from 0x00 to 0x16 (always even) which if you halve those values is 0 - 11 in decimal. This is easily verifiable in Hyrule Magic.
    • The 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 c bits are always even.
    • The 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 b/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:
ID Description
0x00 Basic door. Index = $0460
0x02 Normal door?
0x04 ???
0x06 ???
0x08 Waterfall door (only used in Swamp palace; in one room at that!)
0x0A ???
0x0C Trap door (probably other types but this seems to be most common)
0x12 Adds a property to some doors allowing you to exit to the overworld (this is accomplished by writing to the tile attribute map)
0x14 Transition to dark room?
0x16 Toggles the target BG Link will emerge on. Ex. if Link starts on BG0 in the next room he'll be on BG1.
0x20 Locked door specifically for BG0.
0x22
0x24 Locked door for either BG0 or BG1
0x26
0x30 Large exploded pathway resulting from a switch being pulled (unusual to have as a door as it's huge)
0x32 Sword activated door. Ex. Agahnim's room with the curtain door you have to slash.
0x46 warp door?

Navigate

Table of Contents
Sprites • Dungeons • Overworld • Underworld • SRAM Map • RAM Map • ROM Map • Music • Monologue • Credits • Dumps • Miscellaneous • To-Do/Suggestions
Retrieved from "http://alttp.run/hacking/index.php?title=Underworld:Important_Hex_Addresses/Object_Data&oldid=27462"