(Link to video)
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!)

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


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:
  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.

1 2
6 7
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14776
Location: 127.0.0.1
EZGames69
He/They
Expert player, Publisher, Reviewer (3942)
Joined: 5/29/2017
Posts: 2701
Location: Michigan
I unfortunately cant find any entertainment in the movie watching itself. yes the amount of work required to achieve this is very intense, but the outcome just makes the actual viewing experience obsolete. no vote from me.
[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
Troye
He/They
Experienced player (853)
Joined: 4/27/2018
Posts: 66
Yes vote because I can't see a thing which is entertaining for me
Banned User
Joined: 5/27/2019
Posts: 136
Location: Gensokyo
Voted yes because--- ??? ERRORERRORERRORERRORERRORERRORERRORERRORERRORERRORERROR ERRORERRORERRORERRORERRORERRORERRORERRORERRORERRORERRORERRORERRORER--- congratulations you have saved peach and the mushroom kingdom
i think i got banned again... I don't know if I can do TASing at the moment. May in summer or something? Soon-ish... Aka. Chuterix, formerly ChutacoackoTAS (did I even address that name?) Check out my RTA's and TASes here: https://www.youtube.com/channel/UCx6JXd3XDSkJqREaLQDYlDg P.S. I have school on weekdays unless break or something. So I will not read messages until the weekends or until further notice.
Spikestuff
They/Them
Editor, Expert player, Publisher (2254)
Joined: 10/12/2011
Posts: 6324
Location: The land down under.
Is it a geg or an ace? (don't answer it) Personal preference of the "game end glitch" branch is the other movie. In comparison between that and this in terms of entertainment, even though this is under a second. I'm voting No. Also Gremlins 2 when?
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. These colours are pretty neato, and also these.
Challenger
He/Him
Skilled player (1634)
Joined: 2/23/2016
Posts: 1033
Oh, I didn't see this coming on. This was the SMB3 history. The End.
My homepage --Currently not much motived for TASing as before...-- But I'm still working.
Memory
She/Her
Site Admin, Skilled player (1515)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
There wasn't enough TAS to be entertained. From a pure viewing experience, it was pretty much the same as if I searched for the ending cutscene to Super Mario Bros. 3. Voted no.
[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
AIVV73
He/Him
Player (76)
Joined: 5/30/2018
Posts: 12
Location: Russia
10 for technical 0 for entertaiment this should be uploaded to userfiles tbh
My name is AIVV, I'm an artist, I'm a tas artist. I'm hired to people to fulfill their fantasies, their deep dark fantasies.
Memory
She/Her
Site Admin, Skilled player (1515)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
AIVV73 wrote:
10 for technical 0 for entertaiment this should be uploaded to userfiles tbh
We have a tier for movies that fail to entertain the audience. Whether or not you feel this run is entertaining, there is no reason it shouldn't be submitted.
[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
Spikestuff
They/Them
Editor, Expert player, Publisher (2254)
Joined: 10/12/2011
Posts: 6324
Location: The land down under.
AIVV73 wrote:
this should be uploaded to userfiles tbh
No it shouldn't. Masterjun is simply showcasing a TAS and providing in the submission for something that is of a chance to see where it would go. This is also something that would affect future TASes of the same method of going about it to games that feature this. This is a fairly important TAS much like many other TASes that had something groundbreaking. This isn't something that should be placed in the userfiles.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. These colours are pretty neato, and also these.
Sand
He/Him
Player (124)
Joined: 6/26/2018
Posts: 154
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.
This is so great :)
Player (28)
Joined: 3/2/2007
Posts: 123
Location: Lake Havasu, Arizona
umm, is the emulator your using one that allows all 255 opcodes ?? because NES does "not" have STX and STY.... not until SNES at least :| only these are supposed to be valid -- http://www.obelisk.me.uk/6502/reference.html
Editor, Player (44)
Joined: 7/11/2010
Posts: 1022
kuja killer wrote:
umm, is the emulator your using one that allows all 255 opcodes ?? because NES does "not" have STX and STY.... not until SNES at least :|
There are 256 possible bytes that can be interpreted as instructions. Some of them are undocumented/disallowed but they will nonetheless do something on an actual NES. Some of the opcodes in question are unusable (due to having an effect on an actual NES that's useless or actually harmful). Some of them are unstable (they won't act reliably across different NESes, or sometimes even on a single NES). However, some of them, by chance, happen to do something useful. So you can use them for ACE if you want to. All that said, 86 STX and 84 STY are official, documented, supported opcodes; I don't think any undocumented opcodes are used in the payload of the TAS. Perhaps you had the NES confused with a different console?
Noxxa
They/Them
Expert player, Moderator (4131)
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
kuja killer wrote:
umm, is the emulator your using one that allows all 255 opcodes ?? because NES does "not" have STX and STY.... not until SNES at least :| only these are supposed to be valid -- http://www.obelisk.me.uk/6502/reference.html
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Player (28)
Joined: 3/2/2007
Posts: 123
Location: Lake Havasu, Arizona
crap crap i apoligize i wasnt paying attention. my bad. :( sorry, when i saw that graph that was posted earlier showing all 255, i accidently thought for momment it was taken from SNES or something (before i even linked to the site i showed). wasn't thinking straight, at that momment (had STZ in my head for example)
DrD2k9
He/Him
Editor, Expert player, Judge (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
This submission is an interesting case. Is viewing the result entertaining? In my opinion, No. As mentioned above, it's little different than simply viewing a video of end credits. Is the accomplishment interesting/impressive? ABSOLUTELY! Should it be published? In my opinion, yes, it should. Where should it be published? Given that it's not entertaining to watch, moons probably isn't a good location; leaving vault as the only other landing place as this is the fastest known completion of this title. This is where the case becomes interesting.... The accomplishment of this run could be argued as Star tier quality from a technical aspect, but the lack of anything visually entertaining argues against Stars. Therefore, Vault is the only appropriate publication tier based on current rules. That said, I expect argument against accepting DPCM glitch abuse into Vault.
Patashu
He/Him
Joined: 10/2/2005
Posts: 3999
I've been waiting so long for this to submitted, it's finally here and it did not disappoint at all! Definitely these kinds of TASes will cause problems for the site ruleset as is (it's not entertaining in the traditional sense but it's hugely technically detailed and it's entirely to do with playing the game and hardware as programmed, and it requires extensive research to do. But does it obsolete the game end glitch branch that already exists, despite being even less to do with the idea of playing the game? Is it it's own separate branch? What tier does it go in? Should we expect a lot of TASes in this category? etc) but edge cases like this are how we evaluate what we want the site to showcase and improve the rules for the future, so I look forward to the healthy debate that will ensue.
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Skilled player (1703)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
How many games out of the NES library have the DPCM bug? To what extent do other games affected by the DPCM bug are broken? It was mentioned in discord that SMB2(U) at least requires some setup before spamming inputs for it to work. Will other games be more elaborate, or roughly around the same length? There was also discussion there on future runs; what is the difficulty of pulling something off like this in a completely different game with this bug? Edit: Oh, and I found reading the submission notes more entertaining than the run. I do hope if more runs like this get made, they also get submitted; I know it may be controversial, but at least it serves as a record of sorts.
Masterjun
He/Him
Site Developer, Skilled player (1968)
Joined: 10/12/2010
Posts: 1179
Location: Germany
jlun2 wrote:
How many games out of the NES library have the DPCM bug?
Every game on a NES console has the DPCM bug. Not all games implement a DPCM bug workaround. And even less games have a DPCM bug workaround that can be exploited. And in most of the cases where you can exploit from the first frame of input, you're just going to end up with a crash you can't manipulate. The principle applied here is not a rare way to trigger the credits, but a rare way to trigger a crash.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Player (28)
Joined: 3/2/2007
Posts: 123
Location: Lake Havasu, Arizona
I dont really know much about DPCM romhacking-wise, but i was curious about something, do sound effects in Zelda 1 use that ?? I once implemented the "door opening" sound from Zelda 1, into my megaman 3 hack a few years ago, so that's uhh ... DPCM right ? And only if the controller is being read it'll be affected ? I use it for a couple places just only door opening scenes in Duplex Man, and Pyro Man, you do "not" have control of megaman, so controller inputs dont happen during the animation/fade out/etc or when the Zelda door sound plays, so that means it's safe ...."not" prone to the bug i assume ??
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Awesome it’s done! Looks way more complicated then expected, nice work! I really hope this one gets a console verification , doesn’t seem too timing sensitive so I’d think it has a good chance . This is the culmination of a lot effort and work from all directions, so it’s great to see it done. Hopefully some of the ideas here are more widely applicable and this isn’t just a lucky fluke (well it is one , but hopefully not the only one .) Anyway yes vote!
Active player (479)
Joined: 7/22/2018
Posts: 14
I'd like to raise a few questions here because this TAS has mixed feedback so far. I was very brave to claim this TAS for judgment. This type of TAS is something that has rarely, if not never, been seen here before. With regards to console verification, at the moment of this post, this TAS has yet to be console verified. However, it may be possible with some tweaking of the .r08/.r16m file. What do we consider as gameplay? This TAS is going to force us as a community to reevaluate this concept all together. In this submission's case, all of the work is done at the title screen. Do we consider what is being done there as gameplay? Note that TASVideos follows a strict timing rule for most TASes. It is from power-on until the last input. SMB3 follows the standard timing guideline. However, this is not true for the SMB3 RTA commnity. For the record, the RTA community for SMB3 has decided that the time starts when the start button is pressed to load the World map. Now the question is, based on those timing guidelines, which guideline better constitutes gameplay? This is not the first time when a game end glitch TAS that does not make use of a controller input payload to finish the game was obsoleted by one that does. The most recent example is Tompa's ALTTP game end glitch run, which was obsoleted by fmp, total, and Yuzuhara_3 using a four frame controller payload. Another example that comes to mind was Masterjun's SMW2:YI game end glitch TAS, which used a payload in 2-2 with multiple controllers to obsolete the old warp glitch TAS that used a glitch to warp straight to the last level of the game. While the same warp glitch was used in both TASes (Masterjun used the warp glitch to go to 2-2 instead of the autoscrolling 6-8), one of them used a controller input payload to reach the credits while the other did not. What separates those two TASes from this one is that some setup past the title screen was required to get the game end glitch to work. There were gameplay improvements in both TASes, coming from either a new route or better optimization. That brings me to my next question, which is: Does this TAS have any gameplay improvements compared to the published run? To answer that question, you will need to consider the first question too. This next question is unrelated to the others. 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? At TASVideos and especially with games like SMB3, new categories of games have to show significant differences from the existing categories in order to be accepted. This brings up the next question. Is this type of game end glitch significantly different from the published game end glitch TAS to warrant the creation of a new category? This is relatively unheard of for game end glitch TASes, but we all have to be open to possibilities. Another question does come to mind looking at this TAS from a viewer's perspective. 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 passwords are used in this TAS, but whether people find it similar to using one is a question that needs to be answered. I could see arguments that any sort of game end glitch could look like using a password to skip major portions of a game. However, it is worth mentioning that prior to the credits, Mario's face is not seen in any way, shape, or form. All a viewer sees is the curtains prior to reaching the credits. I would love to hear people's thoughts on these questions. Remember that there is no right or wrong answer to what I have asked here. All of these questions are open-ended. The decision for this TAS is going to be a very difficult one to make. The goal here is to set a good precedent for future game end glitch TASes, especially ones of this type. I do not want to set a bad precedent for future game end glitch TASes here.
Patashu
He/Him
Joined: 10/2/2005
Posts: 3999
My gut feeling is: Yes, there is a distinction between game end glitches that interact with the game's intended gameplay in some way first, and ones that don't even carry a pretense of caring about the game itself. To that end, we might ask what existing TASes might be included in this new categorization. The first one I thought of is Pokemon gen 1 save glitch ( http://tasvideos.org/2687M.html ) but even that interacts with the gameplay in a small way (re-arranging inventory and such). A2600 Superman pause glitch ( http://tasvideos.org/2226M.html ) is a pretty good candidate. It basically engages in nothing that looks like gameplay. Wizardry V save glitch ( http://tasvideos.org/3470M.html ) is another good candidate - corrupting save file and declaring the game beaten. Of course, it's unclear how much gameplay can be involved before it can be considered to engage with the gameplay - all of these other TASes interact with gameplay in a very minor way to set up their glitches or to win after doing so. This is the first one, as far as I can tell, that does not bother at all with gameplay. So perhaps it is in a category of its own after all.
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
DrD2k9
He/Him
Editor, Expert player, Judge (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Maru wrote:
What do we consider as gameplay? which guideline better constitutes gameplay? Does this TAS have any gameplay improvements compared to the published run?
In my opinion, these three questions have related answers. I feel the first two questions can be answered together: As already mentioned we typically time things from power-on for our TASes as opposed to whatever start point is used for RTA runs. (We also end our TAS timing at different points than RTA runners, but that's a bit beside the point) This standardizes the TASing approach. RTA rules, while possibly similar to our own, have rarely dictated how we assess and judge our movies here. With power-on being our start point, it's my opinion that any inputs after power-on should be considered part of 'gameplay' for a TAS even when they occur on (or even before) the title screen. Consider games in which RNG can be manipulated by either delaying title screen input or pressing buttons that don't appear to have an effect on the title screen itself. Changing these title screen inputs changes the outcome of the TAS itself and therefore is part of the TAS gameplay. To answer the the third question: Yes it is a gameplay improvement. Since I consider title screen (and pre-title screen inputs) as part of gameplay, this submission is indeed a gameplay improvement over the current publication.
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?
It doesn't necessarily have to. As the current publication is currently sitting in moon tier, it could remain there as 'fastest non-DPCM abuse' run; though it would have to lose it's fastest completion flag (which would go to this submission). If by chance this submission is deemed moon worthy, they could exist side by side. If it's not moon worthy, it can land in vault and the other run can stay in moons without obsoletion being necessary.
Is this type of game end glitch significantly different from the published game end glitch TAS to warrant the creation of a new category?
Ultimately what needs decided is if there is enough difference between non-ACE game end glitches (I don't even know if these exist), standard ACE, and DPCM-bug abuse ACE. In my opinion, the DPCM ACE is unique enough to be a separate category: Standard ACE mainly abuses RAM management through manipulation of in-game features (i.e. positioning turtle shells) to enable ACE which then yields the desired effect. DPCM ACE (at least of this type) mainly abuses the game's software workaround of a hardware bug and will likely always be on the sub-frame scale.
Since the ending is almost instant, do viewers see some similarity or resemblance to entering a password in-game to skip to the credits?
Resembling using a password or code isn't banned, just the actual use of codes/passwords. If an unintended input method is found to glitch into state that resembles/activates something in the game which can also be done by code/password it is allowed so long as the code/password itself isn't utilized. So the viewer's perspective of this 'looking like cheating' doesn't matter on whether or not it should be acceptable. As long as the submission obeys the rules, it should be acceptable. These are my thoughts on your questions. I'm curious to see other's perspectives.
MESHUGGAH
Other
Skilled player (1884)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
I'm MESHUGGAH and I approve this message TAS. Good job Masterjun, ais523 and Alyosha of course! For DPCM related questions, I think I covered all I could: Not present in BizHawk 2.3.1 > 2nd tab Subframe inputs @ Wiki: MESHUGGAH/ForbiddenTechniques
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
1 2
6 7