Sprite Properties

From TLoZ: ALTTP Hacking Resources
Jump to: navigation, search
This is a subpage of Sprites

These are a bunch of tables, indexed by sprite ID, which define some stats and properties of sprites.


  • Loads to $0E40
  • Byte formatted thus:
    • Bit 7: If set, enemy is harmless. Otherwise you take damage from contact.
    • Bit 6: No idea but the master sword ceremony sprites seem to use them....?
    • Bit 5: Causes enemies to go towards the walls? strange...
    • Bits 0-4: If zero, the sprite is invisible. Otherwise, visible.(actually, it seems like this is the number of OAM sprite slots allocated to this sprite object)


  • Loads to $0E50
  • Hit points of the sprite


  • Loads to $0CD2
  • Lower nybble is the damage type of the sprite
  • Upper nybble is ??


  • Loads to $0E60
  • Byte formatted thus: abcdeeef
    • a - If set, don't draw extra death animation sprites over the sprite as it is expiring.
    • b - if set, sprite is impervious to all attacks (also collisions?)
    • c - If set, adjust coordinates of sprites spawned off of this one, such as water splashes. In general this would roughly approximate the concept of 'width' of the sprite, and for this reason usually absorbable items like arrows, rupees, and heart refills utilize this.
    • d - If set, draw a shadow for the sprite when doing OAM handling
    • e - (Note: 3-bit) Palette into that actually is not used by this variable, but ends up getting copied to the array $0F50 (bitwise and with 0x0F).
    • f - unused?


  • Loads to $0F60
  • Byte formatted thus: isphhhhh
    • i - Ignore collision settings and always check tile interaction on the same layer that the sprite is on.
    • s - 'Statis'. If set, indicates that the sprite should not be considered as "alive" in routines that try to check that property. Functionally, the sprites might not actually be considered to be in statis though. Example: Bubbles (aka Fire Faeries) are not considered alive for the purposes of puzzles, because it's not expected that you always have the resources to kill them. Thus, they always have this bit set.
    • p - 'Persist' If set, keeps the sprite from being deactivated from being too far offscreen from the camera. The sprite will continue to move and interact with the game map and other sprites that are also active.
    • h - 5-bit value selecting the sprite's hit box dimensions and perhaps other related parameters.


  • Loads to $0B6B
  • Byte formatted thus: ttttacbp
    • t - 'Tile Interaction Hit Box'. Selects from one of several hit box limits for use when detecting the tile types that the sprite is interacting with.
    • a - Deflects arrows when they are shot at this sprite.
    • c -
    • b - "Dies like a boss'. Meaning it has that rather explosive death animation and makes a different noise.
    • p - Falls in holes


  • Loads to $0BE0
  • Byte formatted thus: iwbspppp
    • i - If set, disable certain types of tile interactions for the sprite, such as falling into holes, moving floors, and conveyor belts, among others.
    • w - Seems like it has something to do with sprites that are found in water, whether that's deep water or shallow water. Either way, still needs to be reverse engineered a bit more.
    • b - If set, the sprite can be blocked by a shield, provided the player has any level shield at all. The sprite will die if this is set and a collision with the player occurs while they have a shield, regardless of whether it 'hits' the shield. However, it must be traveling towards the face of the shield to be blocked. Otherwise, the player will be harmed.
    • s - If set, play the 'enemy taking damage' sound effect. Otherwise, play the basic 'sprite getting hit' sound effect (which will play for some enemies in spite of the fact that they are still taking damage.)
    • p - Prize pack to grant


  • Loads to $0CAA
  • Byte formatted thus: abcdefgh
    • a - If set... creates some condition where it may or may not die
    • b - Same as bit 'a' in some contexts (Zora in particular)
    • c - While this is set and unset in a lot of places for various sprites, its status doesn't appear to ever be queried. Based on the pattern of its usage, however, the best deduction I can make is that this was a flag intended to signal that a sprite is an interactive object that Link can push against, pull on, or otherwise exerts a physical presence. In general, it might have indicated some kind of A button (action button) affinity for the sprite, but I think this is merely informative rather than something relevant to gameplay.
    • d - If hit from front, deflect Ice Rod, Somarian missile, boomerang, hookshot, and sword beam, and arrows stick in it harmlessly. If bit 1 is also set, frontal arrows will instead disappear harmlessly. No monsters have bit 4 set in the ROM data, but it was functional and interesting enough to include.
    • e - If set, makes the sprite collide with less tiles than usual
    • f - If set, makes sprite impervious to sword and hammer type attacks
    • g - ??Seems to make sprite impervious to arrows, but may have other additional meanings.
    • h - disabled???


Table of Contents
SpritesDungeonsOverworldUnderworldSRAM MapRAM MapROM MapMusicMonologueCreditsDumpsMiscellaneousTo-Do/Suggestions