(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/27/2019 8:13 AM
Quote
ThunderAxe31
Any
Editor, Reviewer, Skilled player (1358)
Joined: 9/12/2016
Posts: 1646
Location: Italy
Arcade TAS of 2023 Homebrew TAS of 2023 PSX TASer of 2022 Gameboy TASer of 2017
Memory wrote:
Limitations go against the spirit of vault.
Vault has more limitations than the other tiers, as it poses restrains to game choice and goal choice. The only freedom that it introduces, compared to the other tiers, is that it has (almost) no entertaining requirements.
Memory wrote:
I still don't see how this is different compared to other game end glitches. Other game end glitches have had the same sort of accusations of "this isn't playing the game, this shouldn't count". I really don't think this particular glitch is any different.
It entirely depends from the personal point of view. Anything can look either different or similar, depending on how we decide to look at it. In the end it all depends from what we want to do about it, that is, if we want to introduce a restrain to such glitches or not. And if that turns to be the case, then finding a yardstick for drawing the difference could be possible. For example, see how the full completion rules does differentiate between what is criteria reached through in-game actions and what isn't. That is indeed a complex definition, and it relies on the ability to handle each case in their uniqueness, yet it's a functional rule because it works with definite criteria that can objectively measured. 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, and that's exactly why I'm saying that there is no objective "right" and "wrong" in this debate, as it all begins from what we want to allow or disallow. I also acknowledge that my point of view does feature some downsides, as well as the fact that it doesn't seem to be shared by the majority of the people here. And in any case, despite how much I'm being dedicated to this discussion so far, I don't need at all costs to have my opinion applied to the final decision, as I could still accept an outcome that differs from what I'm expecting.
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: 7/27/2019 8:35 AM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
ThunderAxe31 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, and that's exactly why I'm saying that there is no objective "right" and "wrong" in this debate, as it all begins from what we want to allow or disallow. I also acknowledge that my point of view does feature some downsides, as well as the fact that it doesn't seem to be shared by the majority of the people here. And in any case, despite how much I'm being dedicated to this discussion so far, I don't need at all costs to have my opinion applied to the final decision, as I could still accept an outcome that differs from what I'm expecting.
From the philosophical point of view, I prefer the objectivist approach: there is one objectively correct reality with infinity of aspects, and it's impossible for a human being to grasp them all, but it's possible to keep accounting for more and more, improving your notion indefinitely. Accounting for more factors rather than fewer makes one happier, and it better fits the feelings of more people. There are objectively "right" and "wrong" solutions/answers, even though absolutely right and absolutely wrong ones are unreachable for us. Yet we can focus on everyone's priorities and come up with an answer that's as "right" as we can afford.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 7/27/2019 12:38 PM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Warp wrote:
When the encode of the run could just as well be simply a screenshot of the ending screen, perhaps some fine-tuning of the definition could be in place. I'd hate for TASes to just consists of ending screen screenshots and a note that "it can be achieved in 0.12 seconds". It would suck everything that makes speedrunning cool to watch out of it.
That reminds me of NetHack. IIRC the movie of it would be unwatchable in real time. Of course it would have lots of in-game actions and "traditional gameplay", but measuring it by real time alone can be misleading.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 7/27/2019 12:52 PM
Quote
lol_lee_lol
Joined: 3/1/2009
Posts: 64
Well that sure was unexpected. And confusing. At some point during the credits, I was wondering if we were back in April :P
Posted: 7/27/2019 2:59 PM
Quote
ais523
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
feos wrote:
Warp wrote:
When the encode of the run could just as well be simply a screenshot of the ending screen, perhaps some fine-tuning of the definition could be in place. I'd hate for TASes to just consists of ending screen screenshots and a note that "it can be achieved in 0.12 seconds". It would suck everything that makes speedrunning cool to watch out of it.
That reminds me of NetHack. IIRC the movie of it would be unwatchable in real time. Of course it would have lots of in-game actions and "traditional gameplay", but measuring it by real time alone can be misleading.
I think the NetHack TAS is comparable to the Sonic TASes that outrun the camera. "Traditional" gameplay's there, it's just happening so fast that the screen can't keep up (in the case of NetHack, because we can send input many times per frame, so even on frame advance you miss part of the action). Just like Sonic games can use a camhack to become watchable, we can use a hack to draw the "gameplay between the frames" (combined with slowing down the encoded) to make NetHack watchable. For this run, the equivalent of the camhack/slow encode is the game's memory watch (Masterjun put the memory watch in the video linked from the submission for a reason). Viewing that on frame advance lets you see the puzzle that's being solved; it's not the puzzle that the developers intended to be solved, but it's a game in its own right that's present on the (game cartridge, NES) combination. I used to play Pokémon competitively. The generation 4 Pokémon games use a 32-bit RNG for most of their random number generation. That means you can generate a lot of random numbers (e.g. by listening to the pitch of Chatot's cry, which is randomized), put them into a brute-forcing program, and discover what the RNG seed is. Then you can start planning out from there to try to end up with competitively powerful Pokémon; the RNG seed is stable enough to be manipulated in realtime. Is that intended gameplay? No, it isn't (the Pokémon Company International became aware of the technique when people started using it competitively, and gave the strong impression that they disapproved of its use in tournament preparation but couldn't figure out a way to ban it, as it was achieved entirely via normal controller inputs and could in theory happen by chance). Despite being unintended, is it gameplay? I'd argue it is; after a while I was having more fun with that than with the intended gameplay of the games, plotting out an RNG route to make the best use of your random numbers without hours of waiting was a puzzle in its own right and a game of its own (and it also ended up providing a use for many lesser-used Pokémon). Is it something that's watchable from an unmodified encode? No, it isn't, you basically need a separate screen listing what random results will generate in the near future to make pretty much any of my actions while doing it explicable. I'd argue that the situation here isn't much different. There are multiple games on the cartridge, some of which are intended, some of which aren't. The unintended games, being unintended, have a pretty terrible user interface, so a traditional encode isn't an entertaining form in which to watch them. I think it is possible to make an entertaining encode (although it'd be a lot longer than just playing through the game in realtime), just like the existing submission text is already entertaining. I think it might be a good idea to update the rules for Moons to permit runs that are entertaining when displayed in the correct way, even if a traditional view of what's happening on screen isn't enough to appreciate how they work. That would solve the problem with this game, too (and sidestep any questions about whether any categories are completed and whether gameplay is involved).
Posted: 7/27/2019 3:08 PM
Quote
Memory
She/Her
Site Admin, Skilled player (1556)
Joined: 3/20/2014
Posts: 1765
Location: Dumpster
GBA TASer of 2020 GBA TAS of 2020 GBA TASer of 2019 Exotic platforms TAS of 2018
ais523 wrote:
I think it might be a good idea to update the rules for Moons to permit runs that are entertaining when displayed in the correct way, even if a traditional view of what's happening on screen isn't enough to appreciate how they work. That would solve the problem with this game, too (and sidestep any questions about whether any categories are completed and whether gameplay is involved).
I'd argue that with the right presentation, pretty much any game/branch could be made entertaining. There are already numerous submissions where the submission notes etc. are far more interesting than the video itself, I feel opening things up in this way would dilute the purpose of Moons.
[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: 7/27/2019 4:46 PM
Quote
Memory
She/Her
Site Admin, Skilled player (1556)
Joined: 3/20/2014
Posts: 1765
Location: Dumpster
GBA TASer of 2020 GBA TAS of 2020 GBA TASer of 2019 Exotic platforms TAS of 2018
ThunderAxe31 wrote:
Memory wrote:
Limitations go against the spirit of vault.
Vault has more limitations than the other tiers, as it poses restrains to game choice and goal choice. The only freedom that it introduces, compared to the other tiers, is that it has (almost) no entertaining requirements.
I believe the entertainment requirement is the strictest requirement of all. Making a run that follows rules of Vault is not particularly difficult. Making a run that meets the entertainment requirements of Moons is difficult. In Moons you are not only allowed to, but encouraged to do what is entertaining, because if not, you do not reach Moons. In Vault, you do not care what is or isn't entertaining, merely fast. This movie does not have an unusual goal: it is fastest completion without a doubt. The game choice is also not under question. If a submission aims for fastest completion or full completion and conclusively completes its objective, I really see only two main reasons it can be rejected from Vault. The first is to fail to emulate a legitimate environment. This is almost exclusively referring to things like manipulating hardware, using bad dumps, etc. The other way is to fail to be superhuman. Using an invincibility code fails to be superhuman. Using a level select code fails to be superhuman. Being trivial to perform fails to be superhuman. Making mistakes fails to be superhuman.
It entirely depends from the personal point of view. Anything can look either different or similar, depending on how we decide to look at it. In the end it all depends from what we want to do about it, that is, if we want to introduce a restrain to such glitches or not. And if that turns to be the case, then finding a yardstick for drawing the difference could be possible. For example, see how the full completion rules does differentiate between what is criteria reached through in-game actions and what isn't. That is indeed a complex definition, and it relies on the ability to handle each case in their uniqueness, yet it's a functional rule because it works with definite criteria that can objectively measured.
Full completion is a much more complex concept than fastest completion as a whole so it makes sense in that case. I'm not in love with how complex the rule is but it's born of necessity.
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. In most TASes we have to resort to gameplay in order to finish the game. Here, we have become so powerful that we don't even NEED gameplay to finish the game when the developers expected us to go through gameplay. Yet it is not trivial to perform by any means. It is not performed using any intended codes or tricks to make the game easier. The game has simply been mastered to beyond what we have previously considered possible. My one concern would be if this would be easily replicated in other games, but it is in fact not easy to replicate as Masterjun has reassured us:
Masterjun wrote:
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.
If it would be easily replicated, it would in essence be trivial and fail to be superhuman. Gameplay requirements would be a completely new kind of requirement. It is one I fail to see the necessity of and one I do not believe people fully grasp the implications of were it to be implemented. When does gameplay start? Would it be on creating a file? If so, what if after starting the game you are immediately asked to name your character. Is this before or after gameplay started? What if a game consists more or less entirely of menus? Where does the gameplay start? Does the gameplay need to be of the same mode as that which we are intending to complete? [2609] SNES Kirby Super Star "game end glitch" by Masterjun in 00:23.03 for example gets the ending for what we consider the final mode from a different mode entirely! Would this still be acceptable? I feel this whole argument around gameplay is ultimately misguided and derived from preconceived notions of what we want TASing to be. Even if you or I might not like this, other people clearly do. There are actually people who were legitimately entertained by this movie! And currently we have a place for movies like this that might not entertain everyone but allow for fastest and full completions that are considered novel to some: Vault. Why Vault exists is because movies were considered to not be entertaining to enough of the site, but were more or less legitimate methods of completing the game. Preventing this movie from reaching Vault or separating it for the reasons I have seen listed is completely missing what is appealing about Vault in the first place!
And in any case, despite how much I'm being dedicated to this discussion so far, I don't need at all costs to have my opinion applied to the final decision, as I could still accept an outcome that differs from what I'm expecting.
While I wish I could say otherwise, I must admit, I would be very deeply disappointed in the site if this submission does not make it due to the reasons I have been seeing listed in the thread. I feel we would have abandoned what makes Vault appealing to some people to begin with and instead have turned it into another Moons tier.
[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: 7/27/2019 5:45 PM
Quote
Chamale
He/Him
Player (182)
Joined: 10/20/2006
Posts: 1355
Location: Canada
This is the platonic ideal of an Arbitrary Code Execution run - a second of button mashing, a byte of RAM rewritten, and the game is over. It's a huge programming accomplishment, but it's not gameplay. I vote yes on this run and I think it belongs in Moons, hopefully with an accessible explanation of how this is possible. However, I don't think there's much benefit from producing more ACE videos for other NES games. What if we had a rule that any% runs can't enter more than one input per frame? Would that break any runs other than ACE? We could still have a category using whatever controller port inputs break the game as quickly as possible, but whenever we use TAS tools to enter thousands of inputs per second its only use seems to be extreme abuse of ACE.
Posted: 7/27/2019 9:10 PM
Quote
DrD2k9
He/Him
Editor, Judge, Expert player (2213)
Joined: 8/21/2016
Posts: 1090
Location: US
Arcade TAS of 2023 Exotic platforms TASer of 2020 First edition TAS of 2020 Gameboy TAS of 2020 Exotic platforms TASer of 2019 Computer TASer of 2017
Though I personally see this type of DPCM abuse ACE as different to other ACE which involves game elements, others here have stated that they feel ACE is ACE regardless of how it's completed. Regardless of which of these perspectives one has, the following holds. As mentioned a few posts back:
Here, we have become so powerful that we don't even NEED gameplay to finish the game when the developers expected us to go through gameplay.
This refers to the fact that we have managed to achieve ACE using a different strategy (though still input based) that accomplishes the exact same goal as any other ACE TAS. Putting it simply, the goal is gaining complete control. Having this submission's form of input used to achieve ACE banned from Vault presents the argument that all forms of ACE should be banned because the achievement of complete control is the same regardless of input strategy. On the same token if any ACE run using valid input is allowed in vault, all ACE runs using valid input must be allowed in Vault.
Posted: 7/27/2019 9:47 PM
Quote
ais523
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
Chamale wrote:
This is the platonic ideal of an Arbitrary Code Execution run - a second of button mashing, a byte of RAM rewritten, and the game is over. It's a huge programming accomplishment, but it's not gameplay. I vote yes on this run and I think it belongs in Moons, hopefully with an accessible explanation of how this is possible. However, I don't think there's much benefit from producing more ACE videos for other NES games. What if we had a rule that any% runs can't enter more than one input per frame? Would that break any runs other than ACE? We could still have a category using whatever controller port inputs break the game as quickly as possible, but whenever we use TAS tools to enter thousands of inputs per second its only use seems to be extreme abuse of ACE.
You don't choose when to enter inputs. The game chooses when to read inputs, and will look at what buttons are held on the controller at that point. So you have no direct control at all over how often inputs are entered. As such, you'd need to word the rule more like "You can only change input once per frame", but then things get awkward because the game doesn't necessarily request input at the same time each frame. You could go for the old standby "You can only change which inputs are pressed at the start of vblank", which is what many emulators implement because it's convenient, but it's really arbitrary and doesn't have much resemblance to how the hardware works.
Posted: 7/27/2019 10:35 PM
Quote
Warp
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
feos wrote:
Warp wrote:
When the encode of the run could just as well be simply a screenshot of the ending screen, perhaps some fine-tuning of the definition could be in place. I'd hate for TASes to just consists of ending screen screenshots and a note that "it can be achieved in 0.12 seconds". It would suck everything that makes speedrunning cool to watch out of it.
That reminds me of NetHack. IIRC the movie of it would be unwatchable in real time. Of course it would have lots of in-game actions and "traditional gameplay", but measuring it by real time alone can be misleading.
With some types of games that's pretty much inevitable, eg. like text-based adventures where there's virtually no delay anywhere, so text can be written as fast as the hardware allows, or games where everything happens by clicking things on screen and there are no delays anywhere. Even real-time speedruns can be astonishingly short. For example the world record for Civilization VI is 284 milliseconds. However, in all these example cases the games are actually completed "as intended", at least in principle.
Posted: 7/27/2019 11:34 PM
Quote
Chanoyu
Joined: 1/14/2016
Posts: 100
Though I do not think the movie very entertaining in itself, it does have a high entertainment per second value. As with all ACE glitches, and maybe even as all glitches, the entertainment of them lies in, I think, in these aspects: 1) speed; 2) surprise; 3) absurdity. Bypassing the Door of Time in OoT, going out of bounds in Metroid Prime, abusing hitboxes, but also this DPCM glitch, I think they all have either nothing to do with gameplay, or they are all a part of gameplay. They all have that air of cheating associated with them, because you bypass the rules of the game as a normal player would see them. But they do not bypass the rules of the game as programmed. Getting a missile underflow or w/e in Super Metroid for unlimited missiles and the beating the last bosses quickly is fun in its own way. But it's a different kind of fun from the killing Materia keeping by combining the mechanics of poison and lucky 7777. In the case of SMB3, whether the game-ending glitch takes place at the title screen, or in a level in world 7, the one is as unrelated to gameplay as the other. The one just takes more normal (superhuman) play to get where the fun begins, or ends. In both cases slowing the movie down does nothing, there is nothing to understand when viewing without the submission notes, they are both, if entertaining, entertaining through their speed, surprise and absurdity. I cannot see the difference.
Posted: 7/28/2019 2:03 AM
Quote
DecafGrub47393
Joined: 4/23/2013
Posts: 59
Voted no. It's nowhere near as entertaining as the World 7 TAS or the ACE from AGDQ 2016.
Posted: 7/28/2019 2:14 AM
Quote
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
Flash TASer of 2022 PSX TASer of 2016
DecafGrub47393 wrote:
It's nowhere near as entertaining as the World 7 TAS or the ACE from AGDQ 2016.
You compared apples to oranges.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Posted: 7/28/2019 2:26 AM
Quote
lexikiq
She/Her
Active player (400)
Joined: 8/13/2018
Posts: 109
Location: United States of America
Speedy TAS of 2018 PC TAS of 2018
The proposals to reject this TAS seem extremely arbitrary. The only meaningful difference I see between this ACE and others is that it theoretically works in other games too but I don't see why this is relevant. I'd imagine some games have glitches or even ACE setups that are similar to other games, but banning glitches because they aren't unique sounds absurd. This is still a bug in the game's code like any other ACE, it just has to do with the workaround to a hardware bug. The arguments of not being visually entertaining don't make sense, that's what vault is for. The argument of not having enough gameplay is absurd for a website about superhuman play, as hardly playing the game at all is the peak of superhuman abilities is it not? Unless this is now "superhuman to a convenient extent where there's still a little bit of gameplay videos", in which case the TAS could just do the glitch at another point in time. For what it's worth I think this should still obsolete the previous game end glitch run, possibly with a note in the description that you could watch a little more entertaining run at [previous record]. Lastly, massive props to both of you for doing this TAS and figuring everything out. My mind was blown the first time I saw the GDQ run, and while there may not be visually much to see it was really entertaining to learn about the insane tricks used and work required to pull this off.
Posted: 7/28/2019 5:42 AM
Quote
Habreno
Joined: 5/23/2014
Posts: 162
I seem to remember someone mentioning when the DPCM bug first was recognized to be exploitable that perhaps only the fastest game completed using it would be accepted, since at this point we aren't playing a specific game, we're effectively playing the console itself as our game. This way we aren't obsoleting anything unless a different game itself allows for faster execution of the DPCM bug to credits warp. Perhaps this is something to consider? Not sure...
Posted: 7/28/2019 5:55 AM
Post subject: Yes vote, but should *not* obsolete existing runs
Quote
dwangoAC
Moderator, Senior Ambassador, Experienced player (907)
Joined: 9/14/2008
Posts: 1014
Exotic platforms TASer of 2015 Exotic platforms TASer of 2013
First, I've skimmed the thread to date and I think I have a grasp on all of the main points raised but if I've missed something please let me know. I cannot test console verification of this movie until someone comes up with a way to extract the raw button presses on a per-poll basis from SubNESHawk. Basically, we're currently using a (really basic) file format called .r08 to send a bitstream of data to a replay device. All of us struggle with it because the file on its own doesn't contain any information on various things that need to be known to attempt a console verification attempt, but that's a side conversation. The point is, I can't test this until I have something like that. I can confirm that the run we displayed at SGDQ 2016 is still functional so a sub second completion can absolutely be achieved on console. I have a very, very strong opinion on this subject that I have shared repeatedly and loudly: This run should *not* obsolete other content. This is, in my opinion, yet another example in a long line of recent examples of the need to rework our category system beyond the three tiers we have now. This is not a question of Vault or Moons, and everyone who is thinking in those terms is limiting themselves and trying to shove a square peg into a round hole. This doesn't fit neatly in anything that the site has now, and I insist yet again that we absolutely must move away from such a limiting system that excludes content that doesn't fit our carefully crafted mold. If we must shove this into an existing category I feel we should simply make it its own branch and allow it to stand. In summary, I have every belief that this run can be console verified and intend to prove that as soon as someone can provide me a file to test with, and I believe this run can and should be accepted into one of the existing categories even if it remains a strong example of why we need to take a long and hard look at better ways of handling categories so we can work past the absurdities that we keep forcing ourselves into in the name of purity.
I was laid off in May 2023 and became too ill to work this year and could use support via Patreon or onetime donations as work on TASBot Re: and TASBot HD is stalled. I'm dwangoAC, TASVideos Senior Ambassador and BDFL of the TASBot community; when healthy, I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Posted: 7/28/2019 6:23 AM
Quote
Masterjun
He/Him
Site Developer, Skilled player (1987)
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
Habreno wrote:
at this point we aren't playing a specific game, we're effectively playing the console itself as our game.
Nope. The game itself is poorly programmed. It doesn't matter if the DPCM bug even happens or if it even exists in the first place. This run would also work on a theoretical NES 2 with the bug fixed. The only reason the DPCM bug is even mentioned is because it is very likely the reason for the game to be programmed that way (however we can never be certain without asking the developers themselves).
dwangoAC wrote:
I cannot test console verification of this movie until someone comes up with a way to extract the raw button presses on a per-poll basis from SubNESHawk. [...] All of us struggle with it because the file on its own doesn't contain any information on various things that need to be known to attempt a console verification attempt
Nobody asked me! I sent you the file.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Posted: 7/28/2019 7:02 AM
Quote
InputEvelution
She/Her
Editor, Reviewer, Player (36)
Joined: 3/27/2018
Posts: 194
Location: Australia
I think I would like to give my thoughts on this topic: First of all, I must say that I thoroughly disagree with the notion that this movie doesn't feature gameplay, and that movies on the site must be required to feature some amount of it to become acceptable on the site. As others have noted, the definition of "gameplay" is far too arbitrary to describe objectively (especially since many genres of games are not considered to have any "real gameplay"). As far as I know, the decision to time all movies from power-on was made because starting from gameplay was too arbitrary a rule, and so given that I would argue that any input from boot-up is gameplay. The argument that the TAS is not really playing the game is comparable to the same argument from YouTube commenters about using glitches. As for the classification of this movie into a Tier, it is very difficult to say; Entertainment indeed meets the "Vault" category without accompanying visuals, but I would argue the technical work and accomplishments behind this are Stars-tier. Obviously for one of these qualities to drag the whole movie up to a certain tier is rather ridiculous, but it's equally true for one of the qualities to bring the whole movie down. Rather than suggest "Moons" as a compromise, I would recommend that given such an unusual pairing of qualities, the community decides which side of the coin is more important, and how such factors of a submission should weigh against each other.
Posted: 7/28/2019 7:11 AM
Quote
fcxiaopengyou
He/Him
Experienced player (558)
Joined: 7/25/2015
Posts: 123
Location: Republic of China
As long as the button can handle it, I think it's legal. Great job, yes vote.
Working on: [NES] Downtown Special - Kunio-kun no Jidaigeki Dayo Zenin Shuugou! (J) ''2 players 100%'' Plan: [SNES] Kenyuu Densetsu Yaiba (Japan) _________________ Ｍｙ　Ｅｎｇｌｉｓｈ　ｉｓ　ｐｏｕｒ．　
Posted: 7/28/2019 7:40 AM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Habreno wrote:
I seem to remember someone mentioning when the DPCM bug first was recognized to be exploitable that perhaps only the fastest game completed using it would be accepted, since at this point we aren't playing a specific game, we're effectively playing the console itself as our game. This way we aren't obsoleting anything unless a different game itself allows for faster execution of the DPCM bug to credits warp. Perhaps this is something to consider? Not sure...
Masterjun wrote:
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.
Also I find this note rather important in general:
Masterjun wrote:
The game itself is poorly programmed. It doesn't matter if the DPCM bug even happens or if it even exists in the first place. This run would also work on a theoretical NES 2 with the bug fixed.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 7/28/2019 2:56 PM
Quote
NxCy
Active player (500)
Joined: 11/19/2007
Posts: 128
TAS of 2013 SNES TAS of 2013
Haha, what a crazy 'run'. To be honest, I don't really get any enjoyment from watching the actual videos anymore for these kinds of runs. What is enjoyable, however, is reading the technical explanations for how things like this are achieved. Perhaps the best way to present these runs then would be in the form of an article/paper or explanatory video. I know that's what the submission text is for, but I think for a run like this that's all that really matters. In any case I think it should definitely be accepted. It's certainly loyal to some basic goals of TASing, e.g. beating a game as fast as possible, and it's a great technical achievement that deserves to be showcased. I just don't really care about the gameplay video and think, as a viewer, the value is more (all) in the explanation of how it works.
Posted: 7/28/2019 4:02 PM
Quote
NEVERDOORS
Any
Experienced player (518)
Joined: 1/18/2013
Posts: 59
Nintendo 3D TASer of 2023
"its good'
Posted: 7/28/2019 8:28 PM
Quote
Warepire
He/Him
Editor
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
This is so technically impressive that it required me to digest what was going on for a while. Sadly it has no direct entertainment value, but I was entertained by the technical achievement itself. Ultimately it lands on a Yes vote from me.
Posted: 7/29/2019 7:13 AM
Post subject: Re: #6466: Masterjun & ais523's NES Super Mario Bros. 3 "game end glitch" in 00:00.78
Quote
Radiant
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
What on earth was THAT? :D
Indie game developer
1 2 3 4 5 6 7