Supper Mario Broth: The Lost Levels, Issue 8, Week 43/2018 (Patreon)

Welcome, Supper Players, Broth Siblings and Supperstars, to the eighth issue of the Supper Mario Broth: The Lost Levels feature! Thank you so much for your continued support! This should mark the beginning of the Lost Levels articles getting back on schedule, but there is still the matter of the oustanding podcast for Broth Siblings tier subscribers. If it is not published until October 30th, I will issue a blanket refund to everyone whose subscription is 6 dollars or more, as that would constitute delivering no value to those subscribers this month and would be entirely unacceptable. You may still request a refund simply for the content being late even if I deliver it; as I discussed previously, I will issue it without question. Before I start, let me briefly restate some things of note about the article series. For more detailed explanations, please refer to Issue 1.

• All images without an attribution have been recorded/created by me. If you wish to know what emulators/programs I used, please leave a comment. I will reply promptly.
• All comments and criticism are greatly appreciated, and all suggestions are evaluated and incorporated into future issues. You can shape the form and content of the articles with your feedback, so don't hesitate to tell me anything!

Now, let us jump up in the air; jump up and not be scared of a world of obscure Mario content.
This is Supper Mario Broth: The Lost Levels.  

Frozen Map Screens in Super Mario Bros. 3

The first thing you see upon starting up Super Mario Bros. 3 is the map screen of the first world, Grass Land. It contains animated tiles - pairs of hills with eyes that move as though dancing to the music.

Note that the animation of the background tiles consists of four frames. As a power of 2, this is a very typical number of animation frames for older video games. This number of frames is also used during gameplay by Brick Blocks, Question Blocks, P-Switches and other background tiles, and the tradition of four-frame background animation in Mario games goes back to Super Mario Bros., which had four-frame palette shifts on coins and Question Blocks.

The palm trees in the World 2 map screen also display a four-frame animation. Also note that the same applies to the one-tile segment of water near Level 2. (Note: by "tile" in this context, I mean a 16x16 pixel tile, as the map screen is clearly divided into these. This is different from a tile as defined by NES hardware, which is an 8x8 pixel square. The Super Mario Bros. games on the NES have levels that are made up of objects on a 16x16 grid, so a "level design tile" in these games is 16x16, but nothing would have technically prevented them from putting them on a more fine 8x8 grid instead. You can even see this in design documents: the larger-scope full level designs use graph paper with each cell representing a 16x16 square, but the detailed documents use a hardware-based 8x8 grid.)

After seeing two worlds with four-frame animations used for background elements, the expectation solidifies that this will be the case for all map screens. However, this is not what ends up being the case.

The World 3 map, which consists largely of water, uses only two frames for the background animation. Note the dancing hills only swaying to one side as opposed to both sides in the first map. Now, while there is no definitive statement on this from Nintendo, I personally believe that this is a result of a glitch or oversight and not intended behavior. I will go into detail on my reasoning after we look at the rest of the world maps.

The World 4 map has the widest variety of animated elements yet, containing water, palm trees and Fire Flowers, with roughtly 75% of the screen being an animated tile, yet it still has four frames for all of them.

The World 5 map has no background animation whatsoever. Neither the hills nor the water move at all.

The same goes for the second part of the World 5 map. Another thing of note about this particular screen is that the small image of the first part of the map in the upper left corner does not match up with the actual map that you play through. Note that there is a path leading north from the tower that is absent on the playable map screen. This was not fixed in Super Mario All-Stars, but was in fact rectified in the Super Mario Advance 4 version (which, for an unknown reason, also included the Start panel to be visible from the sky, raising the question of whether the Start panel is merely a visual indicator on the map or an actual object in the game's world).

The World 6 map is also animated with four frames, but its animation is much faster than previous maps. This was likely done to make the ice crystals' shine animation more realistic, but as a side effect, the water and the dancing hills move much faster, as well.

The World 7 map also has four frames, but the Piranha Plants' animation may be slightly misleading; it contains only three frames, with two sequential frames being identical. The fact that it is still four frames overall can still be seen by looking at the water.

The first three parts of the World 8 map all have four frames of animation. The darkness in the third map screen is displayed as an overlay layer in the SNES and GBA versions, but the NES version uses a different method to create the darkness where the tiles that are not displayed are also not rendered. If you ever wondered, the skulls fill the entire area, which can be seen by hacking the game for the darkness effect to be removed:

The final map screen of World 8 contains no animation because it does not feature any tiles that should have been animated in the first place:

The mushrooms in this map screen are unique, and it is quite curious that they end up being used in the courtyard of Bowser's castle instead of any other map screen. 

Finally, the Warp Zone map screen also has four frames of animation.

Now, let me try to argue that the lower frame count in World 3 and the lack of animation in World 5 are not intentional:

• They were fixed in the remakes. Both the SNES and GBA versions feature four-frame animation for all map screens.
• It is highly unlikely that water would be chosen to not be animated when a) animated water already exists in the game, and b) all water uses the exact same tiles, but with different palettes. While Mario games with water that is not animated exist - such as Super Mario Bros. - to copy and paste the code for an already existing animation should be trivial.
• An argument could be made that the console can not support too much animation at once on the screen. This seems logical; as most people who have played NES games know, when too many moving objects are on the screen, they tend to blink, disappear and otherwise not be displayed correctly. However, this applies only to sprites. A sprite, from the point of view of NES hardware, is an 8x8 pixel image that can be drawn anywhere on the screen, including on coordinated not on the tile grid. (Thus, Small Mario from Super Mario Bros., who fits inside a 16x16 square, is actually made out of four sprites as rendered by the hardware.) Animated tiles are simply background tiles that are drawn differently depending on frame and are handled by the regular background code; i.e. the console experiences absolutely no additional strain from having animated background tiles compared to static background tiles. If you find this difficult to believe, consider how often in Super Mario Bros. 3 the screen is full of Brick Blocks, which are animated. There is never any slowdown or graphical glitches involving this. Thus, I believe there would be no reason to limit background animation deliberately as it has no effect on the performance of the game.

If you believe that this may have been a purposeful decision, I would love hearing your thoughts; please leave a comment below.

The Mystery of Kug

Super Mario Sunshine does not contain Goombas - except for this one:

This is Kug. (The name comes from the name of its model in the code.) Kug is a 2D sprite of a Goomba, or at least something highly resembling a Goomba, found in an inaccessible spot under the ground in Pinna Park, below the spinning shells. Uncommon for 2D sprites used in 3D games, Kug has a backside different from the front side:

(Although, looking closely, the back side appears to be just the front side with the face missing and flipped horizontally, and not a newly-drawn sprite.) 

In-game, there is little we can do with Kug. Trying to touch it after modifying the code to let Mario walk below the ground reveals that it has the same interaction with Mario as touching electric Goop, which is not consistent with it depicting a Goomba. Other than damaging Mario, nothing happens; Kug can not be defeated.

Looking at it in wireframe view reveals that it is rather complex for a 2D object:

It is tessellated with 72 triangles in a manner that seems designed to let it ripple, not unlike the paintings in Super Mario 64. And indeed, hackers have found animations in the code that do just that: cause Kug to ripple.

(Source)

There are five such animations in the code, all causing the model to ripple in some manner, and each of them makes seemingly no logical sense with what the drawing on the model is depicting. Unless Kug is supposed to be a drawing of a Goomba in-universe, a real Goomba would not behave like this. Unfortunately, the animations' names are very unhelpful, being named  "kug_dbk", "kug_dmg", "kug_jbd", "kug_jfd" and "default" respectively. While "dmg" likely stands for "damage", the rest give no indication of what the enemy was supposed to have been doing to cause them.

Note that I said "enemy"; there is clear indication in the code that Kug is an enemy, as the code refers to it as a "typical enemy" and a "test enemy" in a different location. 

But this is not the only time Kug has appeared in a game. Pikmin, released a year earlier, also contains Kug - or something very similar to Kug - as a 3D model. Inside the game's files, a model named "kuribo" can be found, Kuribo being the Japanese official transliteration of  クリボー, "Goomba". The model resembles Kug in the general shape of the head and facial features, although it lacks a body and feet, and does not have the same paint-like texture.

(Source for the model) 

Note that the black outline is a special effect built into the model, made to simulate cel shading. Here is a picture from another angle:

Note how the outlines around the fangs change in response to the shift in angle. This technique is used for cel-shaded objects in games that are not entirely cel-shaded; as those have the shading done by the engine and not part of the object itself. 

Another oddity about this model is that is has a face on the back (which looks different from the front face due to a lack of eyebrows and fangs and being drawn on a different elevation on the model, distorting the mouth; but it is in fact the same texture, only mirrored); this may be not intentional, as it could be merely an error in texture mapping, causing the texture to wrap around the back of the model; however, it may be interesting to imagine what the intent would have been if this was deliberate. A Goomba with two faces would certainly be a unique concept.

In the end, Kug remains a mystery. The most likely explanation for both appearances is that they were part of a "test enemy suite" used by different Nintendo projects during the development of early GameCube games; which likely included both 3D and 2D versions of Kug. It is also unclear what the name "Kug" means, although the first two letters may stand for "Kuribo" as shown in the Pikmin example. If Kug was truly used as a test object across different projects, it may have at some point been in Luigi's Mansion, or even games entirely unrelated to Mario. Perhaps in the future, more instances of Kug will be discovered.

Mario's Hex Colors Through the Years

Mario has had a remarkably consistent design ever since his overalls were officially declared blue and his shirt was declared red around the release of Super Mario Bros. 3; while his proportions have been adjusted, the clothes have remained the same, as did the unique color scheme of his hair: brown head hair with a black mustache. Especially since the GameCube era, Mario's design has become a paragon of stability; whatever changes were made to it since then have been minimal enough that only detailed analyses could pinpoint the exact differences.

Still, even with a team of designers overseeing the consistency of Mario's model, it is impossible for him to always look the same simply due to games being programmed for different hardware. Some consoles require the model to be low-polygon, some cannot handle certain types of lighting, so they need to fake lighting by including it inside the textures, and so on. This results in the actual colors used for the models to be ever so slightly different in many games containing Mario. 

This segment is a test of a larger concept. Using the tools available to me and the models ripped by others, I have access to textures from over 50 games that contain a 3D Mario model. To analyze them all here would be unfeasible, which is why I will limit this segment only to the mainline 3D Mario platformers; however, if you are interested in more color comparisons, leave a comment on this article (or contact me in any other way, such as over Twitter, Tumblr or Patreon messaging), and if there is sufficient interest, I will do a large-scale comparison using all textures available to me in the future in a separate article.

A note on why I am not including 2D Mario sprites: the colors in 2D games are usually determined by code, rather than stored in the images themselves. As you will see in the Wario segment further in this article, usually the actual data stored in the code does not depict anything close to the correct color, and is colored in with separate palette code. Now, to determine the correct hex color it is necessary to either a) find the code and analyze it, or b) take the color from an emulator. However, if you have ever read a forum for retro gaming enthusiasts, there are not many topics more controversial than whether emulators output the correct colors. Arguments range from "the colors need to be adjusted for CRT monitors" to "the colors look clearly different on an emulator and on hardware; emulators thus cannot be trusted". I am not an expert on these matters, nor do I have enough technical knowledge to be able to find the code myself, thus I will restrict myself only to textures.

Textures, unlike sprites, are saved as image files with the pixels having color values in the exact same way they do on image files on any standard computer. Depending on the type of texture, there may be alpha transparency, but the color information is inside the file rather than outside it (for textures intended to determine color, at least; there are plenty of different types of textures with color information that is not used directly, or monochromatic textures). Thus, I can take the textures and use a color dropper tool in an image editing program to determine the hex codes of the colors used.

I will be looking at three colors for each game: the colors of Mario's overalls, his shirt/hat (as those are assumed to be the same color), and his hair. Since in many cases, there are no areas with a single flat color, I will provide the color of the largest single-colored area within the texture, as well as add commentary detailing the process. 

Let us start with Super Mario 64. Since textures are used very sparingly in that game, we do not actually have a texture for Mario's overalls, shirt or hat, as these are colored in by the engine. However, there are textures for his buttons and his hat emblem, which are surrounded by the colors of his overalls and hat, respectively. Since there is no visible color change surrounding those areas in-game, we can assume that the colors on the textures match the engine-colored areas perfectly.

The hair's color was not easy to determine, but I have taken the color of the largest area within it. It could be argued that the true color is the lighter color on the top, and the bottom area is shaded; for this, I have provided a copy of the hair so you may judge the validity of the color yourself.

The hat and overalls are "pure red" and "pure blue", respectively; the maximum color values for their color in the RGB trio and a 0 value for all other colors. This changes with the next game, Super Mario Sunshine.

While both the hat and the overalls in that game have many shades of color on them, they have big enough areas of a flat color that these can be said with confidence to be the correct colors. The hair also has a large area of the same color; although that one only appears flat, but in reality has very tiny imperfections, likely due to compression. I have analyzed which color appears most often in the hair and provided that color; although note that the different colors are so similar that taking a simple "default color" of the hair would produce a result almost indistinguishable from this.

Super Mario Galaxy gives us little problems, as all parts of Mario's body have large areas of flat color. Note that all colors have been darkened from Super Mario Sunshine. Super Mario Galaxy 2 uses the exact same Mario model as the first game, so there are no changes in that one.

Super Mario 3D Land has the most subtle difference yet, making the hat imperceptibly lighter, as lightening the overalls and hair slightly. 

Super Mario 3D World, due to its more advanced lighting engine, has very little shading included in the textures, which is why I can say with confidence that these are definitely the correct colors for Mario's model in that game, as the textures are filled almost completely with a single flat color. While the hat and hair are largely similar to the Super Mario 3D Land colors, the overalls have been lightened significantly, and are lighter than the previous lightest color used in Super Mario 64. (Although note that while lighter, they are not "bluer", as the Super Mario 64 color was as blue as a monitor can possibly display.)

However, the price of progress is sometimes too high. Super Mario Odyssey decided to give Mario an extremely textured look, resulting in his clothes and hair having absolutely no points where they are drawn with a flat color. Therefore, I have at least attempted to determine a hex color by taking a homogeneous spot of the texture and running a default color algorithm on it. Of course, the colors gleaned this way are only a guideline.

If you would like to see more of these comparisons, please contact me or leave a comment as noted above.

The Big Mountain Scam

Video games employ visual tricks to make us believe there is more to a scene than what is really there; this has been the case since the beginning of the medium. Donkey Kong Country uses prerendered sprites that look like models, Super Mario 64 rotates flat trees towards the camera to make them appear 3D, and Super Mario Odyssey draws pictures on the sky.

Consider this screenshot of New Donk City:

There are certainly many buildings here. But which of these are actual 3D models, and which merely appear to be? Luckily, the game provides us two tools to discern between models and flat cutouts: the Snapshot Mode filters "Silhouette" and "Coin".

The "Silhouette" filter works in the following manner: the skybox, i.e. the large object surrounding the entire rendered area, is declared to be white. Then, every object within the skybox is colored a progressively darker version of some color (chosen by kingdom, Metro Kingdom's is grey) the closer they are to the camera, with the closest objects being almost black. This lets us see if some "objects" are not objects at all, but merely drawings on the skybox - if the place where they would be appears entirely white. And as we can see here, all the very distant buildings are completely absent from the image, being as white as the sky, meaning they are, in fact, the same object as the sky, i.e. they are drawn onto the skybox.

The "Coin" filter is also helpful, but for a different reason. It displays two things only: 3D objects without a transparency effect (some objects with a transparency effect are very faintly visible, while others are completely absent), and normal maps. A normal map is a special type of texture which can be applied both to 3D objects and sprites which determines how the object interacts with light, by specifying surface detail. For example, this is the normal map for Mario's cap emblem in Super Mario Odyssey:

(Source)

This is what you see if you look at Mario's cap through the "Coin" filter (though obviously in a different color). Now, this is useful for determining what objects are just drawn onto skyboxes for the reason that skyboxes in Super Mario Odyssey are static, and do not need normal maps. After all, a normal map determines how objects interact with a moving light source, but the skyboxes, being static, are not exposed to any moving light sources (in-universe, they themselves are supposed to be the light source, containing the Sun, Moon etc.) Thus, the same applies as with the "Silhouette" filter: if an object does not show up on the "Coin" filter (and it is not at least partially transparent, such as water, ice, fog, fire, glass etc.), then it is simply a drawing on the skybox.

Super Mario Odyssey does employ the strategy of adding normal maps to 2D images as long as they are not part of the skybox, though. The building here is blatantly a 2D cutout, as it a) appears pixelated when zoomed in on when other buildings around it do not, and b) has a dark outline which other buildings do not have. 

Still, it has a normal map, which results in it appearing (somewhat) 3D with the "Coin" filter. Especially from a larger distance, the effect is very convincing.

This brings us to the main point of this segment. The mountains in the Wooded Kingdom, despite looking very realistic, are not real, and are simply drawn onto the background.

The "Silhouette" filter shows nothing.

Neither does the "Coin" filter. I have moved the camera downward to show that the last line of trees within the dome is the furthest object the "Coin" filter will show.

Now, there is a justified counterargument here. What if the dome, which is between the playable area and the mountains, is somehow interfering with the filters? After all, if the filters treat it as a solid object for whatever reason, they would not render anything behind it, which includes the mountains. However, there is one area where we can see the mountains without the dome in the way - the bonus area reachable by planting a seed at the highest point in the level, near the spot Glydon can be found.

Let's take a look at these unobscured mountains.

The "Silhouette" and "Coin" filters show nothing. 

In fact, merely zooming in on the mountains reveals JPEG artifacts that clearly show that they are merely drawn onto the skybox.

Now, you may think, "this is all very obvious. You cannot expect skyboxes to be fully modeled. The Wet-Dry World city background in Super Mario 64 was just a drawing, and the methods haven't changed since then. Besides, who would render mountains if you could simply use an image?"

Well, as it turns out, fully-rendered mountains do exist in the game - in the Ruined Kingdom.

It is rather easy to miss these mountains, as they are to the right of the starting platform in the kingdom, a place where the camera deliberately never turns if it is left to self-adjust, and can only be seen my moving the camera manually. Not much can be seen of the mountains; both the bottom and the top are covered by fog and clouds. Let us take a look at them in the "Silhouette" filter.

Nothing... or is it? The mountains are actually there, they are simply so far away from the camera that the color they are rendered in is almost white. Still, adjusting the contrast reveals this:

The mountains were real all along. (Note: I did do the same with all previous pictures taken in the "Silhouette" filter; only this one actually had an image that could be seen this way, the background is entirely white in all previous images.)

The "Coin" filter corroborates this and shows that the mountains are actually 3D models, and not merely cutouts (this can be seen by zooming in and noting that no artifacts become visible).

In the end, I simply wanted to show the peculiar design decision to use 2D drawings of mountains for a location where the mountains are extremely prominent, while actually modelling mountains in 3D for a location where they are out of the way and barely visible. 

Late, Late for a Very Important Date

In Super Mario 64, MIPS the rabbit appears in the basement of Peach's Castle when the player collects 15 stars. Here is footage I took after collecting my 14th star on that save file that shows that the rabbit is not there yet:

Going back to Hazy Maze Cave and obtaining another Star results in the rabbit appearing:

However, there is one scenario where it is possible for MIPS to not appear when the player has collected 15 stars. There is a Toad next to the entrance to Hazy Maze Cave that gives Mario a Star when first spoken to. If Mario has 14 Stars prior to talking to the Toad, and gets his 15th Star this way, MIPS will not spawn in his usual spot, as shown in this footage:

The reason for this is that the check in the code that decided whether to spawn MIPS is run only when the castle area is entered: either by selecting a save file or by exiting another level. Until this is accomplished, MIPS will not appear. This means that even leaving the basement, or the inside of the castle (to go to the Castle Grounds) will not cause MIPS to spawn; only actually going inside a course (or a secret area) and then returning will cause him to appear.

While this seems to be a very minor quirk in the code, this is actually surprisingly relevant in certain types of speedruns. If the runner wants to get the star from Toad, the only optimal time to do to is when leaving the Hazy Maze Cave room, as doing it when entering the room or between Stars in Hazy Maze Cave does not take advantage of Mario's position relative to the level entrance that enables him to jump in quicker if not talking to the Toad first. However, it can happen in certain categories that the Star obtained from Toad would be the 15th Star if obtained after all the Hazy Maze Cave Stars. Thus, the runner must take precautions to not talk to Toad at what seems to be the optimal time, and instead remember to talk to him between Stars as doing it the wrong way would not cause MIPS to spawn.

The Wario Crew

One of the microgames in WarioWare: Touched is the Wario-Man microgame "Where's Wario?" Playing the game casually would likely only show the first level of the microgame, where a blue 3D ball must be rotated with the stylus to find artwork of Wario's head that is hidden somewhere on the surface of the ball. The second level is largely the same, with the main difference being that Wario's head is smaller and thus harder to find.

The third level, however, is completely unique. The ball is filled with images of arcade- and NES-era Mario characters, most of them wearing Wario's motorcycle helmet, and the object is to find Wario's pixel self, which is harder due to both the abundance of characters and due to the fact that Mario sprites wearing Wario clothes are there to throw the player off.

No sprite rip of this microgame exists to my knowledge, so I decided to make my own. Ripping graphics from a 3D object is harder than 2D sprites, which can, if no better method is available, be ripped by simply taking a lossless screenshot and cropping out the sprites (this was the prevalent method of very early sprite rips, before the advent of emulators with a variety of analytical tools). 

I have used the emulator to look at what graphics were loaded into memory during the microgame, and found the sprites as used by the engine:

Obviously, these would be recolored by some other code, but this is all I had to go off of. Therefore, I recolored the sprites myself, using screenshots from the game as reference. Note that Luigi and the Goomba have "garbage pixels" in their sprites, which are not a result of the rip, but can actually be seen in-game if you look closely at the rotating ball. I can only speculate, but I believe these are a result of improper image scaling (all sprites here use 2x2 squares for pixels, and it could be that Luigi and the Goomba were scaled from regular 1:1 ratio sprites with a program that leaves such artifacts - interestingly, MS Paint leaves exactly such artifacts, so it is not impossible that precisely it was used).

Here is my finished version of the correctly colored sprites. You may use them however you wish.

Gadd's Slip-Up

In Luigi's Mansion: Dark Moon, E. Gadd makes use of a device he invented to transport Luigi from and to his secure bunker via special cameras and screens. The device is called the "Pixelator" (or "Pixelshifter" in the European versions). 

There is a linguistic consistency between the name "Pixelator" and all other words connected to it, i.e. E.Gadd "pixelates" Luigi and Luigi "gets pixelated". 

However, inside the game's code and in the Japanese version of the game, the device is referred to as the "Pixelporter". Why this name had to be changed both in the North American and in the European versions is unknown, as it already presents a workable portmanteau of "pixel" and "teleporter". Nevertheless, it was changed, and no trace of it remains visible during normal gameplay - except one instance that was overlooked.

In Chapter C-2, "Underground Expedition", Luigi ventures to the ruins beneath the Old Clockworks, where the connection of the Dual Scream (the Nintendo DS-like device Luigi uses to communicate with E. Gadd) becomes unstable and E. Gadd's voice begins to break up, which the game represents by replacing letters in certain words with underscores.

At one point, E. Gadd says "I'll pix__port you back so we c_n regroup." This is the only reference in the dialogue to the original name of the Pixelator, and was likely left in because the translator was preoccupied with the special effect of the connection breaking up to notice the wrong name (although this is merely conjecture). Interestingly, this does not seem to be intentional, as the European version correctly uses its own translated word "pixelshift" in this instance.

In the end, what we can glean from this is that perhaps it is not the best idea to give new names to concepts that already have workable names, as incidents like these are bound to happen eventually.

Teasing Boos

In Mario Golf: Toadstool Tour, if the player waits a short amount of time when asked to hit the ball, pairs of Boos with banners will begin to fly across the screen. These banners include basic tips on how to hit the ball, what options exist for controls, and so on. However, if the player continues to make no input whatsoever for over 30 seconds, new banners will start being mixed in with the tips, containing messages from the Boos about how the player should hurry up, and generally complaining about the player. As the messages sometimes repeat before each one is shown, it may take upwards of 5 minutes to see them all; here are all 8 messages of this kind:

No Yoshis Allowed

As anyone who has played Super Mario World knows, Yoshi does not go inside castles and Ghost Houses. Before each one of these levels, a special intro screen is shown, where Mario simply walks up to the building's door and looks up while the door opens before walking in if he is alone. However, if Mario is riding Yoshi, he dismounts him instead, and walks inside the building without him. 

There are special unused versions of this screen in the code, likely meant to be used for levels that are not taking place inside buildings, which instead of an entrance, contain a "No Yoshi" sign:

Note that curiously, Mario's animation of looking upwards actually makes more sense with the "No Yoshi" sign than with the entrances; while it is not entirely implausible that someone is manning the door opening mechanism from inside and Mario looking up is supposed to represent him calling out for the door to be opened, the act of Mario looking up at the sign is so natural that it raises the question of whether this animation has been developed with this screen in mind, rather than the castle entrances.

(Although admittedly, what makes less sense is why Mario and Yoshi are supposed to respect the sign in the first place; Dinosaur Land seems to have no government and the vast majority of architecture in the game is built by Bowser and his troops. Still, despite this scene going unused in Super Mario World, Yoshi having a respect for signs that bar his way is a trait that was later used in Yoshi's Story, where the Pak E. Derm enemy's stop sign completely prevents Yoshi from continuing, even if Yoshi jumps to a height greater than the sign, as though a forcefield was attached to it.)

One thing that levels that disallow Yoshi from entering have in common that levels that allow Yoshi do not feature is doors. In addition to the entrance doors, there are small yellow doors the size of Super Mario or large red boss doors inside each of these levels. The tongue-in-cheek explanation that Yoshi "hates doors" fits not just this situation perfectly, but also the fact that Yoshi's own house has no doors.

Still, I decided to see one thing for myself. I decided to use codes to take Yoshi into a castle level, where he normally cannot go, and try to take him through a door. Here is what I recorded:

(Note that due to Yoshi not being intended to be displayed inside castle levels, his sprite map is shared with other objects, so that his head becomes a glitchy image of Lava Bubbles (formerly known as Podoboos) when he is close to them.)

The footage starts with me attempting to go through the door as Super Mario riding on Yoshi. This does not succeed; the door does not react as long as Super Mario is on Yoshi. I then use one of the Lava Bubbles to damage Mario and turn him into Small Mario. Small Mario can, in fact, go through the door while riding Yoshi - but then Yoshi simply disappears in the next room.

Here is my interpretation of this: I believe that there are two separate phenomena at work here. Super Mario riding Yoshi has a very odd hitbox:

Note that the Banzai Bill does not interact with the Mario part of the Yoshi-Mario playable character (who is treated by the game as one unit) at all; however, Super Mario still bumps into the ceiling with his head in my footage, showing that his hitbox is a smaller size for some purposes while being a larger size for others. 

Now look at this:

There is an unused object in the game's code that consists of the upper half of a door that allows only Small Mario to enter. From this we can conclude that it is the upper half of a door that determines whether Mario can come in, and that it does not open if Mario is above a certain size. If the half-sized door does not open if Mario's head is on the second tile from the floor - then it may be that the full-sized door does not open because Mario's head is on the third tile from the floor when he is riding Yoshi. (Assuming that the door cares about the same hitbox that is used for bumping into ceilings, rather than the one used for bumping into enemies.)

This may explain the first part of the footage, but what about the second part? Reducing Mario to Small Mario allows us to pass the door since Small Mario riding Yoshi is the same height (hitbox-wise) as Super Mario alone. But then, Yoshi disappears. I believe this is due to the game making a separate check to remove Yoshi in every room of the castle (or any level Yoshi is not allowed in). Now, you may think, why do that if Yoshi is already dismounted in the intro screen?

The thing about that is, Yoshi never really goes away. Dismounting Yoshi in a regular level abandons Yoshi in that spot; entering another area via a pipe etc. and then returning will reveal that Yoshi is gone, and he will be gone if the level is exited in any way. However, "abandoning" Yoshi in a "no Yoshi allowed" world still retains Yoshi on the map screen, and if the player chooses to go to a different level after dying or beating the level, Yoshi will still be there. This makes me believe that Yoshi is still stored actively when the player abandons him in that manner in a "no Yoshi allowed" level; but whenever a room inside that level is loaded, the game simply removes the Yoshi from Mario if one is present. Putting this code in every room instead of just the first room of these levels may be a kind of failsafe; in addition, some castles have midway points, allowing Mario to enter a different room first. Putting the code to remove Yoshi in all rooms may just be a copy-paste procedure since that would be easier than to individually mark all rooms Mario could enter the level in.

This is obviously all speculation, but I hope that I present arguments that make sense given the situation. It seems that Yoshi "hates doors" so much that even after jumping through all the hoops to make him enter a door, he simply disappears afterwards anyway.

This concludes this week's Supper Mario Broth: The Lost Levels. Thank you once again for your support. I must again point out that you are entitled to a refund. Please join me next week for Issue 9, featuring such topics as:

• Demystifying Merlee
• The Talking Statues of Nimbus Castle
• Interpretations and Misinterpretations of Ninjis

Thank you very much for reading.