I really appreciate all the cool SMB3 glitches you show. One thought that keeps living rent-free in my brain is if there is a practical RTA glitch that would either break the extra rock or get runners an extra hammer so that there could be a true 100% SMB3 run. As most people know, it's impossible playing the game as intended to hit all mushroom houses because you need one more hammer than you can get. Might also be possible to just skip to the extra mushroom house (I don't know if the game would let you back out after that).
There actually is a glitch that lets you collect an extra hammer from hammer bros. It's unfortunately comically slow to perform, and RNG dependent, but here's a video showcasing that: ruclips.net/video/uD6OPCN1KAc/видео.html
@@100thCoin Thanks for the link. I had somehow missed that video. Like you said, it's an RNG-fest though so still not quite ripe for this kind of run idea.
My favourite of all your videos to date!!! I have always been intrigued as to why bowser's castle takes significantly more frames to generate compared to every other level in the game - I did my own research just a few months ago and read the level generation section, and was amazed how it always starts with the same pattern for "fortress" tilesets, wastes all that time drawing all those tiles and then removes them because barely any fortress used those tiles! (except for a few sections of checkerboard floor) The fixed and variable sized level generators was a really cool thing for the programmers to do! Makes sense though, such an efficient way to make each level, given only a handful of bytes are required to build a level. Even just watching Bowsers castle being generated frame by frame in the hex editor looked fascinating, but now you've made it completely visual too, so cool to watch! I've spent more time than I want to admit reading through all the disassembly, so I really enjoy it when you make videos like these. I was no joke thinking of a way to visualise Bowsers castle being generated only a few months ago, well, I guess you beat me! Although I had planned to put more emphasis on why this level in particular takes the most time to be generated. I also find it fascinating to note the difference between the level load function on the USA versions compared to the Japan version - the japanese version allows vblanks to occur throughout the level generation process, although all it runs is pretty much the sound engine... Whereas in the USA version, this little bit of code after the level entrance transition is completed is executed a few lines after PRG030_88AD - LDA #%00101000 ; use 8x16 sprites, sprites use Pattern Table 2 (NOTE: No VBlank trigger!) STA
The visualizations are top notch. It's so interesting to see how the sausage is made. Anyone as a kid would think level data is just grids of tiles, but oh no.
love the level generating sections! it would probably take forever to make, since i assume you're doing those sections by hand, but i would love to see a video of all the levels generating
Nah- I wrote a program to draw that stuff for me, ha! There's no way I would've done all that by hand. I might make a follow up video of generating all the main levels if people are interested.
@@100thCoin Did you use a standalone 6502 emulator to do this, or a whole nes emulator with lua scripts? I actually did the standalone emulator approach with the all-stars version with my editor, it's really fun to mess with.
@@Selicre It's a custom made 6502 emulator written in visual studio .Net forms. I just plug in map coordinates and the world number and it generates the level while putting an image in an output folder for each step it took to generate the level. (though a lot of it was toggleable. I could set it up use the actual level's width, or force a full 15 screens, only draw the finished result, only draw the tiles that were newly added to the image, etc. At one point, just to find the cooler glitch levels, I made it loop over every tile on the map for worlds 1 through 8. I still have that folder. It has 65536 images in it, and it's about 1.33 gigabytes! There's a whole lot of poorly labeled checkboxes and toggleable options that I only ever used once, ha!) It also outputs the PPU character information, and a "tilemap" which I used for the visuals around the 13 minute mark. 5-2 actually starts in a tiny room with a pipe, so to draw the second area, I take the information from $7DFE and the tileset that loading a level stores there, and I can use that to generate the second part of the level as well. Generating the level mario enters after ascending in the toad house was trickier. I set it up so I can just paste a series of bytes into RAM at a specific address, then plug in the tileset and address to begin interpreting level data. It was a really fun project, and I'm glad I got to use it for this video!
0:01 - The pipe glitch is probably crying in the corner after hearing that pink note blocks are more exploitable. 0:35 - Obviously Mario doesn't need the whistle to go to a far away land. 2:17 - This flowchart is very nice to see. An excellent way to visualize it. 4:30 - It's always a table that makes everything break, isn't it? 8:52 - This is so sad. 11:25 - I'm kind of surprised bouncing on the note blocks here doesn't crash the game at all.
> It's always a table... With my videos, yeah. I'm actively seeking which jump tables could be exploited, as it is certainly an effective method to crashing the game or executing in RAM. > kind of surprised bouncing on the note blocks here doesn't crash the game... All of these are mapped to the level data in RAM, so nothing goes wrong when bumping them. The out of bounds noteblocks can crash the game if they are pointing to ROM, as writing to certain places in ROM can cause Memory Mapper functions to occur, such as swapping PRG banks. In the case of the 7-1 noteblock, it swaps the positions of the bank it was reading and bank 30, and after a series of RTS instructions the stack underflows, which leads to pulling off unrelated bytes from $100 and $101 as if they were a return address. Unless you manipulate the bytes wherever it "returned" to, it's most likely going to crash the game.
As a quick refresher, the IRQ happens 192 scanlines after the screen starts being drawn. It causes an interrupt, so the game will stop whatever code it was reading temporarily to execute a short routine used for updating graphics so the HUD can utilize different characters, and also update the position / scroll. The toad houses have a specific branch in the IRQ routine (Tileset $07 uses the branch, to be more specific. The map and roulette houses use this branch too.). It doesn't have the step where it adjusts vertical scroll, so scrolling the screen upwards will move the HUD off screen. This looks funky, since it swaps the graphics and horizontal scroll, but the vertical scroll remains unchanged. In summary, toad houses shouldn't scroll upwards, so the developers never bothered to make the HUD remain in one place vertically. But they needed to give the map / toad houses a specific branch in the IRQ since this is where the hud can flip around to the pink side to showcase items you've collected. That's also why the HUD isn't broken in the other glitch levels showcased.
> Refresher Man, I've been skipping lecture :/ Interesting stuff. Would that be the same branch as used by the map screens? Another question, if you don't mind: is the area data in its entirety decompressed to cartridge RAM? Is collision data part of that? I'm looking at an ASCII Toad House at $60F0 right now so it seems like it!
@@warmCabin Correct, the level's tile data is from $6000 through $794F. The "collision data" is a bit of a vague wording... The tiles at $6000 aren't just visual. If you hex edit those then you can interact with any changes you make. The bytes at $7E94-$7E9B determine which tiles are solid or not.
Sorry to be a bit Doo-Doo Brained, but is this possible without any code ejection? Ya know, like without doing any complex setups for your console and all that?
Everything showcased in the video was demonstrated through hex editing, though it could be done without it. It would just require a bunch of arbitrary code execution in 7-1, and some other shenanigans to get the game in such a state where this can be done.
In the logic for any 4-byte object, there's code to specifically load the next byte and update the pointer. If you were to edit the code, you could create a custom object with as many bytes as you want by simply reading the next byte and updating the pointer over and over again.
Very high quality
@kramsdell_ ok mr smarty pants
2nd reply!
wow
It's interesting how 2-1 draws a grid of pipes and then overwrites parts of it to create the level pattern.
I definitely wanted to show 2-1 being generated. it caught me by surprise!
I really appreciate all the cool SMB3 glitches you show. One thought that keeps living rent-free in my brain is if there is a practical RTA glitch that would either break the extra rock or get runners an extra hammer so that there could be a true 100% SMB3 run. As most people know, it's impossible playing the game as intended to hit all mushroom houses because you need one more hammer than you can get. Might also be possible to just skip to the extra mushroom house (I don't know if the game would let you back out after that).
There actually is a glitch that lets you collect an extra hammer from hammer bros. It's unfortunately comically slow to perform, and RNG dependent, but here's a video showcasing that: ruclips.net/video/uD6OPCN1KAc/видео.html
@@100thCoin Thanks for the link. I had somehow missed that video. Like you said, it's an RNG-fest though so still not quite ripe for this kind of run idea.
Thank you algorithm for recommending me this channel! Instant sub.
My favourite of all your videos to date!!! I have always been intrigued as to why bowser's castle takes significantly more frames to generate compared to every other level in the game - I did my own research just a few months ago and read the level generation section, and was amazed how it always starts with the same pattern for "fortress" tilesets, wastes all that time drawing all those tiles and then removes them because barely any fortress used those tiles! (except for a few sections of checkerboard floor)
The fixed and variable sized level generators was a really cool thing for the programmers to do! Makes sense though, such an efficient way to make each level, given only a handful of bytes are required to build a level. Even just watching Bowsers castle being generated frame by frame in the hex editor looked fascinating, but now you've made it completely visual too, so cool to watch!
I've spent more time than I want to admit reading through all the disassembly, so I really enjoy it when you make videos like these.
I was no joke thinking of a way to visualise Bowsers castle being generated only a few months ago, well, I guess you beat me! Although I had planned to put more emphasis on why this level in particular takes the most time to be generated.
I also find it fascinating to note the difference between the level load function on the USA versions compared to the Japan version - the japanese version allows vblanks to occur throughout the level generation process, although all it runs is pretty much the sound engine... Whereas in the USA version, this little bit of code after the level entrance transition is completed is executed a few lines after PRG030_88AD -
LDA #%00101000 ; use 8x16 sprites, sprites use Pattern Table 2 (NOTE: No VBlank trigger!)
STA
Let's be real, 100th coin is the Pannenkoek of SMB3
The visualizations are top notch. It's so interesting to see how the sausage is made. Anyone as a kid would think level data is just grids of tiles, but oh no.
Yeah, I never suspected SM3 was *still* using scripted construction.
I suppose arbitrary data compression would be too slow?
@@musaran2 It can be done (see pokemon gen 1) but it has its own set of tradeoffs and clearly this was good enough for what they needed at the time.
Your videos are so consistently high quality, I love it. The visuals really help with understanding your explanations.
5:52 - that's one majestic way to complete the game...
all of the visualisations are very good and makes this infinitely easier to understand, great video
Another great video! Love your visuals and explanations!
love the level generating sections! it would probably take forever to make, since i assume you're doing those sections by hand, but i would love to see a video of all the levels generating
he's probably using a script to read the level data and visualize it as a video but i could be wrong
Nah- I wrote a program to draw that stuff for me, ha! There's no way I would've done all that by hand. I might make a follow up video of generating all the main levels if people are interested.
@@100thCoin Did you use a standalone 6502 emulator to do this, or a whole nes emulator with lua scripts? I actually did the standalone emulator approach with the all-stars version with my editor, it's really fun to mess with.
@@Selicre It's a custom made 6502 emulator written in visual studio .Net forms. I just plug in map coordinates and the world number and it generates the level while putting an image in an output folder for each step it took to generate the level. (though a lot of it was toggleable. I could set it up use the actual level's width, or force a full 15 screens, only draw the finished result, only draw the tiles that were newly added to the image, etc. At one point, just to find the cooler glitch levels, I made it loop over every tile on the map for worlds 1 through 8. I still have that folder. It has 65536 images in it, and it's about 1.33 gigabytes! There's a whole lot of poorly labeled checkboxes and toggleable options that I only ever used once, ha!) It also outputs the PPU character information, and a "tilemap" which I used for the visuals around the 13 minute mark.
5-2 actually starts in a tiny room with a pipe, so to draw the second area, I take the information from $7DFE and the tileset that loading a level stores there, and I can use that to generate the second part of the level as well. Generating the level mario enters after ascending in the toad house was trickier. I set it up so I can just paste a series of bytes into RAM at a specific address, then plug in the tileset and address to begin interpreting level data. It was a really fun project, and I'm glad I got to use it for this video!
0:01 - The pipe glitch is probably crying in the corner after hearing that pink note blocks are more exploitable.
0:35 - Obviously Mario doesn't need the whistle to go to a far away land.
2:17 - This flowchart is very nice to see. An excellent way to visualize it.
4:30 - It's always a table that makes everything break, isn't it?
8:52 - This is so sad.
11:25 - I'm kind of surprised bouncing on the note blocks here doesn't crash the game at all.
> It's always a table...
With my videos, yeah. I'm actively seeking which jump tables could be exploited, as it is certainly an effective method to crashing the game or executing in RAM.
> kind of surprised bouncing on the note blocks here doesn't crash the game...
All of these are mapped to the level data in RAM, so nothing goes wrong when bumping them. The out of bounds noteblocks can crash the game if they are pointing to ROM, as writing to certain places in ROM can cause Memory Mapper functions to occur, such as swapping PRG banks. In the case of the 7-1 noteblock, it swaps the positions of the bank it was reading and bank 30, and after a series of RTS instructions the stack underflows, which leads to pulling off unrelated bytes from $100 and $101 as if they were a return address. Unless you manipulate the bytes wherever it "returned" to, it's most likely going to crash the game.
amazing what you can do with this game, great video
hey there I came across youre super little channel here and wanted to show my support, great content keep it up ✌😎
damn this guy has the visuals
the fact that the game has 'tiles' that delete tiles is very intresting
Very well made and easy to understand
a 15 minute video from 100th coin? LETS GOOOOO
(0:33) - "One hop on the pink noteblock will send you to a far away land!"
- Toad
That's one way to enter a glitch level in Toad's house.
This is awesome! So, why is the status bar scroll split always all screwy in these glitch levels?
As a quick refresher, the IRQ happens 192 scanlines after the screen starts being drawn. It causes an interrupt, so the game will stop whatever code it was reading temporarily to execute a short routine used for updating graphics so the HUD can utilize different characters, and also update the position / scroll.
The toad houses have a specific branch in the IRQ routine (Tileset $07 uses the branch, to be more specific. The map and roulette houses use this branch too.). It doesn't have the step where it adjusts vertical scroll, so scrolling the screen upwards will move the HUD off screen. This looks funky, since it swaps the graphics and horizontal scroll, but the vertical scroll remains unchanged.
In summary, toad houses shouldn't scroll upwards, so the developers never bothered to make the HUD remain in one place vertically. But they needed to give the map / toad houses a specific branch in the IRQ since this is where the hud can flip around to the pink side to showcase items you've collected.
That's also why the HUD isn't broken in the other glitch levels showcased.
> Refresher
Man, I've been skipping lecture :/
Interesting stuff. Would that be the same branch as used by the map screens?
Another question, if you don't mind: is the area data in its entirety decompressed to cartridge RAM? Is collision data part of that? I'm looking at an ASCII Toad House at $60F0 right now so it seems like it!
@@warmCabin Correct, the level's tile data is from $6000 through $794F. The "collision data" is a bit of a vague wording... The tiles at $6000 aren't just visual. If you hex edit those then you can interact with any changes you make. The bytes at $7E94-$7E9B determine which tiles are solid or not.
highly underrated
very nice video and explanations.
Super Mario Bros but it's a mod where you can make your own level using your own tileset, then it will tas that LMAO
Sorry to be a bit Doo-Doo Brained, but is this possible without any code ejection? Ya know, like without doing any complex setups for your console and all that?
Everything showcased in the video was demonstrated through hex editing, though it could be done without it. It would just require a bunch of arbitrary code execution in 7-1, and some other shenanigans to get the game in such a state where this can be done.
Your videos are awesome! :D
This Definitely one of the most underrated video I have ever seen.
I wish I could edit this cool
YOOO YOU'RE BACK!?
Glitch levels in SMB1 are sooooooooooo much more interesting due to the way that game works.
What about for generating the subworld in levels?
I LOVE YOU SONIC!!
how does the game know whether or not an object is 4 bytes?
In the logic for any 4-byte object, there's code to specifically load the next byte and update the pointer.
If you were to edit the code, you could create a custom object with as many bytes as you want by simply reading the next byte and updating the pointer over and over again.
tysm
Surely a faraway land
Enjoyed
1 minute in and i already don't understand
no entendi un carajo pero buen video