(Link to video)
Submission Text Full Submission Page Publication Page
This site was founded when a certain Super Mario Bros. 3 TAS was discovered on the internet. Ever since then, the job of this site was to push video games to their very limits.
Today, almost 16 years later, it is possible to submit a Super Mario Bros. 3 TAS which might be the very embodiment of a video game being pushed to the limit.
Table of contents

Game objectives

  • Aims to complete the game as fast as possible
  • Exploits a workaround to a hardware bug
  • Presses buttons real fast (requires SubNESHawk core to be enabled for even faster button pressing!)

Comments

You might have seen a similar short SMB3 run in the TAS block at SGDQ 2016, or maybe you've read some of the many articles on the internet which followed the showcase.
It is important to note that, despite dwangoAC saying "it is a valid completion" in the video, it was in fact not a valid completion of the game. The showcased run enters the peach cutscene and then softlocks when the world cutscenes were supposed to appear. This was due to the game being in the wrong mode.
The method to make the real ending appear and complete the game is as simple as changing the (NMI-)game mode at $0100 to the correct value 0x20 before jumping to the credits. What is not as simple to see is how much trouble this one address is, taking months of work just to accomplish this one additional write.

How it came to be 

2016-07-07
<ais523>    Masterjun: that said, my default is to assume that any game
            has an ACE glitch unless it's very simple, and possibly even then
<Masterjun> I'm guessing the same for at least the SNES games
<Masterjun> and I'm betting a lot of NES games also have some kind of major
            glitch that simply wasn't discovered yet
<Masterjun> I'm thinking about those bank switches and exact instruction timings
<ais523>    this reminds me, I found a technique to create precise amounts of lag
            on the majority of NES games
))

DPCM bug

"If the DMC DMA is running, and happens to start a read in the same cycle that the CPU is trying to read from $4016 or $4017, the values read will become invalid." (full explanation)
This is a bug in the hardware of a NES console itself. In simple terms, it refers to audio processing occasionally interfering with input polling, leading to wrong button presses being read by the game.

DPCM bug workaround

It seems like developers of games for the NES were aware of this hardware bug. To avoid wrong button presses, they had to implement a software workaround. This can be approached in different ways or simply ignored.
In SMB3 specifically, developers programmed the game to repeatedly repoll the controller until two consecutive inputs matched. This means in normal play you usually repeat 2 loops (no bug occuring), or maybe 3 or 4 loops (bug occuring once) until you have two inputs matching.
An extra loop only takes 222 cycles (124 microseconds) of the ~30000 cycles in a frame, and it's unlikely that a human changes input 8000 times a second.

DPCM bug workaround exploit

Now this is TASVideos: When human skills are just not enough. So of course we can mash buttons really fast. This is what ais523 meant when talking about creating precise amounts of lag. By continuously changing inputs we can delay the game because it keeps waiting until two consecutive inputs match.
For convenience, the game has the controller reading routine inside the NMI, which is the interrupt that runs at the start of each frame. As soon as it begins we delay the execution by changing the input each loop. Important to notice here is how NMI switches to different banks at the start, and would switch them back at the end. Eventually the NMI is interrupted by IRQ, a different interrupt which is set to run at scanline 192 or 193 (= late in the frame). IRQ expects the NMI to have finished long ago and jumps to $A826. Unfortunately for the game, NMI did not yet finish and the banks are still switched. So it jumps into the middle of a wrong routine. A lot of crazy things happen (such as interrupts interrupting each other), and they keep getting more out of control because of IRQ trying to execute on wrong banks.
Until at some point the very unlikely scenario happens where a leftover byte from an indirect $9Axx jump is executed. Instruction 0x9A is TXS, Transfer X to Stack Pointer. Here, X happens to be 0x00, so the Stack Pointer (innitially 0xFF and in normal execution 0xC0-0xFF) is suddenly 0x00 and after a return it's 0x02. The Stack Pointer points to memory values $01xx, so after another BRK we will overwrite $0100 (= NMI mode) and $0101 (= IRQ mode). They change into "default mode" where IRQ finally doesn't jump into different banks. So we're now at the start of RAM filled mostly with 00's we can safely execute.
This is where the adventure begins.

The goal

We want to reach the peach cutscene and then the credits. This has 6 requirements.
  1. The $C000 bank needs to be 0x19
  2. The $A000 bank needs to be 0x18
  3. The PPU control register copy ($00FF) needs to be 0xA8
  4. NMI mode ($0100) needs to be set to 0x20
  5. Jump to $B85A
  6. The Stack Pointer needs to be sane (not lower than around 0x30), so it doesn't overwrite game modes.
At first, this seems too ambitious to be feasible. However, the first 3 requirements are already met and req. 6 works out automatically in most cases.
We can choose from two different approaches: First approach, set NMI mode (req. 4) and jump to credits (req. 5) manually. Or second approach, jump to a location which does it for us. But does such a convenient location exist? Yes, $8FE3 is what the game executes to prepare for the end sequence. There, the first 5 requirements are executed.
So we can either:
1. Set $0100 to 0x20 and jump to $B85A.
2. Jump to $8FE3.

The tools

What makes this whole movie possible in the first place are the bytes of controller input stored in RAM. We have two controllers with 8 buttons each. In order from most to least significant bit the buttons go: A B Select Start Up Down Left Right. In addition to currently pressed input bytes, we also have newly pressed input bytes (those are always a subset of the currently pressed bits). In particular $17 is P1 input, $18 is P1 new input. Then, $F5 is P1 new input, $F6 is P2 new input, $F7 is P1 input, $F8 is P2 input.
That's barely enough to do anything, and it gets even worse: Up+Down and Left+Right presses are cancelled out. This makes building bytes that end on x3,x7,xB,xC,xD,xE, or xF impossible, limiting our choice of opcodes.
As a first example, let's construct a jump to $B85A. There are three jump instructions: JSR(0x20), JMP(0x4C), indirect JMP(0x6C). As you can see, the JMP's are already impossible as they end on xC (= requiring an Up+Down press). So let's construct 20 5A B8. None of the bytes require opposite directional inputs, so that's good. Since two bytes are not enough, we have to use the second block of inputs. It doesn't really matter if we start at $F5 or $F6, but the important part to notice is how the 0x20 and 0xB8 are made with the same input. For this to be possible, all bits in the first byte need to occur in the second byte, which is the case here! This is exactly what the showcased run did, but unfortunately without setting $0100 (req. 4).
Now the second example, let's do the same thing except we jump to $8FE3. This gives us 20 E3 8F, which is impossible because 0xE3 ends on x3 and 0x8F ends on xF. It's also impossible because 0x8F doesn't have the required 0x20 bit.

The loop

Executing anything just once is not enough. We need a loop to be able to either set $0100, or somehow get that $8FE3 jump. Thankfully we have two areas of inputs to work with. We can use the 4-byte block as a loop back by executing 20 00 00, jumping back to the beginning of RAM. Then we can lag the game enough to get new inputs, execute something at the 2-byte block, execute until the 4-byte block, and loop back again.
It's at this point where it's possible to take a million approaches and have a million problems.

The problems

Just as an example, here is the list of some things that can go wrong:
  • Every BRK(0x00) instruction we execute is a 2 byte opcode, so we need to be careful how we're aligned, either executing even or odd addresses as opcodes.
  • The 3 byte opcode 0x1E sitting at $16, skipping the execution of your $17/$18 completely.
  • The counter at $15 counting upwards through all the opcodes.
  • The counter at $10 counting downwards through all the opcodes.
  • The execution in between, changing the value of A in unpredictable ways. A is unusable.
  • The two 0xA0's sitting at $8D and $8E, executing one of A0 A0 or A0 00 in each loop, setting Y to 0xA0 or 0x00. Y is unusable.
  • The code accidentally stumbling across one of the 12 KIL instructions, stopping execution completely.
  • The fact that setting X to 0xFF, then executing 'STA $01,x' does not write to $0100 but instead wraps around to $0000.

The execution

What is done in this movie is writing 0x8F to $F9 (which is just after the input bytes). Then we're able to form 20 E1 with input, making a jump to $8FE1 (not quite $8FE3, but it will reach the same place if the zero flag isn't set).
To make that write, we need at least two registers. The A and Y registers are unusable. But we can make Y usable by somehow avoiding the A0 A0 block at $8D. After both X and Y are usable, we can change their values and either use STX $ZZ,y or STY $ZZ,x to make the write.
BytesInstructionDescription
48 48PHA PHAThe Stack Pointer is at 0x04, and just about to overwrite the NMI mode with a bad value. We manipulate it to avoid that.
D6 14DEC $14,xX is 0x00, so this decreases $14 from 0x00 to 0xFF. This is done to (eventually) skip over the counter at $15 and the byte at $16, as 0xFF is a 3 byte instruction. Note how using C6 14 (DEC $14) as an instruction wouldn't have worked due to the 0x10 bit in 0x14 not being in 0xC6.
CA (C2)DEX (NOP)This decreases X from 0x00 to 0xFF. We want X to be odd so the second byte is different (it happens to do nothing here).
D6 10DEC $10,xSince X is 0xFF, this decreases $0F from 0x00 to 0xFF. Another preparation to skip over problematic addresses ($10 in this case).
C6 06DEC $06We decrease $06 from 0x00 to 0xFF. This finally completes the setup. No matter whether we execute odd or even addresses, we will hit the 0xFF at $0F (skipping over $10), then we will execute 0x00 at $12, and then 0xFF at $14 (skipping over $15 and $16), to assure we execute $17 every loop.
D6 40DEC $40,xWe decrease $3F from 0x00 to 0xFF to execute even addresses after this point. This is necessary because we can only write specific values to even addresses (using only X).
A2 20LDX #$20Load X with 0x20 for the next write.
86 86STX $86We write 0x20 to $86, which executes JSR $0000 for us without using the 4-byte block at the end. Additionally, we now skip the A0 A0 at $8D, so Y is now usable.
88 (08/00)DEY (PHP/BRK)We decrease Y from 0x00 all the way to 0xF9 to prepare for the write to $F9
A2 A0LDX #$A0We now set X to 0xA0 to be decreased to 0x8F, but we can use a trick here.
9A (18)TXS (CLC)We transfer X to the Stack Pointer. We can decrease the Stack Pointer faster than X.
(28) 20(PLP) JSR $0000$19 and $1A are both 00, so we can shorten the loop and decrease the Stack Pointer faster.
20 00JSR $0000Since we can lag the game whenever, we can precisely time the point where the Stack Pointer reaches 0x8F.
BA 9ATSX (TXS)We transfer the Stack Pointer back to X.
96 00STX $00,yThe setup is complete and we can finally write X (= 0x8F) into $00+Y (= $F9). Now we just need to break out of the loop we created.
84 84STY $84We write 0xF9 into $84. This is a 3 byte opcode so we jump over the 0x20 we wrote to $86 earlier.
20 E1 8FJSR $8FE1The zero flag is not set so we execute $8FE3 and win the game (for real this time).

Special thanks to

  • Alyosha, for creating SubNESHawk, the core that allows button presses once per poll instead of once per video frame.
  • total, for initially playing around with this and creating a Lua script for allowing subframe input on FCEUX.
  • Site admins, for implementing the correct movie file parsing.

Suggested Screenshot

Maru:

Introduction

Firstly, I have to open with how much of a technical marvel it was to figure out how to beat the game from the title screen. The opening levels, all of the other Worlds, and the notorious World 8 autoscrollers are now nowhere to be seen. A TAS of this type was first showcased at Summer Games Done Quick 2016 (SGDQ 2016); however, after some fine-tuning, it was possible to reach the true ending of the game instead of simply being stuck on the credits screen. If the TAS that was showcased at SGDQ 2016 was submitted to TASVideos, it would have to be rejected because it technically does not complete the game; however, the authors found a way to trigger a valid completion. With that, everything looks to be in good order, but this was an absurdly difficult TAS to judge due to the precedent that this decision would set for future game end glitch TASes that would be submitted to TASVideos.

The Glitch

This TAS abuses the DPCM workaround that the developers of this game implemented. With Super Mario Bros. 3 (SMB3), the game developers implemented a system in which the controller would be polled two times until two consecutive inputs matched. However, this can be abused to cause unintended interactions between the NMI and the IRQ and then unintended jumps in memory. In short, this is a very powerful major glitch, and something with effects to this magnitude had not necessarily been seen before now.
In terms of the legitimacy of this glitch, it has been confirmed thanks to dwangoAC’s help that this TAS indeed console verifies on an actual NES. While it is inconsistent, it is confirmed that the authors are taking advantage of a legitimate bug in the game instead of an emulator bug. The evidence of console verification can be found here.
The thing is, the DPCM glitch is not unique to SMB3. It can be summarized as follows: you have NES games with a DPCM glitch, some of those games have a DPCM workaround, and fewer games have an abusable DPCM workaround that allows for a game end glitch similar to this one.
Around a month before this was submitted, Total and I worked on the Super Mario Bros. 2 (SMB2USA) game end glitch. It also takes advantage of the DPCM glitch, but the difference is that a memory setup needs to be achieved in the first level before taking advantage of the glitch. For anyone curious, the documentation can be read here to see how it compares to this SMB3 submission.
Now, there are other games that have an abusable DPCM workaround too, but it does not appear that many games have a DPCM workaround that permits reaching the game’s ending at the title screen. If all games had a DPCM workaround that could be abused to this magnitude, there would be some more concern about allowing TASes that take advantage of this glitch, but this is not the case.

Feedback

Feedback as a whole was mixed for this TAS. The feedback and ratings are not positive enough to warrant acceptance into the moons tier. Therefore, this TAS has to go to the vault tier if it is accepted. There was an equal divide between the number of people who wished for this TAS to obsolete the published run and the number of people who wished for this TAS to be accepted as a new branch. During the initial collection of feedback, I polled people for their definition of gameplay. There were different opinions as to what constitutes gameplay, so this led to a staff discussion to sort things out and create a clear-cut definition for this important concept.

Gameplay

There is some debate as to whether or not this is a gameplay improvement compared to the published run. This is not the first time that longer game end glitch TASes have been obsoleted by significantly shorter ones, so it’s time to look at past cases to see how those decisions panned out and what the differences are with those situations compared to this situation.
Super Mario World’s (SMW’s) first game end glitch TAS was submitted at the end of 2011. It showcased the null sprite glitch by first completing Yoshi’s Island 2 (YI2) and then moving to Yoshi’s Island 3 (YI3) to manipulate the memory values necessary, including RNG, for the glitch to work. The glitch worked by spawning fish from Yoshi in the underground section of YI3, which changed RNG addresses to activate the glitch. That followed with using glitches to duplicate Yoshi sprites and get a cape for the final stages of memory manipulation which would allow for a credits warp. This TAS was obsoleted by a faster strategy that reached the credits from the underground section of YI2. That variant brought sprites to the underground and used a new flying block stun glitch, some enemy slot manipulation, positioning of a P-Switch, and the use of a jump to controller data to reach the credits. Eventually, the SMW game end glitch TAS would see iterations that reach the credits just shortly after collecting Yoshi in YI2 using the item swap glitch because the charging chuck enemies have properties similar to powerups that can be used to jump to the Open Bus region of the SNES.
Now, let’s look at the progression of Super Mario World 2: Yoshi’s Island (SMW2:YI). In 2007, a warp glitch was discovered that allowed for warping to the last level of the game (6-8) by manipulating the coin count and pressing left+right on the controller. The warp glitch branch went through several minor improvements over a few years. Eventually, that type of TAS was obsoleted by a game end glitch TAS that used the warp glitch to reach 2-2 and proceeded to perform a null sprite swap, which can be used to jump to controller data and then the credits. After that, SMW2:YI game end glitch was improved again through a different route, in which the player uses the warp glitch to reach 1-2 and uses the infinite tongue glitch to jump to controller data and then the credits.
So, what makes SMB3 different in this case? In these submissions, there was some sort of improvement in the route, but the playable character was still visible to the viewer in these submissions. Mario, Yoshi, or both characters were still in action with these game end glitch improvements. With this submission, however, all of the work is being done from the title screen, so there is the argument that having “no gameplay” means that the gameplay was not technically improved compared to the published run. In other words, a direct comparison to the published run in terms of gameplay cannot easily be made due to the drastically different ways in which the credits were reached. On the other hand, there is the argument that having less gameplay, even if there is none, is a gameplay improvement compared to the published run. However, these are not ideal ways to judge this TAS in terms of improved or unimproved gameplay for a couple of reasons.

TASes with less gameplay do not always obsolete TASes with more gameplay, even with the same goal in mind

First of all, faster completion TASes with the same goal in mind may not always obsolete slower ones. An example scenario that I could pull here is the SMB3 warps TAS that was submitted in October 2018. With this TAS, there was a speed/entertainment trade-off which involved using a faster and more innovative route through 8-Fortress; however, it turned out that when the TAS was made, it was actually one frame slower to use that route instead of the standard route that was used in decades past due to worse luck with RNG values with Bowser’s routine. Now, a one frame improvement to that TAS could have been submitted with the overall entertainment reduced by a certain margin, but obsoletion is not an ideal approach in that scenario. For small improvements, it is ideal for entertainment to be at least as good as the published TAS. While collecting the two warp whistles to warp to and traverse through World 8 is no longer the fastest way of beating the game, it needs to be remembered that it once was the method of fastest completion. For anyone looking for more than a hypothetical scenario, take a look at this “faster completion” TAS that was not accepted for publication. TASVideos does have entertainment at heart, and while the Vault may exist for movies that do not meet entertainment standards, the fact that the Vault exists does not mean that obsoletion is a given.

Gameplay is what results in a goal being fulfilled

Instead of comparing gameplay by visual means, we have to keep the overall goals in mind. Both TASes sought to reach the credits as fast as possible. However, they did so by using different strategies. Part of gameplay involves being innovative to find different types of strategies, routes, and optimizations in order to satisfy the goal in mind. In essence, both TASes reach the same goal, but this submission fulfills that goal through a much faster strategy. In that sense, this TAS is a gameplay improvement compared to the published run.
While judging this TAS, I stumbled upon a rejected TAS of Kirby Avalanche that skipped to the ending straight from the title screen. I did consider the idea that the two TASes may not look different to the average viewer and without any form of context, the TASes would be nearly identical to the viewer. The main difference between this submission and the Kirby Avalanche submission is that this submission required some very careful controller manipulation in order to jump to the credits, while the Kirby Avalanche submission used a debug code to reach the credits. At TASVideos, we demand more effort than entering in a debug code to jump to the credits. While there may be a similar viewing experience, we filter out runs that break our movie rules by rejecting those runs. This TAS was a game end glitch, while the Kirby Avalanche TAS could not be considered a game end glitch in any form. Since we have branches, we can publish this SMB3 movie with the branch “game end glitch” so viewers know that a glitch is being exploited to reach the credits. Perhaps I would be uncomfortable publishing a movie like this without a branch name, but we have branches so everything is fine in that regard.

Movie Rules

This initially gave us confusion due to some clauses within the movie rules and judge guidelines concerning gameplay improvements. These were as follows:
Obsoleting a published movie
When comparing against a prior movie for faster time, the faster time must come from improved play in the actual game-play segments. For example, gaining time by switching to another version which loads faster, has shorter cut-scenes, or by more optimized usage of the title screen menus is not counted as an actual time improvement. A movie which doesn't have any actual in-game game-play improvements over its published predecessor will not be accepted.
Use the correct version
The US U versions are generally preferred over the Japanese J version due to the use of English language, which is easier to understand for the general audience. However, the Japanese audience here is significant, and there is no longer a specific requirement at TASVideos to use one version over another. Keep in mind that time gained solely through basic ROM differences will be discounted for the purpose of comparison. This includes: time gained through shorter cutscene text and speech boxes due to Japanese writing being more compact; differences in title screen, cutscenes, and menus (unless menus are the game's main control interface). Only actual game-play improvements will be considered. For example:
  • there's a published movie made on a (U) ROM;
  • the title screen for this game takes 100 frames less on a (J) ROM;
  • a movie made on a (J) ROM is submitted, that is 101 frames faster than the movie made on a (U) ROM.
The improvement to be judged in this example is just 1 frame; the 100 frame gain from a shorter title screen is discounted.
The reasoning behind the rules regarding title screen improvements not being counted as gameplay improvements is that they require little effort in order to execute. At TASVideos, we want to have meaningful publications, which is why these rules are in place.

Where to go from here?

First, we need to define the types of input that a game can have. It seems fair that input can be divided into three different types of categories:
  1. The first category is input that does not have any relationship or connection with in-game action. This usually consists of the input performed on title screens or selection or settings menu.
  2. The second category of input that has loose relationship to the in-game action. For SMB3, an example of this would be input performed during the World map (such as moving from level to level or equipping a P-Wing from the inventory) or buying items in an adventure/RPG game.
  3. The third and final category is input that directly relates to or creates the in-game action. This is when the player is using input to progress through the challenges or obstacles that a game has to offer.
At TASVideos, we have typically looked for improvements in the third and final category, although improvements have been accepted to the second category as well. Improvements to the first category were not accepted unless there was an improvement in the second or third category of input.
Going back to this submission, all of the input falls under this first category; however, that input greatly shortens the amount of input falling under categories two and three. In that sense, it did improve gameplay in that regard.
For clarification, we have chosen to add a definition of gameplay in the glossary section. That definition is as follows:
An in-game task or puzzle that is meant to be accomplished or solved by a human while playing the game, by sending inputs to the game and getting its reaction.
This TAS successfully meets the objective of reaching the credits by quite literally sending carefully-crafted inputs at the title screen. This is a good general definition of gameplay for our site.

The Verdict

Now, there are three courses of action that could be taken. I will run through the positives and negatives behind each of these.

Reject

While there was indeed some initial confusion with the movie rules, it turns out that this TAS does not break any of them. The movie rules are one thing to look at, but to double check for 100% certainty, we can also recall what the goals of TASVideos are and see how this submission lives up to TASVideos’ mission.
TASVideos.org is committed to providing the best in tool-assisted speedruns and superhuman play. Our runs are held to high standards, and only high quality runs will be published on the site. We also prefer quality over quantity — a poor quality run will not be accepted whether it is a game new to the site or an improvement to a pre-existing run. Our runs may not be perfect (if that is even possible), but are still high quality and aim to be as entertaining as possible.
We make these movies because they are entertaining to watch, and because we are curious how far a game can be pushed. The process of creating them is also a form of problem-solving and challenge to our intellect and ingenuity. If a child receives a box containing an expensive toy as a birthday present, it's possible that he'll enjoy the box more than the toy. This is creativity. We're doing the same for these games. Instead of walking on the paths created for us, we create our own paths, our own legs and so on. And we're not listening to people who say "you can't do that!". Just like children.
While this TAS does not live up to the goal of entertainment, this is a superplay and has zero chance of being replicated in real time. SMB3 is pushed to the brink of its limit, and the way in which this TAS was pushed to its limit required immense amounts of creativity and problem solving abilities. Overall, it does not fit the mission of the website perfectly, but it fits the mission fairly well. There is no sensible reason to reject this TAS. That would mean that our site would only be hosting a significantly slower iteration of the SMB3 game end glitch with no chance for a faster version to shine.

Accepting to a new branch

This is assuming that the gameplay between the two TASes is so wildly different that a new branch has to be created. I see that the main benefit to this is that two types of game end glitches are showcased on TASVideos at the same time, and one type of game end glitch may cater to the audience more than the other. While some improvements may necessitate the creation of a new branch, having two game end glitch branches does not seem suitable for this game or any game on TASVideos. We had a case where two Super Metroid categories were obsoleted by a game end glitch category, but we have never had a case where two game end glitch TASes have coexisted side by side.
This is when my experience with TASing SMB3 comes into play. While the 7-1 wrong warp variant of this game end glitch does have the entertainment merit over this submission, it is also improvable without any route changes; however, those improvements would not increase that entertainment merit in any way. The entertainment merit would either stay the same or decrease if improvements to the 7-1 wrong warp route were made. In other words, what might seemingly be an attractive reason for having these two TASes separate from each other would eventually be a regrettable decision.
Looking at both TASes from a goal standpoint, they both aimed to complete the game as fast as possible. The 7-1 wrong warp was thought to be the fastest way of accomplishing that goal back in 2014. Now, spamming subframe inputs from the title screen is the fastest way of accomplishing that goal. They both use a game-breaking glitch and both execute arbitrary code, and this effectively makes them the same category, no matter how you look at it or gameplay is defined. It does not make sense for two TASes of the same category to coexist with each other, and if we were to let that happen, we would need some sort of justification for how game end glitches can be differentiated from one another that can apply to all types of games. Even the two Super Metroid TASes that coexisted at the same time before being obsoleted by the game end glitch used completely different approaches while they both relied on game-breaking glitches. Overall, this would lead to disorder, encourage submissions with no obvious differences between branches, and flood the site with an infinite amount of meaningless publications.
We could also bring in the rejected 16 star TAS from Super Mario 64 (SM64) as an example. Collecting 16 stars and notably using MIPS the Rabbit was once the fastest way of beating the game, but then more backwards long jumps (BLJs) were discovered to cut down the number of stars required to beat the game. Now, only 1 key is required to beat the game. 16 star TASes prior to 2007 had the goal of beating the game as fast as possible, and so does the current 1 key TAS. Just as SM64 does not have two branches with the same overall goal in mind existing side by side, it does not feel appropriate to have two TASes that execute arbitrary code with the goal of reaching the credits, and this could lead to chaos with other games too.

Accepting as an improvement to the published run

This is the course of action given that this submission outperforms the published run in terms of gameplay based on the new definition above. While this TAS would only get the vault tier instead of the moons tier that the published run got, it is not the first time that something like this has happened before. Taking this route very clearly shows the fastest completion of SMB3 and keeps the number of branches to a reasonable minimum. In addition, it sets a precedent that limits the number of branches to other games that may have a potentially abusable DPCM workaround. This is the best option for the sake of organization.
There are some downsides to obsoletion, however. In this case, a less entertaining movie would be obsoleting a more entertaining one. As I elaborated earlier, this will not always be the case, but while this movie falls short compared to the published 7-1 wrong warp TAS in entertainment, it exceeds that TAS in terms of technical quality. Superior technical quality is what the rejected Ninja Gaiden precedent lacked compared to the published TAS at that time. Technical quality is essentially a redeeming factor for a TAS like this.
On another note, if we consider the hypothetical scenario that a TAS that reached the credits in the middle of 1-1 was submitted to obsolete the published run, that would indeed happen. If someone submitted a TAS that reached the credits during the first second of 1-1, that would obsolete the TAS that reached the credits in the middle of 1-1. Finally, if this TAS was submitted, it would obsolete the TAS that reached the credits during the first second of 1-1. Sometimes big steps can be alarming at first, but that concern would have not occurred if several smaller steps were taken instead of one big step.

Conclusion, Final Decision, and TL;DR

Overall, from reviewing this TAS, looking at past precedents, and revisiting our site goals and movie rules, I have deemed that TASes abusing the DPCM workaround, including this one, are allowed for this site, although barely. Congratulations on putting together the shortest TAS to ever be accepted by TASVideos. Accepting to vault as an improvement to the published run.
Spikestuff: But who was TAS? Publishing.

Show more

Hide
1 2 3 4 5 6 7
Posted: 7/29/2019 9:23 PM
Quote
GhostSonic
He/Him
Joined: 3/14/2013
Posts: 61
I'm gonna go against what some of the other have said and say, yes, I found this run very entertaining. Watching the game be completed literally within a second of the console turning on is absolutely hilarious, and everyone I show this to (who isn't a member here) seems to agree. This run is so uniquely absurd, just leaving in vault would be a terrible choice in my opinion. Having it obsolete the current "Game End Glitch" would suck though. I would rather advocate for a new category, as arbitrary as it may be now. But I would also err towards what dwangoAC said on the matter.
Dirty SNES TASBot code on GitHub
Posted: 7/30/2019 8:18 PM
Quote
pirate_sephiroth
Active player (315)
Joined: 2/28/2006
Posts: 2275
Location: Milky Way -> Earth -> Brazil
New systems TAS of 2009
Yep, it's good. It ends the game as fast as possible, alright. The only reason not to accept it is if this same bug can be performed on many other games. In such case a new category should be created.
"Genuine self-esteem, however, consists not of causeless feelings, but of certain knowledge about yourself. It rests on the conviction that you — by your choices, effort and actions — have made yourself into the kind of person able to deal with reality. It is the conviction — based on the evidence of your own volitional functioning — that you are fundamentally able to succeed in life and, therefore, are deserving of that success." - Onkar Ghate
Bisqwit wrote:
Drama, too long, didn't read, lol.
Posted: 8/1/2019 1:11 PM
Quote
Kung_Knut
He/Him
Joined: 8/10/2016
Posts: 85
Location: Sweden
Stating my opinions on Marus questions:
Maru wrote:
What do we consider as gameplay?
Everything from power on is gameplay. A TAS necessarily starts at power on, and so for a TAS, gameplay for all games start at power on.
Maru wrote:
Does this TAS have any gameplay improvements compared to the published run?
Yes. Its arguably in the same category, and it is faster. Thus, it has gameplay improvements.
Maru wrote:
If this submission is accepted, should it obsolete the published run based on the fact that the published run was thoroughly outperformed in terms of time?
Yes, it should. This is also an ACE run, only a much faster one.
Maru wrote:
Is this type of game end glitch significantly different from the published game end glitch TAS to warrant the creation of a new category?
No, this is just a faster method to achieve ACE and reach the credits.
Maru wrote:
Since the ending is almost instant, do viewers see some similarity or resemblance to entering a password in-game to skip to the credits?
No, not at all. --- My opinion is that this is a no-brainer. This is a faster completion of an existing branch of a game, and so it shall obsolete the existing publication in that branch. Yes, it is less entertaining, but that is an unavoidable concequence of games being completed faster, and less content and awesomeness being shown. There is a sort of sweetspot where a faster TAS with better optimization and more glitches generally stop being more entertaining because the glitches and/or speed make the video less pleasing to watch. There are quite a few games that have already passed that sweetspot, where new TASes generally are less entertaining than their predecessors. This is such a case.
Posted: 8/2/2019 5:42 PM
Quote
ThunderAxe31
Any
Editor, Reviewer, Skilled player (1361)
Joined: 9/12/2016
Posts: 1646
Location: Italy
Arcade TAS of 2023 Homebrew TAS of 2023 PSX TASer of 2022 Gameboy TASer of 2017
Sorry if I didn't answer earlier to these posts, but I had to take a break for being sure of my conclusions.
feos wrote:
ThunderAxe31 wrote:
As I already wrote in this post, it would be a limitation for Vault-only movies that aim for fastest-completion. The only reason it's not the case for this specific submission, it's because the currently published GEG is Moons. My point is: what if it wasn't Moons? That would mean that it's going to get obsoleted and that there could be no freedom left to compete for that kind of TASing. Since similar glitches could be executed in other games, there are chances that at some point we will see Vault movies getting obsoleted by them, locking away the freedom of competing for a certain kind of TASing in favor of another.
There's always a chance some movie can't be improved by "regular gameplay" anymore. And there are always people interested in trying "irregular" gameplay against them. There's still room for improvement, so that part isn't limited. As for the feel of the movie, it's already Vault, there's very little to expect in the first place. We should be ready to lose old movies, because they're boring either way.
This argument looks perfectly sound to me, as I really can't disagree. It would indeed be counter-progressive to cling to what's old despite its obsolescence, both for TASing and for life in general. Also, since this is part of my personal ideas, it would be hypocritical for me to go against it.
Memory wrote:
Now, I understand that you see no reasons to make a distinction between the glitch used for this movie and other glitches, as you only feel the positive aspects of it...
Now I feel this misrepresents me entirely. I feel there is a very obvious negative aspect of this glitch: it's not fun for me to watch. With Vault, what is entertaining to watch is an irrelevant. In my eyes, there are three relevant points. Does it complete its objective? Yes. It completes its objective of completing the game as quickly as possible. Is it performed in a legitimate environment? Well I haven't looked into the technical details myself but it sounds like it is the case or close enough for our rules. Is it superhuman? This last one is key to this submission I feel and the answer is quite clear. Absolutely.
I apologize for misunderstanding, now I see why you don't consider the glitch performed to be different from what we've seen before. The definition you gave seems sensible to me, so that this movie is a TAS in all aspects. And in light of this, any attempt of making a differentiation with "traditional" kind of glitches would make things uselessly more complex. At this point I can't argue anymore in favor of introducing a new rule or argue against the accepting of this movie.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Posted: 8/5/2019 3:14 AM
Quote
GamesFan2000
He/Him
Joined: 1/4/2019
Posts: 84
Location: Canada
In terms of pushing a game as far as it can go, this TAS literally did just that. I don't care that there's nothing to watch, I'm impressed that this is even possible to begin with. And, as one other person has said, it's hilarious to think about. Yes vote.
Posted: 8/5/2019 4:29 AM
Quote
CoolHandMike
He/Him
Editor, Judge, Experienced player (897)
Joined: 3/9/2019
Posts: 729
First edition TAS of 2023 Sega TAS of 2023
This is a great hacking and programming feat. Maybe fully understood 1/4 of the explanation since I don't know that assembly, but I found it to be the most technical explanation of a movie on this site and enjoyed it a lot. Unfortunately the fact that I had to read a page of technical explanations just to understand something of what is happening puts this movie in a special kind of place. Basically the movie itself is not entertaining without context. There is input into the game, but there is nothing of what I would call gameplay. This is basically assembly programming making use of a hardware glitch. This SMB3 glitch's effect is very similar to ACE exploits it seems...and my favorite ACE is of course MrWint's Pokemon Yellow ACE http://tasvideos.org/3358M.html. One of the first TASes I ever watched and one of the best. I would argue that this is almost certainly Arbitrary Code Execution. It uses this hardware glitch to get it into a state that allows them to do damn near whatever they like with the game. It looks like it has some major inconveniences with limited inputs limiting opcodes, but there are workarounds as shown and it allows the programmer to input what they wish...so ACE. If I am wrong I am curious as to why.
discord: CoolHandMike#0352
Posted: 8/5/2019 4:31 PM
Quote
electricslide
Joined: 1/27/2014
Posts: 181
Great achievement. I want to give a shoutout to Masterjun's and ais523's triumph here. If I had put in the work that they had done and achieved this stunning result I would be rather annoyed by the whole debate around it. Should be in moons, IMO. forget about the whole Vault.
Posted: 8/5/2019 4:33 PM
Quote
EZGames69
He/They
Publisher, Reviewer, Expert player (4468)
Joined: 5/29/2017
Posts: 2765
DS TAS of 2023 SNES TASer of 2022 SNES TASer of 2021 SNES TAS of 2021 Exotic platforms TAS of 2021 TASer of 2020 SNES TASer of 2020 Sega TASer of 2020 TASer of 2019 Sega TASer of 2019 Exotic platforms TAS of 2018
electricslide wrote:
Should be in moons, IMO. forget about the whole Vault.
...if this was any other game other than SMB3 (like if it was a shovelware NES title that had this glitch), would you still be saying this?
[14:15] <feos> WinDOES what DOSn't 12:33:44 PM <Mothrayas> "I got an oof with my game!" Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish [Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Posted: 8/5/2019 5:29 PM
Quote
Memory
She/Her
Site Admin, Skilled player (1558)
Joined: 3/20/2014
Posts: 1767
Location: Dumpster
GBA TASer of 2020 GBA TAS of 2020 GBA TASer of 2019 Exotic platforms TAS of 2018
EZGames69 wrote:
electricslide wrote:
Should be in moons, IMO. forget about the whole Vault.
...if this was any other game other than SMB3 (like if it was a shovelware NES title that had this glitch), would you still be saying this?
The fact that it is SMB3 isn't exactly irrelevant. I wished people watched TASes without looking at what game it was but fact is that they do look at the game and we just have to deal with that fact.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Posted: 8/5/2019 7:27 PM
Quote
zaphod77
Joined: 1/13/2007
Posts: 343
This skips the whole darn game. :) There was one other TAS that skipped close to that much. it was the one where you could manipulate the game ending item to be right by the start and just blindly dig it up. Maybe there should be a "skips 99% of the gameplay or more" tag? :)
Posted: 8/5/2019 11:05 PM
Quote
brunovalads
Editor, Player (175)
Joined: 4/7/2015
Posts: 331
Location: Porto Alegre, RS, Brazil
I have no doubts that this run should be on this site, so yes! It's a high-level piece of technical work, and if it's possible on real hardware it definitely deserves recognition. However, as other people mentioned, this is a deeper version of game end glitch, so it should have its own branch.
Games are basically math with a visual representation of this math, that's why I make the scripts, to re-see games as math. My things: YouTube, GitHub, Pastebin, Twitter
Posted: 8/6/2019 5:07 AM
Quote
Zakatos
He/Him
Joined: 7/26/2004
Posts: 90
Location: Brazil, Sao Paulo, Campinas
Once upon a princess and a plumber. And they lived happily forever after.
The eyes of a machine are wonderful, but there's nothing like the the eyes of the heart – Old Cid, Cybercop
Posted: 8/6/2019 9:56 AM
Quote
Warp
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Memory wrote:
The fact that it is SMB3 isn't exactly irrelevant. I wished people watched TASes without looking at what game it was but fact is that they do look at the game and we just have to deal with that fact.
The choice of game is indeed quite relevant in terms of the enjoyability of the wider public (especially the demographic that are naturally interested in watching speedruns). A lot more people are more interested in watching, for example, a Super Mario Bros speedrun because they have themselves played it or, at the very least, know it and have seen it. The interest in watching some obscure game that almost nobody has played is much less so. In general, if you know a game well, especially if you have played it a lot, it's more interesting to see it being speedrun. However, in this case this becomes less relevant because the game isn't actually being speedrun. There's no gameplay. There's nothing to be seen. There's no awesome superhuman skill visible on screen at any moment. There's no astonishing gameplay to be enjoyed by. There's just an ending screen. You could just as well make a google image search for "super mario bros 3 ending screen" and get the same amount of visual enjoyment.
Posted: 8/6/2019 1:27 PM
Quote
electricslide
Joined: 1/27/2014
Posts: 181
if this was any other game other than SMB3 (like if it was a shovelware NES title that had this glitch), would you still be saying this?
Yep. One of my favorite TASes is the Kings Bounty one. :)
Posted: 8/6/2019 3:17 PM
Quote
zdoroviy_antony
He/Him
Joined: 7/10/2019
Posts: 22
Location: Ukraine
I think this TAS shouldn't replace current game end glitch TAS. 7-1 game end glitch is so great that it needs to have its own branch.
Posted: 8/6/2019 6:16 PM
Quote
ais523
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
theripper999 wrote:
I would argue that this is almost certainly Arbitrary Code Execution. It uses this hardware glitch to get it into a state that allows them to do damn near whatever they like with the game. It looks like it has some major inconveniences with limited inputs limiting opcodes, but there are workarounds as shown and it allows the programmer to input what they wish...so ACE. If I am wrong I am curious as to why.
I suspect this technique can be used to gain ACE, yes. However, it isn't a hardware glitch. The code that's exploited is in the game cartridge, not the NES. There is a hardware glitch, but it's not directly relevant to the run, and the run would work the same way without it; the only reason it's mentioned is that the likely reason that the exploitable code is in the game is that it was probably an attempt to fix the hardware glitch in software. (So the game contains code to work around a hardware glitch; the glitch isn't relevant to the run, but the workaround code is buggy and the workaround code is what the run exploits. Even when using a NES that doesn't have the hardware glitch, the buggy software workaround still exists on the game cartridge and is still exploitable.)
Posted: 8/7/2019 12:20 PM
(Edited: 8/26/2019 6:40 PM)
Quote
Masterjun
He/Him
Site Developer, Expert player (2047)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Exotic platforms TAS of 2020 Speedy TAS of 2018 PC TAS of 2018 Glitchy TAS of 2015 TASer of 2014 SNES TASer of 2014 TAS of 2014 SNES TAS of 2014 Funny TAS of 2014 Glitchy TAS of 2014 TASer of 2013 SNES TASer of 2013 NES TAS of 2013 SNES TAS of 2012 Funny TAS of 2012
For reference, dwangoAC confirmed this run works on console. Thanks for testing! :D (Twitch Clip in case the VOD is deleted)
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Posted: 8/7/2019 2:53 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3828)
Joined: 11/30/2014
Posts: 2834
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
Masterjun wrote:
For reference, dwangoAC confirmed this run works on console. Thanks for testing! :D
Awesome! Seeing this running on console makes me hopeful subframe inputs might be more widely applicable. Maybe some long standing runs that failed on console before can be made to work, like Mike Tyson's Punchout or Ninja Turtles. Maybe I'll start looking into it.
Posted: 8/7/2019 6:07 PM
Quote
Kung_Knut
He/Him
Joined: 8/10/2016
Posts: 85
Location: Sweden
For the record, I voted yes, because I was entertained. I believe this deserves to be in Moons. Ten years from now, we will remember this as one of the most important moments in TAS history. Thanks for your amazing efforts!
Posted: 8/11/2019 12:28 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3828)
Joined: 11/30/2014
Posts: 2834
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
I wanted to make a quick note about sync here. This run won't sync in the current dev build due to emulation changes. It will however sync with different initial conditions. I'm not sure yet what initial conditions I will set NESHawk too for the next release. Since this run works on hardware the initial conditions for it to work in the current core (which is zero cpu offset) seem like a good choice, but I'm still doing a lot of testing. Unfortunately NES power up state varies widely, so picking one or another state will inevitably cause some runs to work and others not to, just a choice that has to be made.
Posted: 8/11/2019 3:05 PM
Quote
Warp
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Kung Knut wrote:
For the record, I voted yes, because I was entertained.
I'm curious to know which part of the 0.78 seconds was the most entertaining.
Posted: 8/11/2019 3:23 PM
Quote
ThunderAxe31
Any
Editor, Reviewer, Skilled player (1361)
Joined: 9/12/2016
Posts: 1646
Location: Italy
Arcade TAS of 2023 Homebrew TAS of 2023 PSX TASer of 2022 Gameboy TASer of 2017
Kung Knut wrote:
For the record, I voted yes, because I was entertained. I believe this deserves to be in Moons. Ten years from now, we will remember this as one of the most important moments in TAS history. Thanks for your amazing efforts!
[3430] A2600 Dragster by Omnigamer in 00:08.49 That movie got a terrific audience response when it was submitted, much better than this submission. Also, in my opinion that was as well another of the most important moments in TAS history. But despite all that, it got mediocre entertaining ratings and had to be moved to Vault, some time after publication. Don't misunderstand, I'm not saying that we should disregard submissions reception altogether. However, to me it doesn't make much sense to accept a submission for Moons for cases where we can tell in advance that it's going to get Vault ratings.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Posted: 8/11/2019 7:10 PM
Quote
Kung_Knut
He/Him
Joined: 8/10/2016
Posts: 85
Location: Sweden
Warp wrote:
Kung Knut wrote:
For the record, I voted yes, because I was entertained.
I'm curious to know which part of the 0.78 seconds was the most entertaining.
The part at about 0.78 seconds in, where the game just gave up before it even started. Like it realized it's no use even attempting to challenge that superhuman player on the other end of the controller port. Quite the "wtf just happened?" the first time I watched it. Of course, for the casual viewer, I fully understand that it might look like a SMB3 ending video with some weird messy graphics at the start of the video. But I'm not a casual viewer, and I very much liked what I saw.
Posted: 8/11/2019 7:15 PM
Quote
Kung_Knut
He/Him
Joined: 8/10/2016
Posts: 85
Location: Sweden
ThunderAxe31 wrote:
Kung Knut wrote:
For the record, I voted yes, because I was entertained. I believe this deserves to be in Moons. Ten years from now, we will remember this as one of the most important moments in TAS history. Thanks for your amazing efforts!
[3430] A2600 Dragster by Omnigamer in 00:08.49 That movie got a terrific audience response when it was submitted, much better than this submission. Also, in my opinion that was as well another of the most important moments in TAS history. But despite all that, it got mediocre entertaining ratings and had to be moved to Vault, some time after publication. Don't misunderstand, I'm not saying that we should disregard submissions reception altogether. However, to me it doesn't make much sense to accept a submission for Moons for cases where we can tell in advance that it's going to get Vault ratings.
True, you are right of course. Being notable does not make the TAS qualify for Moons on its own.
Posted: 8/11/2019 7:15 PM
Quote
Memory
She/Her
Site Admin, Skilled player (1558)
Joined: 3/20/2014
Posts: 1767
Location: Dumpster
GBA TASer of 2020 GBA TAS of 2020 GBA TASer of 2019 Exotic platforms TAS of 2018
Now while I personally don't get much entertainment value from this TAS, I believe that the average viewer could potentially get entertainment value from it. I'd think it would be fairly obvious based on context that SOME sort of glitch brought about the end early and the shock value of the game being completed THAT fast does have some novelty to it. So I don't think this attitude of "what were you even entertained by" is warranted.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
1 2 3 4 5 6 7