Super Mario
World had a lot of unused content, and some of it is still hidden
dormant in the game's ROM. A lot of the old code just gets skipped right over
and can never be executed. However, some of it can still be
triggered under the right circumstances,
usually with the help of some bugs or glitches. In this video, we'll take a look at a couple of concepts
that ended up being scrapped, but an empty shell of their remains
can be found in the game's code. <font color="#00FFFF">♪ [intro jingle] ♪ </font><font color="#FFFFFF"></font> Retro Game Mechanics Explained is
brought to you by its YouTube members, Patreon supporters,
and viewers like you. Thank you! Let's start with the fun mechanic of bringing a carriable item across the end level goal tape. When you do this,
the item turns into a powerup for Mario to collect--a
nice little bonus. The exact item it turns into depends on Mario's
current power status itself. If you're small or big Mario, the item will turn
into a Super Mushroom. If you're Caped Mario, the item will be a cape feather. And if you're Fire Mario,
the item will be a fire flower. But there's also two special cases. The first is that
if you already have the power up that you would get in
your reserve box, you'll get a 1up instead. So big Mario with a mushroom, cape Mario with a feather, fire Mario with a flower. The second special case
is if that item you're carrying
is a key or baby Yoshi. These two
items will always give you a 1up no matter what. We can make a chart that shows
what powerup item you'd get, depending on Mario's
powerup status along the top and the item
being carried along the left. A key or baby Yoshi gives a 1up no matter what,
and any other item would give a mushroom, mushroom, feather, flower. Just keep in mind that if the item received matches
what's already in the item box, then the item upgrades into a 1up. To any casual player, this is the extent of the chart. However, in the game's code,
this chart is over three times as big, with three extra
Mario statuses and two additional checks
for the item being carried. Let's go through these one by one. The carried item check is really simple. First, the key and baby Yoshi
items are checked for individually. In the final game,
they both give a 1up, but since they're checked separately, technically they
could give different items. Secondly, the springboard and P-switch are also checked
for as a group. Again, in the final game,
these are treated the same as the remaining
carriable items such as Koopa shells, throw blocks, Bob-ombs etc. so they still give the mushroom, mushroom, feather flower. Now for the additional Mario
statuses. The fifth status is
if Mario currently has star power
when hitting the goal tape. Technically, this check is
still in the game fully functional. It's just that before the check
for star power happens, the moment Mario hits the goal tape, his invincibility is removed, so he never actually has star power the moment it’s checked for here. If this were to succeed though, Mario would get a super star item. This gives Mario invincibility for the remaining of the end level cutscene, which doesn't seem too useful. I'll come back to this. Unless the item where a key or baby
Yoshi, of course, in which you would get
a 1up mushroom, but this 1up mushroom
would give you two lives instead of one. The sixth status is if Mario is currently riding Yoshi. This will always give you a standard
1up mushroom no matter what. This check is also still in the game,
fully functional. It's just that normally
you can't pick up an item while riding Yoshi. This doesn't check
if Yoshi is holding an item in his mouth,
just if Mario is holding one. However,
with the correct positioning, you can actually grab an item
and mount Yoshi on the same frame, which will allow Mario
to carry the item while on Yoshi’s back. And sure enough,
if you hit the goal tape while doing this,
you'll get a 1up no matter what. The seventh status is entirely unused and isn't referenced anywhere
in the final game's code. The entries in this table
suggest that these would have all also given 1ups. However, they would give a different number of lives. A standard carriable item would have been a normal 1up a springboard or P-switch
would give two lives. A key would give three lives. And a baby Yoshi would... well, we'll come back to that later. Okay, back to the super star. In addition to giving Mario invincibility for the 10 seconds or so during the cutscene, transforming the carriable item into a star triggers a sort of star power counter. There's a single 8-bit byte that holds this counter, and by doing
this it goes from 0 to 1. Every time a level or sublevel is loaded,
this counter is shifted left once. This makes that one bit that got set from the star moved to the left one position in the byte. Once this bit makes its way
to the most significant bit on the left, after entering seven levels or rooms, Mario will instantly start that room with invincibility. Then the entire counter is cleared so you can't queue up
multiple star powers. I think the idea behind this mechanic
was that you could get the star power from the star item for the duration of the cutscene, but it may have stuck around
on the world map. Sort of like
how you can give yourself star power in Super Mario Bros. 3. Then you would enter the next level
with invincibility right away. I'm not
exactly sure why there's the delay of seven level entries
before it triggers, though. By the way, you can totally still get this to happen
in the final release of the game. By utilizing a glitch called powerup incrementation (I'll leave a link to a really old
video of mine that explains it), you can get Mario's powerup status
to be out of bounds values that are not small, big, cape, or fire. Looking at the chart we made, if small Mario is 0, big Mario is 1, cape Mario is 2, and fire Mario is 3, if somehow Mario were to have powerup
status 4--whatever glitch status
that may be--the game would use the star power
entry in the table even when Mario
doesn't have star power. Now, due to other side effects
of being a glitched powerup status, the super star
will make Mario cape Mario, but it still triggers
the star power counter. So if you enter seven more levels, he'll start with invincibility. Let's look at this chart again. This chart exists in the game's code, and each entry is a single byte. Normally, the byte corresponds
to the exact sprite number that will be spawned from
the carriable item at the goal tape. Mushrooms have ID $74. Feathers are $77, flowers are $75, and stars are $76. 1up mushrooms have ID $78,
but for all of these 1up spots in the table,
a different value is used. In fact,
there are two different values: $E0 and $F0. Now in the final game,
these two values end up doing the exact same thing. It's a case of “if the value is $E0,
use this sprite. Else if the value
is $F0, use the same thing.” They are both explicitly checked for individually, but they perform identically, that being a 1up being spawned. However, the values aren't exactly just $E0, and $F0. The top half of the byte is what is checked for--the $E and $F. The bottom half of the byte defines how many lives
this 1up actually gives you. This is how the star power with key and baby
Yoshi are able to give two lives. These two entries in the table are both $F1. The being on Yoshi column is full of the value $E0. So zero means give one life, one means give two lives. The key row is full of the value $F0, while the baby
Yoshi row is full of the value $E0. This is why the key and baby
Yoshi were checked for individually. Had the $E and $F values done
something differently, these two items would have
produced different results. Now what are the values in this final unused column? These are $F0, $F1, $F2 and $E4
respectively for the four rows. The first three values
result in a 1up mushroom giving one, two, and three lives. Does the baby
Yoshi unused value produce a 1up mushroom that gives five lives? Nope! It gives you five coins instead! As a segue into the second unused mechanic, let's look at a fun glitch
that's super easy to do. Everyone knows that
if you stomp on enemies consecutively, you get more
and more points with each bounce, and eventually after 8000 points, you get 1ups. However, there's a particular enemy
in this game that doesn't abide
by this limitation. That being the wiggler. When stomping on a wiggler,
you can get 8000 points, 1up, 2up, 3up and more. After this,
you'll start hitting glitched icons since the game only intended the 3up
to be the highest bonus to give it
any time: collecting a 3up moon. After the 3up is the 5up,
but after that you'll start getting coins
and points. Lots of points. What in the world is going on here? The little icons that appear
when collecting points or lives are handled
by the same system in the game. They're commonly known
just as score sprites, but they handle points, lives,
as well as coins, which went unused in the final game. There are 21 different score sprites in the game, with IDs #1 through #21. ID #0 isn't used here, since it corresponds to the absence of a sprite. IDs #1 through #12 are the score sprites
that actually correspond to points. They start at 10 and go to 20, 40, 80, 100, 200, 400, 800, 1000, 2000, 4000, and finally 8000. Only the score sprites at 100 onward are commonly used, though 10 is used for collecting coins out of blocks. The score sprites with IDs #13 through #16 correspond to lives. They go 1up, 2up, 3up, then skip straight to 5up. The 1up sprite is red, 2up is yellow, and 3up is blue,
but the 5up is unused. Because of this,
it has a glitched sprite, which I'll touch on later. Finally,
the score sprites with IDs #17 through #21 correspond to coins. These would have given 5, 10, 15, 20, and 25 coins each. These also have glitched sprites,
but that's because their original graphics ended up getting overwritten during development. There is a counter in the game
that keeps track of how many enemies
have been consecutively bounced on. This counter has no limit
and will eventually wrap around if you manage to hit 256 enemies in a row. Almost all enemies use a common subroutine
when they are hit. This routine increments
this counter, plays the proper bounce sound effect, and spawns in the proper score sprite depending on how big the value of this counter is. For example, on the first hit, the counter is increased from 0 to 1
and score sprite #6 is displayed,
corresponding to 200 points. When the counter reaches 8, score
sprite #13 is displayed: the 1up. This routine knows to stop here even if the counter goes above 8. It won't try to display any score sprite with ID higher than #13. However, there are two enemies
in the game that don't use this common routine. The first of which is Rex, which just uses
a copy-pasted version of the routine instead of calling the routine
itself. The only flaw of this implementation
is that when you get a 1up from bouncing off of a Rex, only the 1up sound plays instead of being accompanied
by the bounce sound. The second of which is wiggler,
which completely fails to cap the score sprite at ID #13. This means that you can go past the 1up, continue
to get 2up, 3up, 5up, and eventually
run into the unused coin sprites. And even further after the five coin score
sprites, the ID is still uncapped,
so the game will continue to try to display score
sprites with IDs higher than #21, which results in glitched coin and score amounts being given. Let's look at these score sprites in more detail. There are seven tables in the game's ROM that correspond to the score
sprites. The first two of which define the two 8x8 tiles that appear on screen
for this sprite. There are 22 entries in the tables, one for each score
sprite ID, as well as an entry for #0 which goes unused. For example,
the first real entries for score sprite #1 are tiles $83 and $44. That would be this blank tile and this ten tile,
which would display 10 points. These go in order for all of the score
sprites, 1up sprites, and eventually the coin sprites
which show up glitched, since their graphics
don't exist anymore. However, if we go back in time,
we can see that in a previous iteration
of this graphics file, the coin sprites did indeed exist at exactly these locations. When the score sprite ID is #17 or higher, a coin sprite, an additional 8x8 tile is shown, which was supposed to be
this little coin. The next two tables define exactly how many points each score
sprite awards. There are 17 entries in these tables--12 for the 12 actual score sprites, four for the 1up sprites,
and an empty slot for #0 again. The coin sprites just don't
have entries in these tables since they supposedly don't award
points. I'm sure this
won't come up again later. The 1up sprites also don't award points,
but they do have entries in these tables
that are just zeros for some reason. The score sprites all define their amount of points
divided by ten. So for example, the 10 point icon only gives 1 point. This is just how the score is stored
internally. The trailing zero in the status bar is purely graphical. The last three tables
are pretty small and are only used by subsets of the score sprites. One of them just lists how many lives each of the four 1up
sprites give: 1, 2, 3, 5. The next table just lists
how many coins each of the five coin sprites give: 5, 10, 15, 20, 25. I'm sure these two tables
could have been combined with the scoring table somehow, since the 1up and coin sprites don't use the score at all, but that's
just how it was coded here. The last table is interesting
and was only meant to be used by two sprites: the 2up and the 3up. By default, all of the score sprites use a graphical attribute
value of $08. This makes the object tiles use the red palette by default. This small table has two bytes, $04 and $06. If the ID of the score sprite is #14 or greater, the value in this table overrides
the default $08 value. This is what makes the 2up yellow and the 3up blue. So now for the fun part where I explain
why everything is broken. Now I call it broken, but really it's just half implemented
and was never meant to be fully seen in the end. The only way to see
these out of bounds score sprites is with this wiggler
bouncing trick, managing to get a ton of enemies
to follow you to the goal tape when you hit it
at the end of the level, or using glitched powerup states to spawn in that 1up with a glitched
value at the goal tape. The first thing that's wrong is the missing graphics
for the coin score sprites. These eventually got overwritten, so this is what they look like
in the final game. Secondly,
the graphical attribute value applies
to more than just the 2up and 3up. Since the game only checks
if the ID is #14 or greater. This means even score
sprites with IDs #16 and higher will get the default $08 attribute value overwritten as well. This table only defines
bytes for the 2up and 3up, so all the other score
sprites afterwards index this table out of bounds and start reading garbage data. In addition to palette data, the graphical attribute byte is also responsible
for layer priority, horizontal and vertical flipping,
as well as determining which graphical
page the tile comes from. This really mangles the graphics,
and even the 5up doesn't show up correctly because of this. Thirdly, the coin sprites are specifically coded in to also give points. This is due to a branch instruction that never got updated
properly after the coin sprites were officially deprecated. However, this means
that the point value tables do end up getting
indexed out of bounds after all, and that activating a coin
sprite will also award a glitched number of points as well. For example,
the five coin sprite will also give 7680 points. The ten coin
sprite gives 2560 points. The 15 and 20 coin sprites give no points,
while the 25 coin sprite gives a whopping 450,560
points. And finally,
the biggest thing of all, there is no cap on
the score sprite ID at all. Any score sprite with an ID greater than #21 is treated like a coin sprite,
so it will award a glitched number of coins
and a glitched number of points. All of the tables we've looked at, aside from the lives
given from the 1up sprites, get indexed out of bounds so the sprites will look glitched while giving wildly
different amounts of coins and points with each wiggler hit. It is not difficult at all to keep this up
and max out your lives and score in just one visit to Forest of Illusion 1 using this glitch. In fact,
you only need to stomp on 48 Wigglers in a row to max out the score counter in the status bar. Thanks again for watching! As usual,
if you would like to support the channel, you can become a channel
Member or Patreon supporter. As a supporter, you can get extra perks in addition to having your name show up here, such as early access to videos and behind the scenes content. I've recently started
sharing my notes and some media resources,
such as uncut versions of my voiceovers. Even if you don't support monetarily, I still appreciate every view
and share I get. So thank you for your contributions!
