To enable frame by frame with the < and > keys, this is a way to make it work: After changing quality to 60fps, start the video from the start, then immediately press k to pause the video. Then, use < and > to navigate the frames. They should now all be there! For some reason, if you go right back to the start using the nav bar, it goes to 30 fps when navigating frame by frame. Weird! If it goes back to 30fps frame by frame, just hit k twice to rapidly play and pause the video, then you can use < and > for 60 fps navigation again. Hope this helps!
Going frame-by-frame with the , and . keys, some frames seem to be missing here, like the frame where the bottommost row of controller inputs is highlighted.
UA-cam is probably still processing the video. I accidentally copied the files twice when editing the video together and never noticed until after uploading (ha!), so I'm using youtube's video editing utilities to crop the second half of the video out. It's going to be processing for a while, but rest assured, the video was exported with each frame included.
To enable frame by frame with the < and > keys, this is a way to make it work: After changing to 60fps, start the video from the start, then immidiately press k to pause the video. Then, use < and > to navigate the frames. They should now all be there! For some reason, if you go right back to the start, it goes to 30 fps when navigating frame by frame. Weird! If it goes back to 30fps frame by frame, just hit k twice to rapidly play and pause the video, then you can use < and > for 60 fps navigation again. Hope this helps!
Well, the first ten frames are impossible to work with as the controllers aren't read until frame 11. That leaves a total of 3 frames with inputs. It would be incredibly bold to say "This will never be beat", but bear with me... To prevent the credits from crashing, there are 3 major requirements for this run. The NMI mode needs to be set to 0x20, the stack pointer needs to be anything greater than 0x20, and I need to jump to $B85A. If you are trying to beat this run, then you only have two frames to achieve all of these things. But let's take a look at how my run does that in 3. Frame 1 sets up a jump to $9000 (which sets the NMI mode and jumps to $B85A). Keep in mind, we can't take this jump on frame 1, but that's a good thing because we still need to fix the stack pointer. If you want to beat my TAS, you need to fix the stack pointer on this frame, and still execute the jump we previously wrote, which is stored at $0000. You could try writing a branch, which would let you execute $F5 through $F8 on this frame, but that would just read another branch as you can't change inputs mid-frame. That means, for the second frame of the run, you only have access to two consecutive bytes that will hold the same value. No set of matching Opcodes and Operands could fix the stack pointer and still manage to make the jump written at $0000. Perhaps there's another solution I haven't thought of yet, but there's so little to work with that this might just be the most optimal TAS for the "game end glitch" category that's possible.
@@100thCoin I'm going to be honest with you, I have no idea what 80% of that meant, so I'm just going to assume you know what you're talking about and the odds of improvement are very slim.
@@pineapplewhatever5906 I wrote a program to brute force it already. None of the 8 million or so runs complete the game. Assuming the program I wrote was perfectly accurate, the game cannot be completed in 2 frames.
Holy moly. 3 frames from first input. It's sort of amazing how you get to use the NMI's temp zp stores in this way, endianness and pre-cleared memory does half the work! (just kidding) I like how this run builds a ladder, barges into the $8FF4 tavern through the upstairs window at $9000, adjusts the barkeep's PPU necktie unnecessarily, turns on the jukebox to track 32, refuses to elaborate, and leaves through the front door to pick up its prom date princess who wouldn't go with it unless the right music was playing. I see from other comments that you've bruteforced all button combinations in frames 11 and 12 and had no luck, making this probably the fastest you can go. Truly exceptional. My question is, if the ROM was exactly the same *except* the left/right up/down masking wasn't there, would there be a faster way?
I honestly don't think removing the conflicting d-pad inputs could make this run faster. I don't know what else I would write to speed this up. Part of what made brute forcing this so easy was that frame 12 can't utilize controller 2. Perhaps if I didn't need to worry about the conflicting d-pad inputs, and I also didn't have to worry about the bits in the new input being contained within the held inputs, then I could write a branch to $F5, and use that area to fix the stack pointer and simultaneously jump to $0000, thus jumping to $9000, but that also assumes I could magically change what controller 1 is pressing mid-execution in this hypothetical that is already well beyond possible. A lot would need to be changed for this run to be any faster.
Don't forget the part where you need to press 100 non-matching subframe inputs for the first frame, and then delay the second frame's inputs by a single controller read.
The subframe stalling was discovered by ais523, so I can't vouch for how that was discovered. As for creating this run, I've been tearing this game apart for a few years now, so I'm very familiar with the code, regardless of the version. I noticed that this version in particular has the code used to initialize the princess's chamber at an easier place to jump to than other versions, and so with that knowledge I looked into finding the fastest way to create such a jump. It's a huge series of trying new things until something sticks, but you can't just try random moves; Every attempt at discovering something new is from an educated guess at what would happen, all with the goal of finding a new exploit.
ha! Not a chance. I like to bring up the statistics on this one. This requires pressing different inputs every 225 CPU cycles. That's a new input every 0.000126 seconds. In my run, I mash the A button a 8 kilohertz. On top of this, you need to be extremely precise with how fast you press buttons, and what buttons you press at what moment. This is as far from RTA viable as it gets.
@@100thCoin I'm guessing those controller inputs won't even get recorded when using a normal NES controller, yes ? Oh well, so far for those folks who did this in their childhood
@@pearlschild Actually it would work on a normal controller, but it's still impossible for a person to press buttons at such a rate. Perhaps the buttons physically being pressed and released in such a short amount of time wouldn't be possible, I don't know. This run has been console verified using modded controllers though. They work in the same way as a normal controller, but every time the controller is polled it sends in the next input from the TAS. Here's the console verification if you're interested: ua-cam.com/video/JyHB1BGgD8I/v-deo.html
Nope. The first ten frames don't even read the controllers, so the best possible run would be 0.183 seconds. However, I just finished brute forcing every combination of inputs for the first two frames, and none of those were able to win the game, so this run might just be the fastest possible, assuming changing to another version doesn't somehow allow for another frame to be taken off.
![Super Mario Bros. 3: [TAS] "Game End Glitch" in 00:00.316](http://i.ytimg.com/vi/DK0PgI5dt2A/mqdefault.jpg)
![Super Mario Bros. 3: [TAS] "Game End Glitch" in 00:00.316](/img/tr.png)
There we go, last one was a little slow
Yeah, that's what half the comments were saying :P
How about 0 seconds
"slow"
little did he know, that this one was actually very very slow
they simply cannot keep getting away with this
End credits: the game
that TAS could simply be renamed as "SMB3 credits FULL"
Amazing work to get the timing down to near instant!
Now you'll literally miss it if you blink, insanity!
Damn this is a pretty good retro short film
To enable frame by frame with the < and > keys, this is a way to make it work: After changing quality to 60fps, start the video from the start, then immediately press k to pause the video. Then, use < and > to navigate the frames. They should now all be there!
For some reason, if you go right back to the start using the nav bar, it goes to 30 fps when navigating frame by frame. Weird!
If it goes back to 30fps frame by frame, just hit k twice to rapidly play and pause the video, then you can use < and > for 60 fps navigation again.
Hope this helps!
not the < and >, but the , and .
The Konami code ain't got shit on these inputs
Going frame-by-frame with the , and . keys, some frames seem to be missing here, like the frame where the bottommost row of controller inputs is highlighted.
UA-cam is probably still processing the video. I accidentally copied the files twice when editing the video together and never noticed until after uploading (ha!), so I'm using youtube's video editing utilities to crop the second half of the video out. It's going to be processing for a while, but rest assured, the video was exported with each frame included.
Try setting it to 60FPS, you'll get a few more frames (but not all of them).
To enable frame by frame with the < and > keys, this is a way to make it work: After changing to 60fps, start the video from the start, then immidiately press k to pause the video. Then, use < and > to navigate the frames. They should now all be there!
For some reason, if you go right back to the start, it goes to 30 fps when navigating frame by frame. Weird!
If it goes back to 30fps frame by frame, just hit k twice to rapidly play and pause the video, then you can use < and > for 60 fps navigation again.
Hope this helps!
@@100thCoin ironic you doubled the video since input doubling shenanigans was how this started
eh, I'll finish this tomorrow.
This is insane
Had to watch the video in the beginning a couple of times to find out what was going on
epic gameplay, very enjoyable
Please make a video explaining this
I plan to, but it's going to be a while. There's a lot to explain, especially if I want a general audience to follow along.
this video is 99.9% credits lol
I didn't know what to expect when I clicked on this video from Reddit. I was very confused at first.
Incredible work!
TIL this is the shortest movie on all of tasvideos
Toadstool: H-
Mario: I'm here.
I clicked the video and I got an ad that was 30 times longer than the run.
you are a genius how do you keep doing this
Wanna see me do it again?
peach: 助ｋ…
mario:
Nice speedrun
This speedrun will never be beaten.
Amazing. Any chance more frames will be saved?
Well, the first ten frames are impossible to work with as the controllers aren't read until frame 11. That leaves a total of 3 frames with inputs.
It would be incredibly bold to say "This will never be beat", but bear with me...
To prevent the credits from crashing, there are 3 major requirements for this run. The NMI mode needs to be set to 0x20, the stack pointer needs to be anything greater than 0x20, and I need to jump to $B85A.
If you are trying to beat this run, then you only have two frames to achieve all of these things. But let's take a look at how my run does that in 3.
Frame 1 sets up a jump to $9000 (which sets the NMI mode and jumps to $B85A). Keep in mind, we can't take this jump on frame 1, but that's a good thing because we still need to fix the stack pointer.
If you want to beat my TAS, you need to fix the stack pointer on this frame, and still execute the jump we previously wrote, which is stored at $0000. You could try writing a branch, which would let you execute $F5 through $F8 on this frame, but that would just read another branch as you can't change inputs mid-frame.
That means, for the second frame of the run, you only have access to two consecutive bytes that will hold the same value. No set of matching Opcodes and Operands could fix the stack pointer and still manage to make the jump written at $0000.
Perhaps there's another solution I haven't thought of yet, but there's so little to work with that this might just be the most optimal TAS for the "game end glitch" category that's possible.
@@100thCoin I'm going to be honest with you, I have no idea what 80% of that meant, so I'm just going to assume you know what you're talking about and the odds of improvement are very slim.
@@100thCoin This will never be beat
Mario 3 is maxxed.
How hard is it to try all possible combinations of inputs on two frames?
@@pineapplewhatever5906 I wrote a program to brute force it already. None of the 8 million or so runs complete the game. Assuming the program I wrote was perfectly accurate, the game cannot be completed in 2 frames.
Holy moly. 3 frames from first input. It's sort of amazing how you get to use the NMI's temp zp stores in this way, endianness and pre-cleared memory does half the work! (just kidding)
I like how this run builds a ladder, barges into the $8FF4 tavern through the upstairs window at $9000, adjusts the barkeep's PPU necktie unnecessarily, turns on the jukebox to track 32, refuses to elaborate, and leaves through the front door to pick up its prom date princess who wouldn't go with it unless the right music was playing.
I see from other comments that you've bruteforced all button combinations in frames 11 and 12 and had no luck, making this probably the fastest you can go. Truly exceptional.
My question is, if the ROM was exactly the same *except* the left/right up/down masking wasn't there, would there be a faster way?
I honestly don't think removing the conflicting d-pad inputs could make this run faster. I don't know what else I would write to speed this up. Part of what made brute forcing this so easy was that frame 12 can't utilize controller 2. Perhaps if I didn't need to worry about the conflicting d-pad inputs, and I also didn't have to worry about the bits in the new input being contained within the held inputs, then I could write a branch to $F5, and use that area to fix the stack pointer and simultaneously jump to $0000, thus jumping to $9000, but that also assumes I could magically change what controller 1 is pressing mid-execution in this hypothetical that is already well beyond possible. A lot would need to be changed for this run to be any faster.
@@100thCoin Thanks for giving it a think :) You've got a bunch of awesome videos mate, can't wait to see what you cook up next!
13. This game has been destroyed in 13 frames. Amazing!
Bowser : I-
Mario : h̸̸̴̸̴̡͎͙͕̻̻͚̺̞̟̻̦̺͚̓̓͆͑͛̓̔̀̈́̕̚͘̕͠͝e̵̸̴̵̵̢̢̢̡͕̘͉̺͕̟̻̞͇͚̫̔̽̓̈́͊̒̐͐͌͛̒̈́͝l̴̴̵̵̸̺̼̫͖̼͚͕̪͔̠͖̟̙̓̈́̒̽̐̽̓͛͛̕̚͜͝͝l̴̴̸̸̸̡̡͖̦̦͕̟̝͕͚͚̼̓͒͑͛͊͋̓͛̿͌͜͠͝͠͝o̸̴̴̸̵̡̻͓͍̞̼̝͖͖̘̘̙̻̐͊͐̒͛͊͐̈́͛͑̕̚͠͝ m̸̵̴̸̴̢̼̫̙̟̠̝͕̙̺̟͖̫͖̈́̐͒͌̒̈́̀͌͛̕͘͘͜͠͝o̸̵̴̵̵̢̡̦̻̠̫̘̻̘̻̘̟̫͓̿͒͐͋̓̐̈́͑̓̔͌̀̕͘͝r̸̸̵̸̴̠͖̞̻̝̘̻̦͇̪̞̘̼̔́̈́̐̓͑͋̔͑͑͘̚͝͝t̴̸̴̵̵̢̡̙̟̞͇̪͕̼͖̫͎͍͔̝͊̈́̒͋̀̈́͋̔͑̀́̚͝͝a̵̵̸̴̴̡̢͍̫͚̟͖̠͚̟͖̼͉̺͊̾́͊͋̿͛̽͒̔̽͜͠͠͝l̸̵̴̴̸̡̟͔̙̼͇̟̘͙͚͇̠̼͐͑͒̈́͋͐͊͑̿̓̕̕̕͜͠
W
gonna try this RTA, frame perfect inputs on 2 controllers probably not too hard
Don't forget the part where you need to press 100 non-matching subframe inputs for the first frame, and then delay the second frame's inputs by a single controller read.
@@100thCoin trivial enough
i told you guys
how do you even end up discovering a glitch like this?
The subframe stalling was discovered by ais523, so I can't vouch for how that was discovered. As for creating this run, I've been tearing this game apart for a few years now, so I'm very familiar with the code, regardless of the version. I noticed that this version in particular has the code used to initialize the princess's chamber at an easier place to jump to than other versions, and so with that knowledge I looked into finding the fastest way to create such a jump. It's a huge series of trying new things until something sticks, but you can't just try random moves; Every attempt at discovering something new is from an educated guess at what would happen, all with the goal of finding a new exploit.
pog
dont blink
Nice, Are you trying to brute force inputs to improve this now?
I'm not trying to brute force this, no. It would be pretty easy to brute force though.
Update: I brute forced it and was unable to find a faster run that still wins the game.
@@100thCoin FC, NA 1.0, NA 1.1, PAL & or GBA
@@nekogirlsr I only brute forced it on FC 1.0
@@100thCoin How would I do it? I'd like to try it at some point.
If by any chance, would this be doable in RTA?
Just asking so that I can check everyone who apparently "did this by accident back when they were kids"
ha! Not a chance. I like to bring up the statistics on this one. This requires pressing different inputs every 225 CPU cycles. That's a new input every 0.000126 seconds. In my run, I mash the A button a 8 kilohertz. On top of this, you need to be extremely precise with how fast you press buttons, and what buttons you press at what moment. This is as far from RTA viable as it gets.
@@100thCoin I'm guessing those controller inputs won't even get recorded when using a normal NES controller, yes ?
Oh well, so far for those folks who did this in their childhood
@@pearlschild Actually it would work on a normal controller, but it's still impossible for a person to press buttons at such a rate. Perhaps the buttons physically being pressed and released in such a short amount of time wouldn't be possible, I don't know. This run has been console verified using modded controllers though. They work in the same way as a normal controller, but every time the controller is polled it sends in the next input from the TAS.
Here's the console verification if you're interested: ua-cam.com/video/JyHB1BGgD8I/v-deo.html
@@100thCoin throw the controller at the ground ez just got it
@@Falkite No, pour water on the controller as the game boots up
Oops, I blinked and missed it.
Can we get it down to 116?
Nope. The first ten frames don't even read the controllers, so the best possible run would be 0.183 seconds. However, I just finished brute forcing every combination of inputs for the first two frames, and none of those were able to win the game, so this run might just be the fastest possible, assuming changing to another version doesn't somehow allow for another frame to be taken off.
@@100thCoin *boo-womp* :(
Its scientifically impossible to beat the game in less frames than this.
Which makes me wonder, could it be beaten in less CPU cycles?
This is a pretty good run. You need to be lucky and hope you get Imposter so you can just vent straight into Bowser's Dungeon. Takes a lot of resets.
And I thought 00:00.80085 was fast
No
WTF????????
DEAL WITH IT
Wtf
W
W