On NES games such as The Legend of Zelda and Metroid, entities that get to close to the edge of the screen, whether that be the top, bottom, left, or right side wrap around to the other side of the screen. This only happens as a result of glitching, and was clearly not an intended feature of the games that are effected by it. What causes this? Is it a fault of the Object Attribute Memory (OAM).

Zelda screen wrap glitch: https://youtu.be/2gTvKmBQGyQ?t=34

Metroid screen wrap glitch: https://youtu.be/vXMhSsJ50MU?t=37

I do not own these videos.

  • A sprite that wraps (and thus simultaneously appears) over the left/right edge of the screen is a much different issue than one that is programmed to disappear from the left edge to reappear on the right edge. Which case are you asking about?
    – DrSheldon
    Nov 7, 2018 at 15:52
  • the former. sorry, do you want to edit it or should I?
    – Badasahog
    Nov 7, 2018 at 15:55
  • These two issues are caused by completely different things.
    – user
    Nov 7, 2018 at 15:58
  • yes, I am aware.
    – Badasahog
    Nov 7, 2018 at 15:58
  • wait, is this in responce to @DrSheldon, or in responce to zelda and metroid?
    – Badasahog
    Nov 7, 2018 at 15:59

1 Answer 1


After looking at the posted videos, I think that OAM layout may be the cause of the Zelda right-to-left glitch, but not the Metroid top-to-bottom glitch.

In Zelda if you frame step you can see at least one frame where the left half of Link is on the right hand side of the screen and his right half is on the left. The OAM accepts only 8 bits to specify sprite x position even though the screen is 256 pixels wide, and sprites are only 8px wide — Link himself is built out of at least two sprites. So what you're seeing is consistent with code that does something like:

set_link_sprite1(x, y)
set_link_sprite2(x+8, y)

Where x was in the range 248—255, meaning that x+8 overflows an 8-bit integer. The game logic isn't affected because Link's actual position is still safely within the 8-bit range, but setting the sprite location for his right half causes integer overflow.

In the Metroid example, Samus jumps off the top of the screen and reappears on the bottom — but not just graphically, play actually continues from there. So whatever overflow occurs affects game state. It's therefore unlikely to be a mere figment of output. I would imagine there is an internal variable that holds her position as an offset of the current screen position, and that internal variable underflows.

OAM y positions are also limited to 8 bits in size but the screen is only 240 pixels tall (224 'visible'; see comments), so portions of objects may appear to wrap if they are at least 32 pixels tall (which is two sprites, as they can be 16px tall) and drawn at a sufficiently low position with code like:

set_sprite1(x, y)
set_sprite2(x, y+16)

Or sufficiently close to the top of the screen with code more like:

set_sprite1(x, y)
set_sprite2(x, y-16)

Given that she's tall, part Samus reappearing on the top or bottom when she's close to the bottom or top would also be unsurprising.

  • you can see parts of Samus as she wraps through the screen in Metroid, sometimes.
    – Badasahog
    Nov 7, 2018 at 17:38
  • 1
    Nitpick: The screen height is 240 pixels tall, not 224 (although many televisions cut off part of the picture).
    – NobodyNada
    Nov 7, 2018 at 18:58
  • 2
    And it is still not the fault of the OAM, since it just shows sprites, at the commanded coordinates. If the program calculates X coordinates with no attention to the wraparounds, it is not the fault of the OAM. However, OAM has optional 16px wide sprites and in this mode it is possible that right portion of such sprite would be wrapped. It is just my conjecture and I'm not sure it is the case.
    – lvd
    Nov 9, 2018 at 16:35
  • 1
    Correct, NES sprites can optionally be 16 pixels tall, not 16 pixels wide. Regardless of whether 8x8 or 8x16 sprites are used, sprites do not ever wrap around in hardware (to my knowledge).
    – NobodyNada
    Nov 9, 2018 at 17:46
  • 1
    Ok, then I was wrong about the size of sprites. So therefore it is the "fault" of the software controlling OAM.
    – lvd
    Nov 9, 2018 at 18:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .