This is NES Super Mario Bros. 3, completed in 10:26.42 (37647 frames), an improvement of 1.6 seconds (96 frames) over the
previous run, and 3.1 seconds (186 frames) faster than the
alternate run which, like this run, acquired 99 extra lives magnificently™.
Goals
- As fast as possible
- Obtains 99 lives
- Emulator Used: FCEUX 2.0.4-interim, default settings
- Rom Used: Super Mario Bros. 3 (U) (PRG0) [!].nes
I first noticed the site three and a half years ago when I watched Genisto's run on archive.org. There was a link to the site where I read through the
Why and How section and lurked on the forums occasionally as well. I've always wanted to do a run on this game, but for a long time didn't know or suspect improvements. I had occasionally tried to TAS various parts of the game to no avail. Over the years as I got steadily better, I was able to question things more from a frame by frame point of view. Rather than just an ignorant viewers point of view. After the previous run had been published. I found a way to save a frame at the beginning of 8-1, and a 15 frame improvement in the first autoscroller by taking damage.
I knew based off one of Nitsuja's WIPS that 1-1 was improvable by 4 frames, but it wasn't enough to avoid increased hammer bros movement in the over world. I realised that Nitsuja hadn't taken advantage of the fall through block glitch at the beginning which is enough to save a frame. Unfortunately I had to sacrifice too many pixels in order to make it a bankable saving until...
Randil posted one of his WIPS on the forum. With his improved start it meant no pixels needed to be sacrificed to make the fall through glitch work and I was able to incorporate the improvement into the rest of the level. From earlier testing via Game Genie, I knew that it would add up to increased savings in later levels because less delays would be required to in order to get good hammer bros movement.
In the first autoscroller I stumbled on a way to fall through blocks at very low speeds. Unfortunately, I had great problems trying to replicate it and it caused the project to stall for a long time. Until Lord Tom mentioned on the forums that he had found a noticeable improvement in Bowser's Castle. He mentioned a clear desire to do a new run, he probably wasn't aware of the improvements I knew at the time so I decided to PM him and show him my current WIP. He was also able to fully unlock the logic behind the slow speed block glitch, because of this, not only could the first autoscroller be done quicker, it could also be done with more lives allowing us to hopefully of course, manage to get 99 lives magnificently™
Apart from a couple of other things. Everything else is mostly 1-2 frame improvements via greater precision. Detailed improvements are listed below. One thing I would like to note is that any future improvements will be problematic, mainly because you would need to be about 10+ frames faster in the first world in order to get the correct boomerang bros routine at the end of the first autoscroller.
Hope everyone likes the run :-)
P.S. In relation to the rom issue, I personally couldn't care less about whether PRG0 or PRG1 is used. I used PRG0 for consistency sake, as I prefer to use the orginally released rom across all games.
I first discovered this site in '07 when a forum on speeddemosarchive referenced something "the guys at nesvideos" had done. I'd only been following speed-running for a few months at the time, and being a technical person with modest console skills, I jumped right in.
Super Metroid, Zelda and (Genisto's) SMB3 run were among the 1st TAS' I watched. Being able to nudge SMB3 a step further towards perfection is a treat.
I first got interested in SMB3 after re-watching the published run one day and reading the author comments. Realizing that I had no idea what all the passing through walls was accomplishing, I looked at a map of Bowser's palace online. Being a lover of route-planning, I scanned for alternatives, and the route using the 1st door seemed promising. I was crushed for all of 2 minutes to discover there was a thwomp in the way which couldn't be killed by fireballs. Then I remembered the star... There were some other difficulties in figuring out the wall jump (described below), but I ended up confirming the new route was faster and being contacted by Mitjitsu (who more fully optimized the new route). Five months later, and here we are with a new submission!
It was definitely fun working on my first team-TAS. Mitjitsu has style and a sharp eye for stray frames, while I enjoy high level planning and teasing out the technical details behind glitches, so we complemented each other pretty well.
Thanks to the authors of the previously published runs for efforts that had me bursting out laughing at times, to Nitsuja and Randil for early work on an improvement, and to Carrie and Geoffy for being a supportive and indulgent audience.
World 1
As Mitjitsu alluded, obtaining "bankable" time savings can be very complicated in SMB3. This is because world 1 is a virtual minefield of de-facto mini-frame rules, due to the need to optimize overworld hammer brother movement, which is done by adjusting the frame on which levels are finished either by adding delays (easy) or finding improvements (hard). Carrying over world 1 savings into world 8 is further complicated by the need to manipulate the fastest movement pattern for the hammer brother at the end of the 1st tank autoscroller -- the fastest pattern is faster by about 15 frames, and only occurs every 10th frame or so.
Initially, we had saved 9 frames based on Mitjitsu's efforts, but found all those juicy frames wiped out by the need to wait 10 frames for the world 8 hammer. Some debugger work revealed that saving just *1* further frame in world 1 would yield the fastest pattern without waiting. Thankfully, we found a way to save 5 frames in the world 1 fortress, giving us a bankable world 1 savings (after all the math) of about 12 frames.
The improvement occurs toward the end of the fortress, when Mario runs and ducks underneath a spinning ball. We start sliding earlier, at higher speed, to get past the ball more quickly. Then, we jump at the last possible moment to get up the stairs. This is important, because the timer for P-speed running out doesn't start until you jump. Jumping later means that we keep P-speed right up until the door to the whistle, whereas the published run loses P-speed several frames before the door.
Getting 99 Lives
Being able to get 99 lives without losing time was made possible by 3 things: being able to glitch into blocks at less than p-speed, careful planning to avoid lag while maximizing lives gained, and discovering that it was possible to bounce on some cannonballs off the left side of the screen.
The falling into blocks at low speed only works in the auto-scrollers and makes use of their odd physics. Mario has different horizontal velocities while in the air depending on whether he jumped from the ground or from a moving platform/tank -- jumping from the ground makes Mario faster going right, and slower going left. This state is unchanged by bouncing on enemies. Hence, by jumping from the ground and bouncing off a cannon-ball. we're able to get into the platform at the end of the 1st autoscroller without p-speed, giving us more time earlier on to be magnificent™. We've performed this at speeds as low as 32 (max walking speed is 24, max running speed is 40, max p-speed is 56).
The published run breaks a sequence of 1-ups toward the end of the 1st autoscroller to float right and tail-flip a bomber that is off-screen to the right. Although we're not sure, it seems this must have been done to avoid lag, since it clearly reduces the number of 1-ups achieved without other obvious benefit. We found that changing up the stomping just beforehand, in particular killing one of the manhole dudes before he throws his wrench, avoided lag and allowed us to greatly extend the sequence of 1-ups.
Finally, we discovered that with very careful timing, it is possible to stomp cannon-balls that are fired just as the cannon goes off the left side of the screen. This increased the number of 1-ups both by adding additional targets and increasing flexibility in the stomping pattern.
Our target was to finish the 1st autoscroller with 92 lives, which would let us reach 99 just by getting the 7 lives obtained in the published run on subsequent levels, so we were very happy when we ended up with 94.
8-2
Mitjitsu chopped off a few more frames here with 2 discoveries. First, running down slopes does not increase Mario's speed as reported by memory addresses, but it *does* increase the speed Mario actually moves at; by 1/8 pixels/frame on a shallow slope, and 1/4 pixels/frame on steep slopes. Second was a new route past the bouncy music boxes which allows full speed to be maintained all the way through them.
Bowser's Fortress
Most of the time savings came from the new route, but we also saved 2 frames on Bowser.
Apart from using the star, the new route is made possible by using a low-speed wall-jump. A wall jump requires speed of no less than 33 (with perfect sub-pixel positioning, this is the lowest speed which enables Mario to embed himself far enough into the wall to jump off it before he is ejected). Unfortunately, after entering the 1st door in the palace, Mario falls down a narrow chute with only enough room to accelerate to speed 32. BUT, Lord Tom discovered (by accident) that about every 15th frame, some strange collision-detection thing happens which allows Mario to accelerate for 1 extra frame, thereby permitting a wall-jump without losing time walking left to make extra running room. So, when Mario falls, we push left to hit the wall with optimized subpixel placement, then wait for the correct frame to start accelerating right.
The Bowser fight is faster because, for reasons which are unclear, killing Bowser on certain frames causes the exit door to open faster or slower. So, delaying the final fire-ball a few frames actually ended up finishing the run 2 frames faster.
adelikat: The authors have provided a new submission file that includes commentary via subtitles. Enjoy!
Also, accepting for publication as an improvement to the published movie.
ShinyDoofy: Processing...
adelikat: Replacing the submission file (again). The authors used 4 score input which left null input for controller 3 & 4 for the entire movie. The new submsision file removes that extra data. The movie playback is unaffected by this, but the filesize is cut approximately in half.
