Since no one else has done so, I went ahead and uploaded a (basic, SNES resolution) encode just so those interested in watching these April Fools' submissions can easily do so.
That way my work in getting Snes9x 1.2 Re-recording and the actual patched ROM working isn't just for me.
YouTube tells me it will go live (as an unlisted video) in about 40 minutes from this post.
Link to video
Really, really wish someone would subtitle these. I want to hear reactions from real people, but I also want to understand them. That's why I love AGDQ.
Because I watched them both and checked the time on both. Timing on the latest RTA starts 2 seconds after console on, and both the end of YI2 and YI3 are more than 2 seconds ahead of the TAS by the clock given in that stream. YI4 is the about the same, and only after that does the TAS start beating the RTA (usually by 2 seconds per level, though not always.)
Also, you have a strange definition of arbitrary code execution, as the Cloud doesn't involve total control. It involves programming in an existing item, just like the orb glitch which is used in the TAS. I can't see how one is ACE but the other isn't.
Because, since the RTA being played by imperfect humans, it should not be faster than the supposed "perfect play" of a TAS. And it is trivial to compare different timings: the RTA community does it all the time.
One of the rules on this site is that a TAS must beat ALL RECORDS, including any RTA records. If it isn't doing so, that is a problem.
Comparing the two is required by the site rules.
Is anyone working on this branch now? The RTA now beats this speedrun, since it uses a Lakutu cloud (glitch) to beat Bowser much more quickly. (It saves like 50+ seconds.) Also, there are faster routes through YI2 and YI3--the RTA is faster on both of those, too.
Since the TAS is around 2 seconds faster on most of the other levels, I'd guess that a new one could beat the RTA by a minute or more, which would also beat this run by over a minute.
Sorry if I'm posting this in the wrong thread. The general thread seems to be about people asking for help with various speed runs, and I saw no mention of any WIP for this branch. (Thought it is really long.)
I'm downvoting because I don't think it should have obsoleted the previous run. Arbitrary Code Execution should always be a separate category. Always.
Heck, I'm still not sure why these don't get put in the Vault. They are speed for speed's sake, which is what the Vault is supposed to be.
I'll weigh in even though this seems to be settled. Warp is mostly correct. What we tell people when we explain this site is that we are using computers to simulate a perfect player, one unrestricted by reaction times and reflexes. We're not just putting in arbitrary input. If a robot using the real equipment can't do it, it is not a tool-assisted speedrun.
(Where he goes off the rails is complaining about the reset button. A perfect player could easily press that button. I know of a Pokemon human speedrun that involves cutting off the power and corrupting the save file. It lets you get into a glitched menu that lets you pick an option that will take you to the final room of the game. If it can be done in a real speedrun, it can be done in a tool assisted speedrun. It's only the other way around that might be impossible.)
Anyways, the question for the SNES run is whether or not our imaginary perfect player could execute these inputs. He's allowed to use multiple controllers, as has been established forever. Maybe he has perfect muscle control and can play with his toes and other body parts. He's allowed to use any controller that was authorized for the system, because a human speedrunner can use any controller.
As far as I know, there are no standard SNES controllers that directly implement those extra buttons. It would be pointless if they did, since those buttons wouldn't do anything. So our possibilities are the mouse or the multitap.
Well, the mouse is out, because you didn't confirm that it is possible to send the exact data using the mouse. To confirm that, you'd need to use a mouse as input. It is extremely likely this is impossible, as a mouse has restrictions on the kind of input it can send. Plus, as you said, one of the extra pins is always on, so you can't shut it off.
The multitap is far more promising. Could the player pull it off with 8 controllers plugged in? The much more fun arbitrary code execution branch does that, so I would think it was possible. But we should confirm. Can you do it by simulating 8 full controllers?
My understanding of this is that the answer is yes. In that case, I approve of the run. If not, I don't. Because, if not, we've been lying to people about what a TAS is.
Hence I'm okay with the SMW game end glitch, but only because I believe it is theoretically possible. But I would prefer it to be confirmed with software simulating two multitaps, like is used for the SMW "executes arbitary code" run. IN the AGDQ, it was explicitly stated that this would be possible if you had eight standard controllers and two multitaps. So it should be possible here.
What is all this talk about changing something? There's exactly one game on this site that is affected by whether or not the extra button presses count. This one. We thus have no policy on whether these extra buttons are allowed.
Up+Down and Left+Right do not count. They are possible on a real controller. You just have to press really hard. That's not intended, but no one is arguing that the extra buttons shouldn't be allowed because they are unintended. The argument is that they are not possible for a perfect player playing perfectly with no speed restrictions.
Now, whether this is true, I don't know. I know you can't with a standard SNES controller. I know you can't with the SNES mouse, since the mouse cannot do every pin combination. (For one thing, one pin is always active to indicate that it is the SNES Mouse). I think it's unlikely to be possible with the SuperScope, since I believe it also has a pin that is always on. The one that is most promising is the Multitap.
I don't know how it works, but the most obvious way would be for it to use all the pins. If so, since Multitap support exists in the emulators used on this site, it should be possible to use that to handle the extra pin inputs. If you can do that, you've proven it can be done. And then there's no longer any debate.
If you can't, then the question becomes "What is a TAS?" The explanation I've always seen given is the one I mentioned above: that of a perfect player playing perfectly with no speed restrictions. IF so, then I agree that, if it's not possible with an official SNES peripheral (whether Nintendo or third party), it doesn't count.
And, if it is hosted on this site, the description needs to indicate that it is using a nonstandard controller. Heck, if it's using anything other than the SNES Controller, I'd say you should mention it. (Currently it doesn't even mention the Multitap, which I know is required.) Even if you disagree with me on everything else, why wouldn't you want to mention that you used a special controller? Doesn't that make it cooler?
The reason this submission doesn't obsolete the 11 exit branch is that it's assumed that you cannot use ACE in that branch. ACE is a separate branch for this game, meaning that all other branches are inherently "no ACE."
ACE is already automatically excluded. And the "game end glitch" run is not an intended path. So those aren't the problem with the name.
The only problem then that I see with the 11-exit branch is that it would be conceivably possible to create a game that still did 11 exits, but not the exits intended. That's why I would go with "shortest intended path."
If you don't think that "no ACE" can be the default, then just add that on to the end. "shortest intended path (no ACE)."
Since this is a Gruefood Delight submission, I do think this should have an encode. Obviously it would have to be truncated. All you need to see is one run where the Hammer Bro. died and one where he didn't.
Though there is a 10 hour version of Nyan Cat, so you could just let it run that long. Or you could get creative with editing and go all Zeno's paradox on it. (Have a timer onscreen and accelerate the video until you get so fast there's only one blurred frame, calling it "infinite speed" and having the infinity symbol on the clock.)
I know this is old, but since you deliberately made the movie longer to make it more entertaining, it needs the category about speed/entertainment tradeoffs.
Was this submitted under the old system? Because, under the new system, I don't see why this wouldn't pass. We decided that not being entertaining was only a downside to certain categories, and that technical feats could stand on their own.
I also don't understand the idea of having a movie that was rejected actually published, with rendered videos.
If it's designed properly, it should fall back, dropping frames if you don't have enough bandwidth. YouTube already drops frames now, so it shouldn't be too hard.
Of course, that might suck for TAS footage, since 60fps won't need the fancy filters we use, and so transparent things may go invisible or stuff like that. Maybe we should upload both.
I mean, especially since there's going to be a huge backlog of TASes that are only available at 30fps. Since the 60fps versions are already rendered, it won't be too hard, but it still will take a while. If we keep both, we won't have to delete any videos.
I'm also not sure this shouldn't be a separate thread. Maybe once YouTube actually enables 60fps, we can have a new thread.
And now I'll voice my worry with the tier system. If every speedrun is going to get published, no matter how entertaining, I'm worried this will result in fewer people making speedruns with entertainment in mind. There's only so much time in the day, after all.
You've mentioned a form of gamification where you reward people who make the most entertaining games with a higher score of some kind. That's good, but I think you might want to go a bit further, and actually make a point to recognize people who have really high scores. Something like a list of the top 10 TASers. Or if you want to be less competitive about it, just occasionally have a "featured TASer" on the main movie page that's selected from amongst the top TASers that are still around.
If the point of the site is still entertainment, then we need to reward the most entertaining TASers.
I think this is the wrong way to go. If the run is the fastest run of a certain game, it shouldn't matter if it tried for entertainment or not. Sure, it should be obsoleted later if a faster run is made, but until then, it is still the current record holder and should be placed in the vault, since that is where unentertaining fast playthroughs go.
It makes sense for us not to accept any new vault entries that make entertainment tradeoffs, as that means they cannot be the fastest. It does not make sense to unpublish current runs that make entertainment tradeoffs, if, as of now, they currently are the fastest. And it definitely does not make sense to create a tier for a type of movie we apparently do not want more of.
Just treat the entertainment tradeoff in an unentertaining movie as a flaw that needs to be fixed for the next run.
(My idea also has the advantage of making less work for the judges. If it published before and is the fastest current run, it stays in, no questions asked.)
There are runs of much more complex games on the site that are much more boring. At least this one has to move in more than one direction. The only boring part is after input has ended, and E.T. has to wait there for so dadblasted long. But it's far from the first boring ending sequence.
Yes, this doesn't have as much gameplay as, say, an NES game. But if that was going to be your criteria, why would you accept Atari submissions at all?
The game makes short work of a game that most people hate because it's so frustratingly hard. Definite Yes vote.
Please un-obsolete this. It doesn't in any way use the glitch that allowed the subsequent run to be obsoleted. It actually plays through the game, avoiding the so-called "pipe-glitch" (which really should be called a "glitch world" glitch.
Heck, go ahead and work on them ahead of time if you want. But don't submit them. Talk about them in the forums. Ask people to look at them. But don't submit them until some people say it looks good.
You can wind up banned for too many frivolous submissions, and I'd hate to see that happen. Your idea even sounds interesting. But it needs to wait until you have an understanding of what people on this site want.
Exactly. This is not a personal pet project, nor a commercial emulator. It is an open source project. The programmers are not in any way better than any other person on the team. We are all equal. All input is equal. That's the point of free software.
I personally don't care about the emulator name, but I find the attitude here disturbing. There is absolutely no lack of respect in trying to contribute to an open source emulator by trying to get a better name for it. And the code does not belong to you because you coded it. You released it under a copyleft license--it belongs to everyone.
I understand that some people might want it for nostalgia's sake, but it's pretty annoying and seemingly pointless, and I would like to be able to disable it. I can't figure out how to do this.
If this can't be done currently, please add an option to just give a plain black screen, or even just use the window chrome.
Bilinear can be done for free by the video card, or with very low performance impact on the CPU.
And yet they removed it because AMD GPUs were apparently "suffering". So by auto-hiding or hiding the task bar, I can use 3x scaling? Why I can't manually adjust the window size to anything I want is beyond me (I don't care about accurate pixel aspect ratio).
Jesus, dude. I never said that.
We are emulating old consoles. Most of us prefer to see pixels rather than blurry crap. Bilinear can be done for free in the video card. We can probably make it an option. I never said we wouldn't, just that we didn't realize anyone actually wanted that functionality.
What I meant was that it was actually difficult to disable bilinear on AMDs, because of an oddness with AMD drivers.
We've tried to be helpful and we're working to address some of your issues. In response you've just been combative. So.. thanks for that.
No, you said to discount everything vecna said, and vecna is the only one who said that bilinear filtering was an easy thing to add that you didn't realize people actually wanted.
In general, when someone gets upset with you, the problem is that you miscommunicated.