Here's a link to the video with the full playthrough of the game! ua-cam.com/video/1whju31WAPA/v-deo.html You can support the channel on Patreon here: patreon.rgmechex.com/
0:50 The moment I saw this, I realized all this could be prevented with "AND #7". And yet the programmers chose not to. They had some major cajones (or desperately needed to save the two bytes required to bounds check) to leave that out.
What font do you use for your videos? It seems like it was designed to look monospace, but with a couple of clever tricks to increase readability, like a ligature for a comma-space that is just one character wide. Did you make it yourself?
The fact that pipe warps have a check for what world you're in is interesting, that explains why in every single glitch level I've ever seen, there has NEVER been a pipe transition that successfully takes you to a different level.
In Kosmic's series of glitched worlds, the first time a pipe took him do a different level was in something like 1-111. There was probably a warp sprite that just by chance only occurred when it's world 1.
As a programmer myself, I am pulling my head in front of those who developed this format and the loading routine. All these edge cases create a lot of branches in the code, making the routine really complex. Crazy to think of these times where ROM was so expensive you had to play such tricks. I wished the video would have gotten more down to the reasons these levels crash.
Not just ROM. This predated the memory-mapper chips that defined what NES-era games looked like. Even if it was affordable, there wasn't a means of addressing more than 32 + 8 K of program/object data.
@@algotkristoffersson15 modern cpu performance is more or less defined by the ability to find work that can be done, to keep the instruction pipelines full. Long pipelines mean less work done at each stage, meaning breaking up the longest running instructions into smaller steps and so allowing the clock speed for all operations to be increased. Instructions start at the first pipeline step and are delivered to the next step on each cycle. But in order for this to execute instructions efficiently you need to find lots of work to do on each cycle, as the latency to execute each individual instruction is 20 cycles. This becomes harder at the point of a condition or branch, as it is unknown which set of instructions to start adding to the pipeline next. Modern cpu design uses a lot of prediction to allow the cpu to try and schedule work. This prediction takes advantage of various locality correlations in code - branches tend to be mostly taken or mostly untaken and the processor can track this. If the cpu guesses correctly, it has done a set of work ahead of time and can carry on. If incorrect, it has to remove the instructions from the pipeline (they are tagged and tracked) and return the processor to an earlier state to take the alternative path. This "pipeline flush" work is very expensive and results in no useful work done during this time. This is speculative execution, and in especially branch heavy code it struggles to get every decision right. The code mentioned in this video would not be written today, mostly for that reason.
And what made this even more hardcore is the fact that Shigeru Miyamote and his team had to design levels by hand on graph paper, then manually enter in the bit registers for every BG, BG theme, tile data, and object data for each level into their source-code editor while paying attention to the rules of the programming logic they had written to avoid lockups, crashes, and glitches, and then compile the game and run it to playtest it. At the time, there were nearly no game development tools available to allow on the fly level editing or playtesting without having to recompile the whole game.
No emulators either, including the fancy devices we have now that emulate a cartridge. Each test attempt had to be written to EPROM, which took a while! They must have been relieved when FDS came along and they could use disks to quickly load from for testing, even if the final game only used ROM. I know they even made a SNES floppy disk drive for development - not related to the CD-ROM drive that would later become the PlayStation; this was for internal use only. Some of the leaked Super Mario Kart code uses it to run a level editor. Even some N64 games used the 64DD as a debug tool long after it was cancelled.
This level encoding is a masterpiece of engineering, and is "living" proof that real art is born from limitations. 2k of ram, 32k of data... What the programmers and game designers were able to do within these constraints is staggering. Thank you for explaining this!
The most impressive part here is that SMB1 is a full game and not a minigame as many other games were around its time but also exists on a vanilla cartridge (i.e. no MMC, no extra RAM). Even as an arcade game (given that lives, score and hard mode are a thing), it still would be one of the more complex ones due to the variety of levels here.
@@MarioFanGamer659 you mean *most* games of its time. Lots of games (most?) were still either conversions of arcade games, or were original but mimicked arcade mechanics. And arcade games tended to be minigames.
@@kargaroc386the defenition of a minigame is “a smaller game included within another game” not “a game based around obtaining a high score” therefore it is completely impossible for an entire game to be a minigame.
As a kid, i always wanted to make my own Super Mario Bros. levels. It seemed so simple in my mind, and you almost nailed the concept i had with level storage back then (and 10 year old kid-me was frustrated at the lack of easy tools to do so). Watching this video makes so much sense to me why the reality is that was so much harder to achieve, and why there is a base level of understanding of the game's engine required to make a custom level. Really great video (and series) as always!
If you're wondering how you can bump blocks when everything is on a fixed grid, there is a trick to it. First you delete the tile from the tile map, replace it with a sprite with the same tile image and animate the bump. Then at the end of the animation, you remove the sprite and if the tile object is not destructible, put the original tile back into the tile map. The book "I Am Error" also covers the SMB1 level format (along with a lot of other NES stuff). Recommended.
This is why in Super Mario World, there can only be four spinning blocks at once. Hitting one replaces the solid block with a spinning one and adds its coordinates and frame counter to a queue. When the frame counter reaches zero, it's replaced with a solid block again. Adding a fifth block to the queue removes the oldest one.
Having been an assembly language programmer in the 8-bit era, I am truly amazed at how great the true masters were at cramming so much stuff into so little memory. Boundary checking? 5 wasted bytes, and we can't spare the CPU cycles, either. Use a lookup table; who cares if level 33 points to the executable program? You can't legitimately get there anyway.
@@komos63modern games (particularly AAA ones) do tend to still be a lot more like this than most software, because squeezing out as many FPS as possible makes the game genuinely better for players with less than cutting-edge hardware.
That animation going through the level is insanely helpful. All the concepts covered are well explained but kinda hard to visualize in practice since so much is happening at once, the animation clears all that at once. It's really really well put!
I’m making a Super Mario Bros ROM hack and I’ve learned so much about the crazy stuff behind the scenes of SMB. SMB feels like it’s one of those facade houses. Only the parts we see work the way you’d expect
I often tell people what you *see* and what you *do* are not the same thing. The naive approach is to mirror reality, but that's rarely most performant or helpful. All video games are lies, there is no Mario. So, when programming games, what you do is lie convincingly.
@@ItsHyomoto Super Mario Bros 3 is a stage play, both in its theme and in the fact that all games are. Modern engines even call the objects "actors" and the levels "scenes". Everything is just behaving according to a script, playing its role. It might sound a bit obvious and/or vague, but that mentality can help when designing the actors. Maybe you want a monster that, when its HP is zero, it still doesn't die until hit one more time? If you approach it as a simulation, you might have coded something like "when anything reaches zero HP, kill it", which would make that case difficult. If you approach it as a play, you'd probably code each monster to do "if my HP is zero, I should switch to my death animation", making it much more flexible.
@@renakunisaki My favorite example is just a player object. The player is the person sitting at the keyboard or gamepad, the actor in front of them is just a collection of 1s and 0s. The only reason they associate with it is because when they press left on the controller it moves.
Generally, in computer science you head for a model which fulfils the requirements it has to - which is usually not the "human way of imagining things". You want 8 worlds? Have a list of 8 numbers as IDs. Accessing the 9th one is not accounted for because it doesn't have to - the game never will do that. You could check for this and handle it nicely, if somebody tries to load world 9, but this takes up the scarce space on the cartridge and as far as your model (-> game) is concerned, loading world 8 will never happen naturally, so why bother? Of course, this is not resistent to bugs and enables glitchy levels like this (instead of giving nice error messages) - but for the usual player, it's perfectly fine and sufficient, while using less memory than a "safer" more extensive style with more checks in place, which do not benefit the player or game at all.
Honestly, I'd like to see that final animation applied to the fully-glitched levels, considering their broken data... Or we could even see _why_ these crashing levels do so, and possibly try and remove what causes the crash to see their true appearence.
I don't know why, but the original mario game has always fascinated me. i guess it's the way retro games work, but i've watched a bunch of videos on this game and it never gets any less fascinating
@@MaxOakland displaced gamer has some videos on the coding logic of SMB1 and some of the other nes games (+ going into the all stars collection as the SNES and NES have the same asm but with 16 bit and 8 bit systems) NES Scrolling Basics featuring Super Mario Bros. - Behind the Code is the first video and New Discovery for Minus World in Super Mario Bros! - Behind the Code for the second video on SMB
With no hyperbole, Super Mario Brothers is the most complex 'official' game for the Famicom *under its original specs.* Virtually every game since then - including SMB2 (Lost Levels) used hardware upgrades on the cartridge or the FDS to expand the amount of usable program and graphical space.
In official Nintendo parlance, level "screens" are called "pages". Screen is the physical screen. The high bit of the second byte is the page flag. What we call "pixels" are dots, as pixels are a physical thing on a physical screen. Screen and pixel are physical. Dot and page are logical. What are sometimes called 8x8 tiles are "characters". What we call "sprites", which Sega uses, Nintendo calls "objects." That is why the sprites are in OAM (object attribute memory) and the background tiles are the "name table", short for character name table.
@@algotkristoffersson15 Because they are professional engineers, not kids on the Internet. "object" was in use for a long time before "sprite." "Character mode graphics" is the proper term in use for a long time.
I have such an enormous level of awe and admiration for the folks behind earlier game design. The creativity which with they were able to execute their ideas in such harsh restrictions is incredible. It may be a silly sentiment, but I think present day designers would benefit from that inspiration. We have so much free space to work in now that it often feels like it's being squandered. Of course, that's just from a lay person's perspective though
@@ariastroke9692And a lot of the time the reason why those textures take up so much space is because they're all gigantic uncompressed 4K textures that just aren't needed on most systems. If someone wants those textures, distribute them separately as a free DLC, so the people who don't want them don't have to download a bunch of textures that are never going to be displayed.
Great details of how they achieved level design with these familiar sprites from the 8 bit days. I've played a lot of Mario brothers and often wondered about some of the underlying methodology - very interesting to see it explained here!
19:14 OH! So this is why you can kill generated bullet bills with a koopa shell but not bullet bills that come out of launchers. They had to share a slot with cheeps.
@@Rocket_Gunner7414 It was worked on by the same software division as Mario 1 and aside from Doki Doki Panic lacking a run button, it controls just like you’d expect a Mario game to. I wouldn’t write it off as not a Mario game
I already was guessing how the game loaded its level data (i.e. only a portion of it) and some of the other stuff also came into my mind when I was experimenting with Brutario (a WIP SMAS:SMB1 level editor). The queuing system is also interesting (which, in hindsight, is actually natural due to the objects' shapes) and also explains the existance of the level foreground pattern but damn, I didn't expect it to be _this_ strict. A lot of the ideas has been transplanted into later games, albeit in a cleaner way. The object compression (i.e. compressing a level data) is the biggest giveway but even in the details, there still are things which are mirror SMB1. SMW, for example, only uses three bytes per object (which, among others, has to do with the fact that objects now keep track of both sizes instead of just one) with the only exceptions being the level destination (which is four bytes) but it still doesn't have an X position high byte (unless it's a vertical level in which case there is no Y high byte) and makes use of the next screen flag as well as the screen skipt to handle more complex positioning. The existence of tileset specific objects (the tile type and special platform setting) also is used albeit in a much greater scale than in SMB1. Yoshi's Island is the most sane, having separated data for objects, teleport destinations (which strictly speaking is part of the foreground data but loaded after all the objects are processed) and sprites as well as no screen skip (it helps that the levels can be as tall as 128 blocks and as wide as 256 blocks so longer objects is ultimately a necessity), though the fact that its level data works on a memory allocation basis results in some interesting level storage (most notably, the game is only able to fill half of the screens) while the object handlers themselves are pretty crazy due to using pointer everywhere as well as storing tileset Map16 data in RAM to save on objects (e.g. the mud floor in the swamp levels use different Map16 tiles but are made of the same object). Furthermore, the sprite tileset can also be used to change the palette and even foreground tileset, something which I made use of it in my YILDC level, btw. The most interesting fact is that SMB1 can change which background decoration is generated which actually explains why the backgrounds in the SMAS version are dynamic and are larger than they fit in VRAM: It's just the modern equivalent of the change background decoration! As an aside, this also is true to TLL (naturally) and SMB2, surprisingly enough. SMB3, on the other hand, uses static backgrounds like SMW. Another thing which is interesting is the fact that the object end byte is 0xFD instead of 0xFF as one might expect. Then again, the screen skip object is easily sacrificeable, it actually makes sense.
I think how the small and big castle are the same but encoded into 2 different bytes blew my mind. I always recognized the small castle on the big one, but didn't realize they were the same object under the hood.
one of my favorite parts of these videos is the interactive content you put on your website like you didn't have to make a level decoder and decode all the glitch levels in full but you did anyways and i appreciate that and it piques my curiosity
There's an interesting trick that comes up in Mega Man 2 hacks where they make multiple enemies load in at different times; normally, most enemies in that game load when they get on-screen, but the trick allows things such as enemies appearing behind Mega Man as well. To my understanding, this is because enemy loading is handled in a similar way as SMB, in that they all need to be done in order; however, instead of breaking if they're out of order, it just delays the earlier enemy until the latter is also loaded. It's quite interesting, though I do wish that I knew the exact way it worked.
If it works the same, then to my understanding, clearing the queue of something that is already loaded (killing an enemy) will allow something to take its place in the queue (the unloaded enemy).
As a programer this really makes me appreciate the amount of effort put into this game! Id love to see something like this for other NES games like mario 3! Though if this one is this complex, I cant imagine more complex games. Goes to show how much faith nintendo had that Mario Bros would take off.
The reason why some glitch levels lag a lot or sometimes crash in the middle of the game is because $0000-$7fff is nes ram, so the level data might not just be invalid, but also change while the game is running
Very interesting. It isn't stored the way I imagined at all. Now the level header thing seems very complex. I'm surprised the game can process all those edge cases so fast. Is the black screen that says "WORLD 1-1 MARIO x 3" secretly a loading screen to unpack the level header?
The real "loading screen" is the blank screen that appears for several frames when you change levels. NES PPU (graphics chip) can't have large amounts of graphics data uploaded except when the screen is 'turned off' (forced blank screen). So in order to update an entire screen's worth of data, the screen needs to stay blank for several frames.
@@Dwedit Interesting. Admittingly, there aren't that many things which need to be prepared for a SMB1 level when everything is basically ready to be used. This contrasts SMW where the Mario Start is an actual loading screen since that's where the level data is decompressed and music is uploaded to ARAM as well as YI where the Yoshi Start sequence does the same _and_ upload all the graphics and stuff.
SMB1 is a bit unique in how it "streams" level data (part of why you can't go backward), so it's essentially loading in the background while you play. Later games had enough RAM (added to the cartridge for NES games) to store a huge tilemap, so they decode the entire level at once, and in some cases use a "start" screen to mask the load time. (This tilemap is the other reason you can't go backward - the game wouldn't be able to remember which blocks you've destroyed/collected.)
huh, the object explanation on how objects don't spawn sometimes for some reasons kinda helps me understand a bit why some stuff doesn't spawn correctly in the lost levels. even tho it's caused by enemies like lakitu, it still kind of helps knowing how object spawning works and actually seeing it
Wouldn’t it be interesting if Mario Maker had a mode that limited you in the same ways as the original SMB NES cartridge (or, sure, the SMB2 FDS disk as well)? It would make for a great ROM hack concept playground! By the way, kudos for the awesome design work on this video, it’s a really good piece of information design on a rather arcane topic.
At 3:00 (world e-1) I used an infinite jump cheat code and there is much more to that level than just a block and the void. I recommend trying it out because there’s more than the void.
UA-cam's got your video categorized as being about 1983's Mario Bros. in the section below the description, instead of 1985's Super Mario Bros. It reminds me of looking up Game Genie codes for SMB in the book and always confusing it with Mario Bros.
I think that level loading animation is easily the coolest thing this channel has produced. I'm a software developer and the stuff these guys did to make this game run is just... My hair is going gray just thinking about all of the edge case BS the devs had to remember. It's a miracle this game doesn't crash all the time.
Trying to make your own SMB1 levels to run on an original NES without a proper editor and compiler is like trying to edit a .JPG picture by opening it in notepad and changing text.
Awesome video! I would love to see you do this again, but for the Super Mario All-Stars version of this game. Most of what you talk about in this video has been retained in that version. When referring to the tile data for each of the above ground type levels in that version, at the end before the tile data terminator ($FD), are two other bytes placed after the end castle sprite. These two extra bytes constitute a scroll stop, which I know you discussed at one point here. In the original NES SMB1, scroll stops were featured in every level type except for above ground ($01), the few exceptions in that case being the cloud type bonus levels and the outside warp zone in 4-2 that takes you to Worlds 6, 7 or 8. Scroll stops were first added to the other above ground type levels beginning with the Japanese Super Mario Bros. 2 (the one we call The Lost Levels), which was released for the Famicom Disk System accessory, but the only iteration of SMB1 to have the scroll stops for the above ground levels in the 8-bit era (outside of the cloud bonus levels and world 4-2's outside warp zone) was All Night Nippon Super Mario Bros., also for the FDS; this title was a promotional data pack that was given away to celebrate the 20th anniversary of the founding of the All Night Nippon radio station.
Fantastic video! Been wanting to understand about this for a long time, and I'd definitely say you did the topic justice. Also really like all the illustrations, and the video at 27:50, that must have been a ton of work!
This guy deserves a medal for communication with diagrams and animations. I imagine most anyone who knows what hexadecimal is could clearly understand what goes on here without even any basic understanding of NES architecture.
After watching this video, I decided to try and recreate some of these levels in Super Mario Maker 2 using the maps linked in the description as a reference. Unfortunately, most of the unique effects produced by the original's level storage method aren't reproducible in SMM2 at all- things like the weird mixtures of tilesets and backgrounds just aren't possible with the way the latter handles level styles. The best I could manage was an approximation with relatively accurate object placements, but it still doesn't have the same magic as these weird messy levels.
Man, I remember these levels on one of those 99999 in 1 cartridges. Half of the Mario games were unplayable and/or had these. Others had some weird effect, I ended up finding one where big mario cannot go small by touching an enemy. I always wondered what was after the black void of E-1, thanks for the maps.
Haa yes I had one of those on my bootleg nes, Polystation. It had thousands of mario versions, most of them normal but others where bugged as heck. I remember the one where the objects came before collision, so you could pass through them and later hit and invisible wall.
World E-1 is giving me flashbacks of that "Super Mario Bros. Frustration" video from like over a decade ago...i thought it was like a 'pre-Kaizo' ROMhack intentionally made to be near-impossible to beat, but i guess it couldve just been a Glitch Level...he DOES end up with 'W-BlueSky lives' at one point...
The lives counter works in an odd way. I might be misremembering but it does something like, if number of lives is greater than 9, draw a crown before the number and subtract 10 from it. So it works correctly for up to 19, then starts showing glitch tiles. (The W was probably the crown icon.) I don't know why they didn't just draw a 1 instead. It would have been much clearer. It would still show glitch tiles after 19, but it already does that. Clearly they never intended it to get that high. That hack just gives you some absurd number of lives.
I actually was trying to recreate levels in the way SMB1 did them in Mario Maker 2, but lacked a ton of the detail of how they worked. This video alone basically setup exactly how to do so, even to the point of limits. Now I feel inspired to make those levels.
2:35 Hello! Actually you can access these crash levels as well using the SZTOLS Game Genie code or setting the 0729 RAM value to 0. Not a technical expert, but there seems to be a part of game code intentionally preventing you from accessing them.
3:26. Can't you get through the wall using that speed running technique where the clip into the block using small Mario forcing themselves to be pushed forward? Its use on I believe its world 4-2 in order to shift the pixels and create the wrong warp exploit. Its difficult but it allows you to hit a block which is a solid wall.
I love your channel so much and keep adding every single video I watch to my "intetesting" playlist. These are the intricacies of retro games I have always been super interested in, explained in a really accesible way. Thank you so much for all the work you do!
"the toad and the princess are the same sprite" Hang on, does this mean toad goes through every castle, pretending that there's a princess that got captured but moved to a different castle, then at the end of the game he dresses up like a princess so Mario can save him? Is this whole game some sick plot by toad just to get attention from Mario?
You forgot: The weird castle block white background empty space, castle level with red background and mario stopped in place, and a glitched level that changes depending on how you move through it.
Game Genie "codes", just me as a kid messing around with them, once took me to a single-screen _Super Mario Bros._ "level" that was nothing but letters / characters from the character map on a black background. Their locations had some property where Mario would bounce on them but couldn't "land". No clue what it was pointing at...!
Absolutely fantastic video series! 🌟 Even though I'm not a tech expert and didn't grasp every detail (from part 2 onwards my brain was technically out most of the time 😂), I'm blown away by the clarity and depth of the explanation, it really covers the topic very interestingly. It's not the video's fault that I didn't fully understand everything; it's just super extensive stuff and I don't have a particularly good brain! The previous two parts of this series were also incredible. The animation is top-notch, and the whole presentation feels so high-quality. Keep up the great work! 👍
I love this video so much. Is there any chance you'd be willing to do a similar video about how SMB3 stores its levels? They tend to be larger and more complex than those in SMB1, and I'm really curious as to how they managed to fit so many in the cartridge.
One of my favorite nuances with smbs worlds is that the levels can be labeled in different ways. 8-4 for example can be 1-36 (using cree3po's smb any worlds patch) X-4 can be (x+1)-0 (2-0 is 1-4) And it even works with negatives.
The level maps are incredibly fascinating. Would you be willing to share the code you wrote to make these? The SMB map/tile format is extremely interesting and I wanted to try doing something like this on my own to understand it better, but had no idea where to begin.
I feel like this could be used to make some super cool custom levels that change colors when you go through a pipe like a weird NES Mario maker. It might require force-freezing certain parts of the RAM to be stable to get it to work but it should, ignoring issues _that_ would cause, work
Interesting how the loading is more of a technicality of how objects and the level worked with loading stuff into memory. I'm curious to know how that changed in SMB3/SMW and how they handle their loading of objects instead. Especially SMB3 since it too was developed on the NES.
The biggest advantage both games have is the fact that they can have the complete level data stored in RAM so they don't have to build the levels on the fly and thus allow for bidirectional scrolling.
SMB3 uses a similar object system, but it unpacks all the individual tiles into RAM on the cartridge, so going backwards and diagonally is that much easier.
@@warmCabin So basically it pre-constructs the entire level, as if it were going to copy the data to VRAM, but instead unpacks it from ROM to cartridge RAM, and during the game the portion of the level that Mario is at gets copied from the cartridge RAM to VRAM. Right?
@@williamdrum9899 Not quite. It stores each individual _tile,_ like brick, cloud, or question block w/ fire flower, to be used as collision data. Then the drawing code can dig into that data based on your screen scroll or whatever. Look up 100th coin on UA-cam, he taught me everything I'm telling you
Great explanation! Thanks for the in-depth review and graphics that tied it all together. The timeline at the end is a masterclass in using visuals to teach a complex subject. Well done.
As I've done some SMB romhacking before, this was very interesting, and easier to understand than videos o this style on other games. But when it came to the "objects in those specific Y values", I think it would have been helpful if you showed how they look in the SMB Utility program, being 1, 2, or 3 tiles below the bottom of the floor.
All your videos have excellent graphical representations, but this really stood out to me! Truly amazing! I didn't know how intricate the level loading was in this game, very interesting!
So, now knowing this - I'm kind of curious how Super Mario Bros 3 differs. The levels of this game's threequel are WAY more varied. Is SMB3 using a form of floor pattern switching and prebuilt level elements like this? Or are they storing rows and rows of individual tiles?
The most important point is that SMB3 keeps track of the whole level instead of just a portion so the object codes are very much simplified compared to SMB1.
Great stuff like always! I wonder how much work would be required in order to allow going backwards in a level, and still get the routines to load the proper data at the correct place. Probably something painful, lol
I there any chance that the "Hard Made" flag is processed before being added to the queue, meaning that you could remove platforms by purposefully overloading the queue to make the level harder the second time around? That could be interesting to play around with.
I assumed that level tile data would at least be stored via RLE, it's interesting to know they went so much further and defined preset tile and sprite 'groups' for quickly roughing in the map and placing recurring objects like the flag staircase, pipes, etc. Thus, requiring very little space to encode additional customizations. 🤔 Oh-ho~ so not being able to scroll the level back was as much a technical limitation as anything else?! Now I'd be all the more interested to hear how SMB3's engine works! 🤩
Outstanding series as always. It's crazy how the developers came up with such complex routine to encode level data to save space. But I think is crazier how to level designers managed to create fun levels with these restrictions - or maybe they were the same people lol. Cheers
3:25 believe it or not, it's actually possible to get past that wall RTA, by doing a clip in the corner of the clouds. There are koopas in the 2nd level up, so you have to clip in the 4th level up, which is tricky, but doable, especially with savestates. There are also some other obstacles that you need to clip around, but point is, it is possible to progress.
0:26 when I was a kid I had one of those bootleg Famicom cartridges pretending to have like 2000 games, and one of those was a broken Super Mario Bros. that started with this level... oh it was so mystifying for a kid to wonder how to beat this "game" :D
I remember some hacked ROMs circulating online back in the day, which changed the startup code for some reason (cheats and/or bootlegs that erased the title). They expected all memory to be cleared a certain way at power on. But since many emulators (and for that matter, real consoles) didn't do that, you'd start in World 0-1, or Mario just wouldn't show up.
Really great video as always! I'm curious though...if the level is loaded left to right and level data is assumed to be organized left to right, what's the point of having an X coordinate in the object data? To me, it seems like it would make more sense to instead use that "next screen" flag bit as a "next column" flag instead (and maybe expand it to be two or three bits wide, allowing larger jumps as well). That way, when loading a column, the game would just load objects on the current column until that flag is set. The only problem I see with this is that the queue system wouldn't work for objects larger than one column, but I think that could be fixed by adding an "offset" byte to each item in the queue that starts at zero and is incremented by one every time a column is drawn to track progress on rendering it
It was the first time they used an object system like that. Zelda 2 would refine the system. Zelda 2 used something very similar, but instead of storing an X coordinate, they stored the difference between this object's X coordinate and the previous object's X coordinate. Then you don't need the "Next Page" flag anymore, so you can double the number of possible objects.
I think Super Mario Land 1 does something kinda like this. The level data is one byte per column, indexing into a list of columns (and each column is a list of tiles). I'm not sure though.
If you had ground in e-1 you would find random monochrome level tiles, and in w-1 if you could walk it would crash soon after. Plus in 62-1 if you could walk you would walkdown a hall way until you reached a wall and if you could walk through walls you would continue walking until the scrolling stops or the time runs out.
What about upside down pipes, how are they encoded? I assume that every pipe comes with a piranha plant, and the upside down pipes seem to come with upside down piranha plants, so they can't be too much of a hack?
Instead of changing the world value, what about the level value? Also the game genie has anti crash codes that don’t crash the game (which a game genie is the best way to play these worlds on real hardware)
It's really interesting (and makes perfect creepypasta material) how nobody intentionally created it. It just "exists." Granted, it exists because the level loading algorithm is interpreting stuff that isn't a level as though it were bona-fide level data, but still.
@@williamdrum9899 I would have loved to see the developers' reactions. People keep talking about a secret level, but you know there isn't one because you didn't put one in... wait, what's this!?
Here's a link to the video with the full playthrough of the game! ua-cam.com/video/1whju31WAPA/v-deo.html
You can support the channel on Patreon here: patreon.rgmechex.com/
0:50 The moment I saw this, I realized all this could be prevented with "AND #7". And yet the programmers chose not to. They had some major cajones (or desperately needed to save the two bytes required to bounds check) to leave that out.
5:38 1 kilobyte equals a thousand bytes not 1024. You're thinking of a kibibyte actually
Now make another note on the follow up video explaining all the possible level numbers you can increment to.
@@neb_setabed computer term
What font do you use for your videos? It seems like it was designed to look monospace, but with a couple of clever tricks to increase readability, like a ligature for a comma-space that is just one character wide. Did you make it yourself?
The fact that pipe warps have a check for what world you're in is interesting, that explains why in every single glitch level I've ever seen, there has NEVER been a pipe transition that successfully takes you to a different level.
Case in point: -1 which is identical to 2-2 but is unbeatable because the pipe just brings you back to the beginning.
In Kosmic's series of glitched worlds, the first time a pipe took him do a different level was in something like 1-111. There was probably a warp sprite that just by chance only occurred when it's world 1.
Sections of levels are reused between others.
Thus, a warp pipe is always a warp pipe (1-1 being an exception)
@@MarioFanGamer659 Actually it's 7-2
1-× is 19 code of world in rom
As a programmer myself, I am pulling my head in front of those who developed this format and the loading routine.
All these edge cases create a lot of branches in the code, making the routine really complex.
Crazy to think of these times where ROM was so expensive you had to play such tricks.
I wished the video would have gotten more down to the reasons these levels crash.
probably the same reason that creatures like the liger and zedonk are unable to reproduce; they were never meant to exist in the first place
Back in the days before speculative execution made this kind of thing too expensive.
Not just ROM. This predated the memory-mapper chips that defined what NES-era games looked like. Even if it was affordable, there wasn't a means of addressing more than 32 + 8 K of program/object data.
@@darren8453what is speculative execution and why?
@@algotkristoffersson15 modern cpu performance is more or less defined by the ability to find work that can be done, to keep the instruction pipelines full. Long pipelines mean less work done at each stage, meaning breaking up the longest running instructions into smaller steps and so allowing the clock speed for all operations to be increased.
Instructions start at the first pipeline step and are delivered to the next step on each cycle. But in order for this to execute instructions efficiently you need to find lots of work to do on each cycle, as the latency to execute each individual instruction is 20 cycles. This becomes harder at the point of a condition or branch, as it is unknown which set of instructions to start adding to the pipeline next.
Modern cpu design uses a lot of prediction to allow the cpu to try and schedule work. This prediction takes advantage of various locality correlations in code - branches tend to be mostly taken or mostly untaken and the processor can track this.
If the cpu guesses correctly, it has done a set of work ahead of time and can carry on. If incorrect, it has to remove the instructions from the pipeline (they are tagged and tracked) and return the processor to an earlier state to take the alternative path. This "pipeline flush" work is very expensive and results in no useful work done during this time.
This is speculative execution, and in especially branch heavy code it struggles to get every decision right. The code mentioned in this video would not be written today, mostly for that reason.
And what made this even more hardcore is the fact that Shigeru Miyamote and his team had to design levels by hand on graph paper, then manually enter in the bit registers for every BG, BG theme, tile data, and object data for each level into their source-code editor while paying attention to the rules of the programming logic they had written to avoid lockups, crashes, and glitches, and then compile the game and run it to playtest it.
At the time, there were nearly no game development tools available to allow on the fly level editing or playtesting without having to recompile the whole game.
No emulators either, including the fancy devices we have now that emulate a cartridge. Each test attempt had to be written to EPROM, which took a while!
They must have been relieved when FDS came along and they could use disks to quickly load from for testing, even if the final game only used ROM.
I know they even made a SNES floppy disk drive for development - not related to the CD-ROM drive that would later become the PlayStation; this was for internal use only. Some of the leaked Super Mario Kart code uses it to run a level editor. Even some N64 games used the 64DD as a debug tool long after it was cancelled.
*That's the original Paper'a Mariooooooo !!!*
This level encoding is a masterpiece of engineering, and is "living" proof that real art is born from limitations. 2k of ram, 32k of data... What the programmers and game designers were able to do within these constraints is staggering. Thank you for explaining this!
Pfft
The most impressive part here is that SMB1 is a full game and not a minigame as many other games were around its time but also exists on a vanilla cartridge (i.e. no MMC, no extra RAM). Even as an arcade game (given that lives, score and hard mode are a thing), it still would be one of the more complex ones due to the variety of levels here.
How about Atari 2600 specs? 128 *BYTES, NOT KILO-BYTES* of RAM, 4K of ROM.... Made a fully functional platformer!
@@MarioFanGamer659 you mean *most* games of its time.
Lots of games (most?) were still either conversions of arcade games, or were original but mimicked arcade mechanics. And arcade games tended to be minigames.
@@kargaroc386the defenition of a minigame is “a smaller game included within another game” not “a game based around obtaining a high score” therefore it is completely impossible for an entire game to be a minigame.
As a kid, i always wanted to make my own Super Mario Bros. levels. It seemed so simple in my mind, and you almost nailed the concept i had with level storage back then (and 10 year old kid-me was frustrated at the lack of easy tools to do so). Watching this video makes so much sense to me why the reality is that was so much harder to achieve, and why there is a base level of understanding of the game's engine required to make a custom level. Really great video (and series) as always!
how did you comment 2 days ago if this was uploaded 2 seconds ago?
Patreon and SubscribeStar supporters get to see the video a few days early.
@@RGMechEx ohhh i see
i used to draw whack SMB levels in graph papers.
@@araigumakiruno I drew my own in church haha
If you're wondering how you can bump blocks when everything is on a fixed grid, there is a trick to it. First you delete the tile from the tile map, replace it with a sprite with the same tile image and animate the bump. Then at the end of the animation, you remove the sprite and if the tile object is not destructible, put the original tile back into the tile map.
The book "I Am Error" also covers the SMB1 level format (along with a lot of other NES stuff). Recommended.
That's also why the Emerald Framers in Adventures of Lolo lose a color while you're pushing one.
This is why in Super Mario World, there can only be four spinning blocks at once. Hitting one replaces the solid block with a spinning one and adds its coordinates and frame counter to a queue. When the frame counter reaches zero, it's replaced with a solid block again. Adding a fifth block to the queue removes the oldest one.
This is why my gf left me
Having been an assembly language programmer in the 8-bit era, I am truly amazed at how great the true masters were at cramming so much stuff into so little memory. Boundary checking? 5 wasted bytes, and we can't spare the CPU cycles, either. Use a lookup table; who cares if level 33 points to the executable program? You can't legitimately get there anyway.
Yeah, and it made glitches so much more fun.
If only modern games were made like this...
@@komos63modern games (particularly AAA ones) do tend to still be a lot more like this than most software, because squeezing out as many FPS as possible makes the game genuinely better for players with less than cutting-edge hardware.
That animation going through the level is insanely helpful. All the concepts covered are well explained but kinda hard to visualize in practice since so much is happening at once, the animation clears all that at once. It's really really well put!
oh this is excellent. everything I could have asked for for a video about this topic
I’m making a Super Mario Bros ROM hack and I’ve learned so much about the crazy stuff behind the scenes of SMB. SMB feels like it’s one of those facade houses. Only the parts we see work the way you’d expect
I often tell people what you *see* and what you *do* are not the same thing. The naive approach is to mirror reality, but that's rarely most performant or helpful. All video games are lies, there is no Mario. So, when programming games, what you do is lie convincingly.
@@ItsHyomoto Super Mario Bros 3 is a stage play, both in its theme and in the fact that all games are.
Modern engines even call the objects "actors" and the levels "scenes". Everything is just behaving according to a script, playing its role.
It might sound a bit obvious and/or vague, but that mentality can help when designing the actors. Maybe you want a monster that, when its HP is zero, it still doesn't die until hit one more time? If you approach it as a simulation, you might have coded something like "when anything reaches zero HP, kill it", which would make that case difficult. If you approach it as a play, you'd probably code each monster to do "if my HP is zero, I should switch to my death animation", making it much more flexible.
@@renakunisaki My favorite example is just a player object. The player is the person sitting at the keyboard or gamepad, the actor in front of them is just a collection of 1s and 0s. The only reason they associate with it is because when they press left on the controller it moves.
Generally, in computer science you head for a model which fulfils the requirements it has to - which is usually not the "human way of imagining things".
You want 8 worlds? Have a list of 8 numbers as IDs. Accessing the 9th one is not accounted for because it doesn't have to - the game never will do that.
You could check for this and handle it nicely, if somebody tries to load world 9, but this takes up the scarce space on the cartridge and as far as your model (-> game) is concerned, loading world 8 will never happen naturally, so why bother?
Of course, this is not resistent to bugs and enables glitchy levels like this (instead of giving nice error messages) - but for the usual player, it's perfectly fine and sufficient, while using less memory than a "safer" more extensive style with more checks in place, which do not benefit the player or game at all.
Honestly, I'd like to see that final animation applied to the fully-glitched levels, considering their broken data...
Or we could even see _why_ these crashing levels do so, and possibly try and remove what causes the crash to see their true appearence.
indeed
I don't know why, but the original mario game has always fascinated me. i guess it's the way retro games work, but i've watched a bunch of videos on this game and it never gets any less fascinating
It was a marvel of coding done with limited resources in a time when video games were seen as bad. Such a legendary work.
Me too. Have any links to other good videos?
@@MaxOakland displaced gamer has some videos on the coding logic of SMB1 and some of the other nes games (+ going into the all stars collection as the SNES and NES have the same asm but with 16 bit and 8 bit systems)
NES Scrolling Basics featuring Super Mario Bros. - Behind the Code
is the first video and
New Discovery for Minus World in Super Mario Bros! - Behind the Code
for the second video on SMB
With no hyperbole, Super Mario Brothers is the most complex 'official' game for the Famicom *under its original specs.* Virtually every game since then - including SMB2 (Lost Levels) used hardware upgrades on the cartridge or the FDS to expand the amount of usable program and graphical space.
In official Nintendo parlance, level "screens" are called "pages". Screen is the physical screen. The high bit of the second byte is the page flag. What we call "pixels" are dots, as pixels are a physical thing on a physical screen. Screen and pixel are physical. Dot and page are logical. What are sometimes called 8x8 tiles are "characters". What we call "sprites", which Sega uses, Nintendo calls "objects." That is why the sprites are in OAM (object attribute memory) and the background tiles are the "name table", short for character name table.
Why are they calling things stuff that literally no-one else calls them?
@@algotkristoffersson15 Because they are professional engineers, not kids on the Internet. "object" was in use for a long time before "sprite." "Character mode graphics" is the proper term in use for a long time.
19:18 i knew it! peach was actually toad in disguise the whole time!
Fraud exposed 🗣🗣🗣
I have such an enormous level of awe and admiration for the folks behind earlier game design. The creativity which with they were able to execute their ideas in such harsh restrictions is incredible. It may be a silly sentiment, but I think present day designers would benefit from that inspiration. We have so much free space to work in now that it often feels like it's being squandered. Of course, that's just from a lay person's perspective though
Nah, you're right. How big games are now feels unnecessary and people keep saying it's justified because you spend 150+ gigabytes on textures alone.
@@ariastroke9692And a lot of the time the reason why those textures take up so much space is because they're all gigantic uncompressed 4K textures that just aren't needed on most systems. If someone wants those textures, distribute them separately as a free DLC, so the people who don't want them don't have to download a bunch of textures that are never going to be displayed.
Great details of how they achieved level design with these familiar sprites from the 8 bit days. I've played a lot of Mario brothers and often wondered about some of the underlying methodology - very interesting to see it explained here!
19:14 OH! So this is why you can kill generated bullet bills with a koopa shell but not bullet bills that come out of launchers. They had to share a slot with cheeps.
Huh
No, they're just a different sprite. If you were to spawn a bullet bill without a canon, youd also be able to kill it with a shell
I would love to see an analysis on how they improved all these mechanics in SMB3
Need Mario 2 first!
@@MaxOakland uh lost levels is very VERY similar
@@Rocket_Gunner7414 They’re probably referring to Super Mario USA
@@Nightcaat yea But that's not really a mario game
@@Rocket_Gunner7414 It was worked on by the same software division as Mario 1 and aside from Doki Doki Panic lacking a run button, it controls just like you’d expect a Mario game to. I wouldn’t write it off as not a Mario game
I already was guessing how the game loaded its level data (i.e. only a portion of it) and some of the other stuff also came into my mind when I was experimenting with Brutario (a WIP SMAS:SMB1 level editor). The queuing system is also interesting (which, in hindsight, is actually natural due to the objects' shapes) and also explains the existance of the level foreground pattern but damn, I didn't expect it to be _this_ strict.
A lot of the ideas has been transplanted into later games, albeit in a cleaner way. The object compression (i.e. compressing a level data) is the biggest giveway but even in the details, there still are things which are mirror SMB1. SMW, for example, only uses three bytes per object (which, among others, has to do with the fact that objects now keep track of both sizes instead of just one) with the only exceptions being the level destination (which is four bytes) but it still doesn't have an X position high byte (unless it's a vertical level in which case there is no Y high byte) and makes use of the next screen flag as well as the screen skipt to handle more complex positioning. The existence of tileset specific objects (the tile type and special platform setting) also is used albeit in a much greater scale than in SMB1.
Yoshi's Island is the most sane, having separated data for objects, teleport destinations (which strictly speaking is part of the foreground data but loaded after all the objects are processed) and sprites as well as no screen skip (it helps that the levels can be as tall as 128 blocks and as wide as 256 blocks so longer objects is ultimately a necessity), though the fact that its level data works on a memory allocation basis results in some interesting level storage (most notably, the game is only able to fill half of the screens) while the object handlers themselves are pretty crazy due to using pointer everywhere as well as storing tileset Map16 data in RAM to save on objects (e.g. the mud floor in the swamp levels use different Map16 tiles but are made of the same object). Furthermore, the sprite tileset can also be used to change the palette and even foreground tileset, something which I made use of it in my YILDC level, btw.
The most interesting fact is that SMB1 can change which background decoration is generated which actually explains why the backgrounds in the SMAS version are dynamic and are larger than they fit in VRAM: It's just the modern equivalent of the change background decoration! As an aside, this also is true to TLL (naturally) and SMB2, surprisingly enough. SMB3, on the other hand, uses static backgrounds like SMW.
Another thing which is interesting is the fact that the object end byte is 0xFD instead of 0xFF as one might expect. Then again, the screen skip object is easily sacrificeable, it actually makes sense.
It can help to think of the object data as a sequence of bits rather than a sequence of bytes.
I think how the small and big castle are the same but encoded into 2 different bytes blew my mind. I always recognized the small castle on the big one, but didn't realize they were the same object under the hood.
The fact that the big castle is just the small castle extended down, with extra bits added to the sides, is what got me.
Whenever I accidentally make the small castle big during level editing (by moving it above the ground) I am absolutely disgusted each and every time
one of my favorite parts of these videos is the interactive content you put on your website
like you didn't have to make a level decoder and decode all the glitch levels in full but you did anyways and i appreciate that and it piques my curiosity
There's an interesting trick that comes up in Mega Man 2 hacks where they make multiple enemies load in at different times; normally, most enemies in that game load when they get on-screen, but the trick allows things such as enemies appearing behind Mega Man as well. To my understanding, this is because enemy loading is handled in a similar way as SMB, in that they all need to be done in order; however, instead of breaking if they're out of order, it just delays the earlier enemy until the latter is also loaded. It's quite interesting, though I do wish that I knew the exact way it worked.
If it works the same, then to my understanding, clearing the queue of something that is already loaded (killing an enemy) will allow something to take its place in the queue (the unloaded enemy).
As a programer this really makes me appreciate the amount of effort put into this game! Id love to see something like this for other NES games like mario 3! Though if this one is this complex, I cant imagine more complex games. Goes to show how much faith nintendo had that Mario Bros would take off.
The reason why some glitch levels lag a lot or sometimes crash in the middle of the game is because $0000-$7fff is nes ram, so the level data might not just be invalid, but also change while the game is running
I'm sure you have a typo with the RAM memory because the NES has 2 KiB or RAM which is enough to fill go from $0000 to $07FF but not any higher.
Very interesting. It isn't stored the way I imagined at all. Now the level header thing seems very complex. I'm surprised the game can process all those edge cases so fast. Is the black screen that says "WORLD 1-1 MARIO x 3" secretly a loading screen to unpack the level header?
The real "loading screen" is the blank screen that appears for several frames when you change levels. NES PPU (graphics chip) can't have large amounts of graphics data uploaded except when the screen is 'turned off' (forced blank screen). So in order to update an entire screen's worth of data, the screen needs to stay blank for several frames.
@@Dwedit Interesting. Admittingly, there aren't that many things which need to be prepared for a SMB1 level when everything is basically ready to be used.
This contrasts SMW where the Mario Start is an actual loading screen since that's where the level data is decompressed and music is uploaded to ARAM as well as YI where the Yoshi Start sequence does the same _and_ upload all the graphics and stuff.
SMB1 is a bit unique in how it "streams" level data (part of why you can't go backward), so it's essentially loading in the background while you play.
Later games had enough RAM (added to the cartridge for NES games) to store a huge tilemap, so they decode the entire level at once, and in some cases use a "start" screen to mask the load time.
(This tilemap is the other reason you can't go backward - the game wouldn't be able to remember which blocks you've destroyed/collected.)
Your presentation tools to visually show the mechanics and what happens in memory are amazing. I love these videos
huh, the object explanation on how objects don't spawn sometimes for some reasons kinda helps me understand a bit why some stuff doesn't spawn correctly in the lost levels. even tho it's caused by enemies like lakitu, it still kind of helps knowing how object spawning works and actually seeing it
Wouldn’t it be interesting if Mario Maker had a mode that limited you in the same ways as the original SMB NES cartridge (or, sure, the SMB2 FDS disk as well)? It would make for a great ROM hack concept playground!
By the way, kudos for the awesome design work on this video, it’s a really good piece of information design on a rather arcane topic.
At 3:00 (world e-1) I used an infinite jump cheat code and there is much more to that level than just a block and the void. I recommend trying it out because there’s more than the void.
That's because it uses random RAM code. It's always different and pretty much endless.
4:04 that's honestly very poetic in a way I don't fully understand
UA-cam's got your video categorized as being about 1983's Mario Bros. in the section below the description, instead of 1985's Super Mario Bros. It reminds me of looking up Game Genie codes for SMB in the book and always confusing it with Mario Bros.
I think that level loading animation is easily the coolest thing this channel has produced. I'm a software developer and the stuff these guys did to make this game run is just... My hair is going gray just thinking about all of the edge case BS the devs had to remember. It's a miracle this game doesn't crash all the time.
Trying to make your own SMB1 levels to run on an original NES without a proper editor and compiler is like trying to edit a .JPG picture by opening it in notepad and changing text.
2:40 ”just a lone question block” aw there’s a koopa too, RIP koopa
Awesome video! I would love to see you do this again, but for the Super Mario All-Stars version of this game. Most of what you talk about in this video has been retained in that version. When referring to the tile data for each of the above ground type levels in that version, at the end before the tile data terminator ($FD), are two other bytes placed after the end castle sprite. These two extra bytes constitute a scroll stop, which I know you discussed at one point here.
In the original NES SMB1, scroll stops were featured in every level type except for above ground ($01), the few exceptions in that case being the cloud type bonus levels and the outside warp zone in 4-2 that takes you to Worlds 6, 7 or 8. Scroll stops were first added to the other above ground type levels beginning with the Japanese Super Mario Bros. 2 (the one we call The Lost Levels), which was released for the Famicom Disk System accessory, but the only iteration of SMB1 to have the scroll stops for the above ground levels in the 8-bit era (outside of the cloud bonus levels and world 4-2's outside warp zone) was All Night Nippon Super Mario Bros., also for the FDS; this title was a promotional data pack that was given away to celebrate the 20th anniversary of the founding of the All Night Nippon radio station.
Fantastic video! Been wanting to understand about this for a long time, and I'd definitely say you did the topic justice. Also really like all the illustrations, and the video at 27:50, that must have been a ton of work!
This guy deserves a medal for communication with diagrams and animations. I imagine most anyone who knows what hexadecimal is could clearly understand what goes on here without even any basic understanding of NES architecture.
Great video. Instead of framing the video as how glitch levels work, it could just be how level data is stored.
After watching this video, I decided to try and recreate some of these levels in Super Mario Maker 2 using the maps linked in the description as a reference. Unfortunately, most of the unique effects produced by the original's level storage method aren't reproducible in SMM2 at all- things like the weird mixtures of tilesets and backgrounds just aren't possible with the way the latter handles level styles. The best I could manage was an approximation with relatively accurate object placements, but it still doesn't have the same magic as these weird messy levels.
Very interesting stuff! Really love the effect you put into the animations and explaining the loading algorithm!
Man, I remember these levels on one of those 99999 in 1 cartridges. Half of the Mario games were unplayable and/or had these. Others had some weird effect, I ended up finding one where big mario cannot go small by touching an enemy.
I always wondered what was after the black void of E-1, thanks for the maps.
Haa yes I had one of those on my bootleg nes, Polystation. It had thousands of mario versions, most of them normal but others where bugged as heck. I remember the one where the objects came before collision, so you could pass through them and later hit and invisible wall.
World E-1 is giving me flashbacks of that "Super Mario Bros. Frustration" video from like over a decade ago...i thought it was like a 'pre-Kaizo' ROMhack intentionally made to be near-impossible to beat, but i guess it couldve just been a Glitch Level...he DOES end up with 'W-BlueSky lives' at one point...
The lives counter works in an odd way. I might be misremembering but it does something like, if number of lives is greater than 9, draw a crown before the number and subtract 10 from it. So it works correctly for up to 19, then starts showing glitch tiles. (The W was probably the crown icon.)
I don't know why they didn't just draw a 1 instead. It would have been much clearer. It would still show glitch tiles after 19, but it already does that. Clearly they never intended it to get that high.
That hack just gives you some absurd number of lives.
Ah yes "🟦 - 1"
I actually was trying to recreate levels in the way SMB1 did them in Mario Maker 2, but lacked a ton of the detail of how they worked. This video alone basically setup exactly how to do so, even to the point of limits. Now I feel inspired to make those levels.
2:35
Hello! Actually you can access these crash levels as well using the SZTOLS Game Genie code or setting the 0729 RAM value to 0. Not a technical expert, but there seems to be a part of game code intentionally preventing you from accessing them.
3:26. Can't you get through the wall using that speed running technique where the clip into the block using small Mario forcing themselves to be pushed forward? Its use on I believe its world 4-2 in order to shift the pixels and create the wrong warp exploit. Its difficult but it allows you to hit a block which is a solid wall.
I love your channel so much and keep adding every single video I watch to my "intetesting" playlist. These are the intricacies of retro games I have always been super interested in, explained in a really accesible way. Thank you so much for all the work you do!
Honestly, super cool! I loved the explanation, very informative!
"the toad and the princess are the same sprite"
Hang on, does this mean toad goes through every castle, pretending that there's a princess that got captured but moved to a different castle, then at the end of the game he dresses up like a princess so Mario can save him? Is this whole game some sick plot by toad just to get attention from Mario?
You forgot: The weird castle block white background empty space, castle level with red background and mario stopped in place, and a glitched level that changes depending on how you move through it.
Game Genie "codes", just me as a kid messing around with them, once took me to a single-screen _Super Mario Bros._ "level" that was nothing but letters / characters from the character map on a black background. Their locations had some property where Mario would bounce on them but couldn't "land". No clue what it was pointing at...!
Absolutely fantastic video series! 🌟 Even though I'm not a tech expert and didn't grasp every detail (from part 2 onwards my brain was technically out most of the time 😂), I'm blown away by the clarity and depth of the explanation, it really covers the topic very interestingly.
It's not the video's fault that I didn't fully understand everything; it's just super extensive stuff and I don't have a particularly good brain!
The previous two parts of this series were also incredible. The animation is top-notch, and the whole presentation feels so high-quality. Keep up the great work! 👍
I love this video so much. Is there any chance you'd be willing to do a similar video about how SMB3 stores its levels? They tend to be larger and more complex than those in SMB1, and I'm really curious as to how they managed to fit so many in the cartridge.
One of my favorite nuances with smbs worlds is that the levels can be labeled in different ways.
8-4 for example can be 1-36 (using cree3po's smb any worlds patch)
X-4 can be (x+1)-0 (2-0 is 1-4)
And it even works with negatives.
YES! I've waited so long for this video! I subscribed just for this video!
The level maps are incredibly fascinating. Would you be willing to share the code you wrote to make these? The SMB map/tile format is extremely interesting and I wanted to try doing something like this on my own to understand it better, but had no idea where to begin.
I'm always so excited when you upload.
First video of yours that I've seen and it is extremely high quality. I'll be taking a look at the rest of your catalog.
these videos are so incredibly well-made, please never stop creating them!
I feel like this could be used to make some super cool custom levels that change colors when you go through a pipe like a weird NES Mario maker. It might require force-freezing certain parts of the RAM to be stable to get it to work but it should, ignoring issues _that_ would cause, work
I never would've guessed that the levels in this game had to be implemented so intricately. This is incredible!
Interesting how the loading is more of a technicality of how objects and the level worked with loading stuff into memory. I'm curious to know how that changed in SMB3/SMW and how they handle their loading of objects instead. Especially SMB3 since it too was developed on the NES.
SMB3 had a lot more cartridge space than SMB1 did, plus it had four-way scrolling so I imagine they would be vastly different.
The biggest advantage both games have is the fact that they can have the complete level data stored in RAM so they don't have to build the levels on the fly and thus allow for bidirectional scrolling.
SMB3 uses a similar object system, but it unpacks all the individual tiles into RAM on the cartridge, so going backwards and diagonally is that much easier.
@@warmCabin So basically it pre-constructs the entire level, as if it were going to copy the data to VRAM, but instead unpacks it from ROM to cartridge RAM, and during the game the portion of the level that Mario is at gets copied from the cartridge RAM to VRAM. Right?
@@williamdrum9899 Not quite. It stores each individual _tile,_ like brick, cloud, or question block w/ fire flower, to be used as collision data. Then the drawing code can dig into that data based on your screen scroll or whatever. Look up 100th coin on UA-cam, he taught me everything I'm telling you
Great explanation! Thanks for the in-depth review and graphics that tied it all together. The timeline at the end is a masterclass in using visuals to teach a complex subject. Well done.
Amazing video with great visuals as always!
As I've done some SMB romhacking before, this was very interesting, and easier to understand than videos o this style on other games.
But when it came to the "objects in those specific Y values", I think it would have been helpful if you showed how they look in the SMB Utility program, being 1, 2, or 3 tiles below the bottom of the floor.
All your videos have excellent graphical representations, but this really stood out to me! Truly amazing! I didn't know how intricate the level loading was in this game, very interesting!
Great video!
Now I want a video explaining how Zelda 1 stores screens 🥺
After all that wasteful JSON/YAML at work, your videos are like a Spa for the mind… 😌
So, now knowing this - I'm kind of curious how Super Mario Bros 3 differs. The levels of this game's threequel are WAY more varied. Is SMB3 using a form of floor pattern switching and prebuilt level elements like this? Or are they storing rows and rows of individual tiles?
it mostly uses a bunch of pre-built elements like SMB1. the channel 100th Coin has a pretty detailed video about it!
The most important point is that SMB3 keeps track of the whole level instead of just a portion so the object codes are very much simplified compared to SMB1.
this actually explains why there is nothing after the flagpole, becuase it reached the end of the list.
Thank you for making this explanation, I loved reading these kind of specs from txt files but of course having cool visualizations is even better :)
Simply amazing. Thank you for doing all this research and putting it into such a digestible format!
Great stuff like always!
I wonder how much work would be required in order to allow going backwards in a level, and still get the routines to load the proper data at the correct place.
Probably something painful, lol
I there any chance that the "Hard Made" flag is processed before being added to the queue, meaning that you could remove platforms by purposefully overloading the queue to make the level harder the second time around? That could be interesting to play around with.
Hard mode only applies to sprites, not the background object system.
I assumed that level tile data would at least be stored via RLE, it's interesting to know they went so much further and defined preset tile and sprite 'groups' for quickly roughing in the map and placing recurring objects like the flag staircase, pipes, etc. Thus, requiring very little space to encode additional customizations. 🤔 Oh-ho~ so not being able to scroll the level back was as much a technical limitation as anything else?! Now I'd be all the more interested to hear how SMB3's engine works! 🤩
I am LIVING for this series
this makes me wanna see more from you, maybe stuff like bugged objects from Super Mario World when the game is corrupted in some way
Outstanding series as always. It's crazy how the developers came up with such complex routine to encode level data to save space. But I think is crazier how to level designers managed to create fun levels with these restrictions - or maybe they were the same people lol. Cheers
Have you ever been to MissingNo - MissingNos Brother? that level was wild!
Timestamps:
0:00 Intro
0:36 Glitch level cause summary
2:03 GL showcase
5:07 Tile data
6:20 Level header
8:34 Object format
17:04 Floor pattern
18:18 Sprite data
20:00 Y-position 15
20:36 Y-position 14
23:00 Level formatting requirements
27:27 Foreshadowing
27:50 Animation time
"Mario eventually meets his worst enemy... A single lone brick block" Best narration of all time
3:25 believe it or not, it's actually possible to get past that wall RTA, by doing a clip in the corner of the clouds. There are koopas in the 2nd level up, so you have to clip in the 4th level up, which is tricky, but doable, especially with savestates. There are also some other obstacles that you need to clip around, but point is, it is possible to progress.
0:26 when I was a kid I had one of those bootleg Famicom cartridges pretending to have like 2000 games, and one of those was a broken Super Mario Bros. that started with this level... oh it was so mystifying for a kid to wonder how to beat this "game" :D
Even if you have a weird SMB1 bootleg cartridge, the A+Start continue code will still start you at 1-1.
I remember some hacked ROMs circulating online back in the day, which changed the startup code for some reason (cheats and/or bootlegs that erased the title). They expected all memory to be cleared a certain way at power on. But since many emulators (and for that matter, real consoles) didn't do that, you'd start in World 0-1, or Mario just wouldn't show up.
Really great video as always! I'm curious though...if the level is loaded left to right and level data is assumed to be organized left to right, what's the point of having an X coordinate in the object data? To me, it seems like it would make more sense to instead use that "next screen" flag bit as a "next column" flag instead (and maybe expand it to be two or three bits wide, allowing larger jumps as well). That way, when loading a column, the game would just load objects on the current column until that flag is set. The only problem I see with this is that the queue system wouldn't work for objects larger than one column, but I think that could be fixed by adding an "offset" byte to each item in the queue that starts at zero and is incremented by one every time a column is drawn to track progress on rendering it
It was the first time they used an object system like that. Zelda 2 would refine the system. Zelda 2 used something very similar, but instead of storing an X coordinate, they stored the difference between this object's X coordinate and the previous object's X coordinate. Then you don't need the "Next Page" flag anymore, so you can double the number of possible objects.
I think Super Mario Land 1 does something kinda like this. The level data is one byte per column, indexing into a list of columns (and each column is a list of tiles). I'm not sure though.
it still amazes me how they put this all together in a 32kb rom.
If you had ground in e-1 you would find random monochrome level tiles, and in w-1 if you could walk it would crash soon after. Plus in 62-1 if you could walk you would walkdown a hall way until you reached a wall and if you could walk through walls you would continue walking until the scrolling stops or the time runs out.
I've been waiting for this video, thank you :)
It's crazy to think that folks designed and built this game without an easy way to visualize this process.
Super interesting video! And the animations are amazing as always! (the one at 27:55 is bluffing)
What about upside down pipes, how are they encoded?
I assume that every pipe comes with a piranha plant, and the upside down pipes seem to come with upside down piranha plants, so they can't be too much of a hack?
All pipes come with a piranha plant for free, yes. Upside down pipes are exclusive to lost levels, which I haven't looked at (yet).
@@RGMechEx except for 1-1 through, that one is hardcoded to not contain piranhas.
Instead of changing the world value, what about the level value? Also the game genie has anti crash codes that don’t crash the game (which a game genie is the best way to play these worlds on real hardware)
I absolutely love these videos, its just so fascinating. Great voice to listen to, as well.
another incredible RGME video
ur vids are so relaxing bro, thanks.
idfk what you're talking about /lh but I like your voice and how passionate you are for this stuff
He shouldve shown the queue in the animation
I've been waiting forever for this, thanks!!!!!!!!!!!!!
I love this series so much! Thanks!!!
This is WILD. Grew up with this game and always thought the minus world was just crazy
It's really interesting (and makes perfect creepypasta material) how nobody intentionally created it. It just "exists." Granted, it exists because the level loading algorithm is interpreting stuff that isn't a level as though it were bona-fide level data, but still.
@@williamdrum9899 I would have loved to see the developers' reactions. People keep talking about a secret level, but you know there isn't one because you didn't put one in... wait, what's this!?