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.
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!)
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.
- The $C000 bank needs to be 0x19
- The $A000 bank needs to be 0x18
- The PPU control register copy ($00FF) needs to be 0xA8
- NMI mode ($0100) needs to be set to 0x20
- Jump to $B85A
- 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.
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.
| Bytes | Instruction | Description |
|---|
| 48 48 | PHA PHA | The Stack Pointer is at 0x04, and just about to overwrite the NMI mode with a bad value. We manipulate it to avoid that. |
| D6 14 | DEC $14,x | X 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 10 | DEC $10,x | Since X is 0xFF, this decreases $0F from 0x00 to 0xFF. Another preparation to skip over problematic addresses ($10 in this case). |
| C6 06 | DEC $06 | We 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 40 | DEC $40,x | We 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 20 | LDX #$20 | Load X with 0x20 for the next write. |
| 86 86 | STX $86 | We 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 A0 | LDX #$A0 | We 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 00 | JSR $0000 | Since we can lag the game whenever, we can precisely time the point where the Stack Pointer reaches 0x8F. |
| BA 9A | TSX (TXS) | We transfer the Stack Pointer back to X. |
| 96 00 | STX $00,y | The 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 84 | STY $84 | We write 0xF9 into $84. This is a 3 byte opcode so we jump over the 0x20 we wrote to $86 earlier. |
| 20 E1 8F | JSR $8FE1 | The 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
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:
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.
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:
- 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.
- 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.
- 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.
