A crude attempt to reverse engineer a Super Mario World glitch
By J.Raza On February 4th, 2011Every now and then I remember playing the games I used to play as a child. One of those games was Super Mario World for the SNES. The reason why I bring this up is because of this very cool trick you could pull off in the Forest of Illusion level. With it, a semi-skilled player could go from 0 to 99,999,990 points in a few minutes.
Here’s the video displaying you how to do it, it’s pretty neat:
Now as you watch it, you can see Mario jumping from Wiggler to wiggler, and while he does that he gets points and extra lives. Here’s the screen shots of his points:
And as continues to bounce, the lives he gets:
However on the 7th wiggler jump he gets this symbol:
And then this one:
And so on and so on:
When I was 9 years old and saw those symbols for the first time, I had no idea what they were. The manual where I read this secret trick from said they were “secret super symbols that show how awesome you are!” But after reviewing this video a few times, I think I have a different opinion on what it might be: an offset pointer in video memory going haywire.
To understand what I mean by that, let’s have a quick discussion. In classic consoles programming, for an image (normally known as sprite) to be drawn into the screen, it’s done in the following sequence:
- First you must load the sprite into memory. Sprites are usually stored in memory sequentially, so images are grouped together (for caching purposes). This also has the benefit of making animation algorithms easier to implement. Here’s how sprite memory for the NES Zelda looks like:
This picture is taken from http://randomhoohaas.flyingomelette.com/RandomHooHaas-ripsprites.htm - You then use an offset pointer to inform the sprite rendering engine what part of memory to draw onto the video memory. This offset is usually in bytes. If you translate bytes to picture offsets, you are then able to ‘crop’ pictures and render individual sprites onto the screen. Assume I did that with the previous picture, and made an algorithm that given an (x,y) coordinate would give me the cropped out sprite. So for (4,3) I’d get the image below:
- This cropped image is then copied into the video memory, which it in itself is then read by the output signal to a PAL/NTSC scan line renderer. The result is an image drawn onto the TV screen.
Given that condition, here’s one of the most basic animation algorithms for sprite based rendering. You’d load a sprite such as this:
Into memory and you’d use the sprite render pointer offset to interpolate between the frames. So you’d start with coordinates (0,0), then after a few fractions of a second you’d switch to (1,0), then (2,0) and so on. Via this method you’d get an animation such as:
Given that technical description and the above Super Mario World glitch, here’s my assumption of what went wrong:
- The game had a counter (let’s name it the jump_counter) that started at zero. This counter tracked how many times the player jumped on a “bouncy” object (such as the wiggler), without touching the ground.
- As the player jumped on “bouncy“ objects, the game would use the jump_counter to track:
- The bonus the player would win: points and/or extra lives
- The associated image for such bonus.
So say the player jumped on a wiggler. The jump_counter would increase to 1 and render 1000 points. If the player jumped on another wiggler, the jump_counter would go to 2, and render 2000. As the player continued to “bounce” around, this process would continue.
So my assumption is that the algorithm was basically:
if( player_jumped_on_bouncy_object() )
{
Jump_counter++ ;
Points_variable += power_of_two( jump_counter ) * 1000;
player_lives += ( jump_counter > 4 ) ? jump_counter : 0 ;
ImageHandle Image_to_render = memory_offset_via_jump_counter(jump_counter);
Render_image( get_player_bounced_pos(), image_to_render ) ;
}
Now let’s explain the above pseudo-code:
- Perform this algorithm only if the player bounced on something.
- We increase the jump_counter, which is the base counter for the entire algorithm.
- We increase the number of points, based on 2 ^( jump counter ) * 1000.
- If the player “bounced” on more than 4 objects in a row, he’d get an extra life per bounce after that.
- We retrieve an imageHandle that is relative to the jump_counter variable. So if jump_counter is 1, the ImageHandle returned the 1000 point image. If it’s 2, the 2000, and so on.
- We then render the image we just retrieved at the location where Mario bounced.
Simple, isn’t it? However there’s a bug in the above pseudo-code. We can only retrieve valid image handles when the jump_counter’s range is from [1,7]. What if we make a request when jump counters is equal to 8 and above?
And that’s the catch! We get an invalid pointer offset to somewhere else in memory! Since that memory area is used for what’s to be displayed on the screen, we get bits and pieces from other sprites.
Obviously this is all an assumption of what went wrong. I could be incredibly incorrect in my analysis, but at least it’s worth a shot. What are your thoughts on this one?
