How are emulation differences in console and emulator handled anyway? Because I know there is a bunch for GE and PD, but those runs are never questioned. If you get right down to it, almost none of the runs done here can be done on the actual console, there's frame differences everywhere, hardly any of the NES (yes the simplest and most iterated emulator) TASes could be played back on the actual console, so those had emulation differences which could have given the runs slight advantages too by doing things which the actual console can't do.
Where is the line drawn and what is the clear rule for this? It seems like it's just what what some admin's arbitrary discretion is and what the said admin knows about the game and differences if any.
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
I can't help but feel like you're missing a rather obvious point here. If it doesn't work in the N64 version of the game on console then you shouldn't use it in a TAS of the N64 version of the game. It's not rocket science. If you think that's a dumb rule, then you're obviously unaware of what the site is for and should probably read up on it.
The problem here being, that there are no different versions of the game. Just the same version in 4 different consoles (well 3DS has a graphics overhaul and other slight changes). On N64 it crashes, but on GC, Wii and 3DS it works just fine.
Mupen is not an N64. It is just an emulator for a game, a game that supports StickB in 3 of it's 4 versions.
If it makes you happy you can file a TAS with StickB under the Wii category. But TASing it in dolphin would be stupid.
Btw. just noticed that Jabo 1.6 actually can emulate deku stick on B. Problem is different than other graphic plugins it won't just continue running when it encounters inconsistencies. It will throw an error box and pause emulation.
But between error boxes you can get input in (use stick, break stick) and if you put the stick away the game continues to run normally. Ofcourse that doesn't help with the TAS, but I thought it was interesting.
sounds like a programmer could write a wrapper for the .dll that steals the messagebox API calls to prevent that, assuming it's using standard windows stuff.
Well a programmer could also make a mupen that has the pause bug fix and reset, so we wouldn't be bound to Jabo (I explained above why another plugin would be preferable). But sadly no programmer cares for N64 TASing. :(
At least I don't know of one.
I can't help but feel like you're missing a rather obvious point here. If it doesn't work in the N64 version of the game on console then you shouldn't use it in a TAS of the N64 version of the game. It's not rocket science. If you think that's a dumb rule, then you're obviously unaware of what the site is for and should probably read up on it.
The problem here being, that there are no different versions of the game. Just the same version in 4 different consoles (well 3DS has a graphics overhaul and other slight changes). On N64 it crashes, but on GC, Wii and 3DS it works just fine.
Mupen is not an N64. It is just an emulator for a game, a game that supports StickB in 3 of it's 4 versions.
If it makes you happy you can file a TAS with StickB under the Wii category. But TASing it in dolphin would be stupid.
Congratulations. It finally seems as if you understand that such a run would have to be submitted as a run on a different console than N64.
Great TAS swordless! So many epic moments :D And the route was brilliant!
This is my first post in this thread recently, Synx, so I'm not sure what you're talking about. Yes, a run using the route other people want would mandate it being done on the VC/GC versions. That much has been said already, I was just pointing out to Slowking that TASes must be theroetically possible on the console they're done on. Since that route does not work on N64 because it requires an emulation inaccuracy, then the TAS wouldn't be accepted on the N64 version.
Congratulations. It finally seems as if you understand that such a run would have to be submitted as a run on a different console than N64.
Congratulations you managed to miss my point this whole entire time! I don't care where a run is categorized. What I do care about is trying to force people to use an emulator in an emulator or disallowing a glitch all console runners use, because it's possible on a real console.
Categorize it under "moonstones" for all I care.
ShadowWraith wrote:
This is my first post in this thread recently, Synx, so I'm not sure what you're talking about. Yes, a run using the route other people want would mandate it being done on the VC/GC versions. That much has been said already, I was just pointing out to Slowking that TASes must be theroetically possible on the console they're done on. Since that route does not work on N64 because it requires an emulation inaccuracy, then the TAS wouldn't be accepted on the N64 version.
TASes are not done on console, they are done on emulators. Here the diocy comes in, since at some point there is always an "inacurate" N64 emulator.
Tasing it in mupen means "'inacurate' N64 emulator --> game"
Tasing it in dolphin means "Wii emulator --> 'inacurate' N64 emulator --> game"
There is no difference in the outcome. With the second option, you just put an emulator in an emulator and broke everybodys CPU, yay.
Well, then it would be a VC TAS, not an N64 TAS. Part of our whole mission statement is that the games can theoretically be played back on their respective console. We'd be going against that concept if we knew it wasn't actually possible.
Is this really the case? We may somewhat be comparing apples to oranges here, but let's go back to HappyLee's latest SMB warpless submission for a minute. While basically every previous SMB run had synced when it was played back on a NESBot, that run had one specific trick that caused a desync on the console. When people questioned whether we should not accept that submission and instead request a slightly edited one that didn't use the trick and would sync on a console, the consensus formed that it was sufficient for the run to sync on an emulator and that the property of syncing on NESBot was more of an interesting footnote than a requirement.
There are a number of obvious differences here. In SMB, we're probably looking at maybe 26 frames, while in OoT, we could be talking about many seconds or even minutes. In SMB, disallowing the glitch would cause a slight deviation that could probably be hexed in, but it would mean a major route change in OoT. In SMB, the trick was a pixel-perfect glitch that no one would have reasonably tested beforehand. On the other hand, it's clearly widely known among OoT players in which versions of the game you can use a deku stick on B and in which versions you can't. It also changes a fundamental aspect of the typical RBA route that runners use these days, enough so that it's a factor in which version people would use, while no one would ever think twice about whether they can actually use the SMB glitch on a console.
Given all these things, there's still the fundamental issue here that a trick that can't be duplicated on a console would be used on an emulator run. Perhaps there's some gray area there, or maybe there's a spectrum that these two tricks are on opposite sides of. Maybe it's a judgment call as to whether we can accept runs that use these types of tricks, and that's one of the reasons why we have judges. However, the main purpose of this site is to push games to their limits and create entertaining runs. Either Ganonless route would surely do that, but perhaps the one that does it more so would be the one using the stick on B. What's the harm if the run wouldn't actually be possible on an N64, especially since it would be possible on other console versions of the game?
Is this really the case? We may somewhat be comparing apples to oranges here, but let's go back to HappyLee's latest SMB warpless submission for a minute. While basically every previous SMB run had synced when it was played back on a NESBot, that run had one specific trick that caused a desync on the console. When people questioned whether we should not accept that submission and instead request a slightly edited one that didn't use the trick and would sync on a console, the consensus formed that it was sufficient for the run to sync on an emulator and that the property of syncing on NESBot was more of an interesting footnote than a requirement.
iirc, that trick is possible on console, it didn't sync because of lag. There's a huge difference between slight timing differences and fundamental changes in how the game works.
What I do care about is trying to force people to use an emulator in an emulator or disallowing a glitch all console runners use, because it's possible on a real console.
Console runners do not use stick on B on their N64, because in fact, it's not possible.
Is this really the case? We may somewhat be comparing apples to oranges here, but let's go back to HappyLee's latest SMB warpless submission for a minute. While basically every previous SMB run had synced when it was played back on a NESBot, that run had one specific trick that caused a desync on the console. When people questioned whether we should not accept that submission and instead request a slightly edited one that didn't use the trick and would sync on a console, the consensus formed that it was sufficient for the run to sync on an emulator and that the property of syncing on NESBot was more of an interesting footnote than a requirement.
iirc, that trick is possible on console, it didn't sync because of lag. There's a huge difference between slight timing differences and fundamental changes in how the game works.
What I do care about is trying to force people to use an emulator in an emulator or disallowing a glitch all console runners use, because it's possible on a real console.
Console runners do not use stick on B on their N64, because in fact, it's not possible.
You beat me to it. This topic is under N64 and hence we discuss N64-runs. I don't mind seeing a stick on B run on wii or another console, but this type of run should not be discussed further here.
Ok, I'll explain it once again!
The GCN and Wii both emulate ocarina of time. Those consoles have a built in Mupen Emulator (not exactly Mupen, but an emulator. I use the term Mupen, though, because that will make it easier for most people to understand), that allows you to play the N64 version on these consoles.
This built in Mupen Emulator also allows you to use Stick B on GCN and Wii.
Now you guys want me to TAS this Mupen Emulator using Dolphin, although I could get access to the Mupen Emulator also without using Dolphin. Why make life harder than it actually is?
At the moment we try to stick to the rules in every single kind of situation. Rules are important, no question, but sometimes rules need exceptions or have to be modified for certain situations. It is just not possible to use them the same way for every kind of game ;)
Joined: 10/30/2011
Posts: 146
Location: Auckland, New Zealand
I know this has been said before, I'm repeating it just for the people that are taking this argument to another direction. If the trick can't be reproduced in the console, then disallow it forever and either do the run without it or do the run another version of the game, thus classifying it under another category. If someone finds a way to make it work on console without crashing, then go all out.
Why would you allow a trick for a N64 - Zelda OoT TAS that you know for sure 100% can't be reproduced on a N64 console? it's clearly a bug in the emulator, and should be improved.
Tasing mupen64 "instead" of VC on GC/Wii doesn't make sense for me, sorry. Mupen is not meant to emulate the emulator you play on Wii or GC, it's meant to emulate N64 console. I would enjoy watching both runs, but a run that isn't even possible on N64 shouldn't be published as a world record atlesat. Maybe a free run of OoT using emulator glitches, where the goal is to have a more entertaining route than the RBA route.
Slowking: Ignoring the rules for the sake of convenience is retarded. They're there for a reason.
Your trick may be possible on 'a' real console, but it's not possible on the console mupen emulates. This is the point you seem to be missing.
That said, nobody is stopping you doing your TAS of the 'entertaining route' using mupen. It just won't be accepted here.
Console runners do not use stick on B on their N64, because in fact, it's not possible.
No console runners do runs on N64 anymore, so that's somewhat of a moot point which does not counter the point that stick on B is possible on console.
Also no one has responded to my post about what the official rule on emulation differences is. Everyone refers to this rule, but what exactly is it? Because almost all of the runs on this site take advantage of emulation differences. Where is the line drawn?
Also Mupen isn't an accurate N64 emulator for any N64 game and does have attributes of the emulator which are closer to VC than N64, at what point can you take the open source code for Mupen and rename and distribute it as a VC emulator? It seems like a lot of people are creating a big fuss over rules I see no official documentation for and semantics of emulator names. I can't see any reason why all this can't be directed the same way to the NES games which can't be played back on the NES.
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
While basically every previous SMB run had synced when it was played back on a NESBot, that run had one specific trick that caused a desync on the console.
No one actually ever tested adelikat's theory. It desync'd on new PPU, which may or may NOT be more accurate. Actually, I believe I'm the only remaining person with a working NESBot. Scratch that, mine is currently in pieces. micro500, who is never around, is the only person who can test atm.
Actually, I'm starting to see slowking's point, but not in a way that will make him happy. If the VC 'version' really is just the OoT rom being emulated, then Deku stick on B should just be banned, outright. It is an emulation error. Does it matter if the emulation error is inside the Wii, which is also being emulated by dolphin?
I'll remind you, there was a Super Mario Land 2 run, as part of the first (iirc?) Dream Team Contest. It beat the game, but was determined to never work on actual hardware. That run was rejected. We strive to do the best run which, at least in theory, is playable on a console.
snorlax wrote:
There are a number of obvious differences here. In SMB, we're probably looking at maybe 26 frames, while in OoT, we could be talking about many seconds or even minutes. In SMB, disallowing the glitch would cause a slight deviation that could probably be hexed in, but it would mean a major route change in OoT. In SMB, the trick was a pixel-perfect glitch that no one would have reasonably tested beforehand. On the other hand, it's clearly widely known among OoT players in which versions of the game you can use a deku stick on B and in which versions you can't. It also changes a fundamental aspect of the typical RBA route that runners use these days, enough so that it's a factor in which version people would use, while no one would ever think twice about whether they can actually use the SMB glitch on a console.
You pretty much nailed it here. Going into a run, basing it off a trick you 100% know will not work on a console is a far different from "might not sync when playing through an NESBot-type device."
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Actually, I'm starting to see slowking's point, but not in a way that will make him happy. If the VC 'version' really is just the OoT rom being emulated, then Deku stick on B should just be banned, outright. It is an emulation error. Does it matter if the emulation error is inside the Wii, which is also being emulated by dolphin?
Something seems very fundamentally wrong to me to ban something which can be done on multiple consoles, yet things like up+down are allowed. I can't see the consistency here, what is the mission statement of TASvideos, are these view points ones which were agreed upon by the consensus of the community?
What was great about this site back when Bisqwit ran it was that he listened what each community for each game and emulator wanted to be done and catered the decisions and policies to keep the community and most importantly the contributors happy.
When you start run things with a dictatorship and ultimate everything is based of the viewpoints and values of that one individual, ban major contributors and rule against what valuable, well respected community members want, you end up losing what was once so great. You get a shit-storm mess like lybia, people defect and make their own websites, the community gets split-up, grudges are held, and ultimately the community and the viewers suffer.
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
There's a video out there somewhere of someone successfully performing a glitch that requires up+down (or left+right, I forget which) on original hardware with unmodified controllers. You just have to hit the inputs properly. That's completely different from a bug that actually crashes the original hardware.
If you want to use this bug, run the Gamecube version of the game. There is precedent for using the version of a game that has "better" behavior regarding bugs and glitches (c.f. Chrono Trigger). I have a hard time with the argument that a buggy emulator of the original hardware is equivalent to an official release on different hardware, though. To my knowledge, we have never knowingly published a run that relied on inaccurate emulator behaviors.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Where is this video? I've know you can have barely force the NES controller to do up+down, but I've yet to see it done in any sort of practical manner. That's the only original controller I know that can do up+down without breaking the controller. If you've got proof of this I'd love to see it.
I know the GE speedruns were well documented with emulation differences and were accepted.
Nevertheless, the single entity which holds the ultimate power here has said he think this glitch should not be allowed no matter what emulator you use, VC or GCN. I'm pretty sure I'm not the only that thinks that's a ridiculous extremist viewpoint. Basically the RTS of the game will be faster and use better strategies then. I don't know who is served by that decision, but clearly the runners and the viewers don't/won't like it. Why would I want to watch a slower TAS which uses inferior strategies when I watch a faster RTS nonetheless which is better.
Since all the emulators don't exactly emulate anything perfectly, what the rule that decides which emulator can be used to run which roms? If I'm not mistaken a VC emulator would run NES, SNES, N64, ect roms. So why can't Mupen be renamed and distributed as a VC emulator? What's to stop that and who's the know the difference? Couldn't everyone go home happy with that?
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
That's the only original controller I know that can do up+down without breaking the controller. If you've got proof of this I'd love to see it.
Regardless of what is possible with an original controller, it works on the console. And wtf is this about practical? Pressing a button 30 times per second is even less practical.
Nevertheless, the single entity which holds the ultimate power here has said he think this glitch should not be allowed no matter what emulator you use, VC or GCN.p
That wasn't quite what he said. And it seemed like a joke to me, anyway.
Basically the RTS of the game will be faster and use better strategies then.
Well hey, with no 3ds emulator, that will be the case anyway.
So why can't Mupen be renamed and distributed as a VC emulator?
Because it's not an official nintendo release. And if it was, you'd need to tas it in dolphin.
The electrical hardware might allow it, but the physical hardware does not. We are doing something which is physically impossible I can't be done on the real hardware.
VC isn't an official Nintendo release? And why does that matter anyway? If the RTS that use VC are so popular and all the runners use that, why shouldn't TAS be able to as well. We run hacked roms on this site which aren't official Nintendo releases which the community and contributors want to see, why is this different? Why does it have to be run on Dolphin, why can't it use a different VC emulator?
Why is it okay for some things to not be official and impossible and others not? What determines that? Why don't the community and contributors get to decisions catered to help them contribute. We all want to see a VC run, people willing to make it want to a VC run, why don't we do w/e we can to let this happen. Why are we road blocking our on community and contributors, what do we stand to gain by doing that and is it worth it?
It's looking to me like this run is just going to get done on Mupen and stick on B and won't be submitted to TASvideos, it's really not worth it. What TASvideos stands to gain by not hosting the run really isn't much.
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
The electrical hardware might allow it, but the physical hardware does not. We are doing something which is physically impossible I can't be done on the real hardware.
VC isn't an official Nintendo release? And why does that matter anyway? If the RTS that use VC are so popular and all the runners use that, why shouldn't TAS be able to as well. We run hacked roms on this site which aren't official Nintendo releases which the community and contributors want to see, why is this different? Why does it have to be run on Dolphin, why can't it use a different VC emulator?
Why is it okay for some things to not be official and impossible and others not? What determines that? Why don't the community and contributors get to decisions catered to help them contribute. We all want to see a VC run, people willing to make it want to a VC run, why don't we do w/e we can to let this happen. Why are we road blocking our on community and contributors, what do we stand to gain by doing that and is it worth it?
It's looking to me like this run is just going to get done on Mupen and stick on B and won't be submitted to TASvideos, it's really not worth it. What TASvideos stands to gain by not hosting the run really isn't much.
The problem isn't doing the run. It's not even a problem abusing this emulator bug in mupen. The problem is tho that it can't beat the current any% run, it would need to be a freerun with a goal that allows it to abuse emulator bugs to achieve a route that is not possible on the console the emulator is emulating.
The point is that it is unfair for future runs, if this emulator ever gets fixed. Also this is not even a semi-decent reason to allow it, because we already know it's not possible on the console. If this was extremely hard to verify on console, and nobody knew if it works or not, then it most likely would be an accepted speedrun(which is not the case here).
Actually, I'm starting to see slowking's point, but not in a way that will make him happy. If the VC 'version' really is just the OoT rom being emulated, then Deku stick on B should just be banned, outright. It is an emulation error. Does it matter if the emulation error is inside the Wii, which is also being emulated by dolphin?
I'm not really sure if I see fixing a hardware bug that causes a crash by an emulated hardware bug that just ignores an operation as faulty emulation. It seems to be an improvement of the N64 hardware, comparable (not entirely the same though) to an official NES emulator by Nintendo that reduces lag. A devkit should crash or throw an exception so the developers know there's some bug in their code, why would the actual N64 need to crash though as opposed to just ignore the operation? I'm not sure if you can say this VC emulation difference is clearly faulty emulation or rather an improvement or a fix.
I agree that using Deku Stick B should be limited to VC/GC runs though.
Since all the emulators don't exactly emulate anything perfectly, what the rule that decides which emulator can be used to run which roms? If I'm not mistaken a VC emulator would run NES, SNES, N64, ect roms. So why can't Mupen be renamed and distributed as a VC emulator? What's to stop that and who's the know the difference? Couldn't everyone go home happy with that?
Using Mupen as a replacement for the VC emulator is like using a bad dump of a ROM. It's not the same as the actual thing. And there is a way to use the actual VC emulator, namely through Dolphin.
If people actually think that the N64 crashing with Stick on B is a glitch that needs fixing, then I guess we need to fix OoT too before there's any point in TASing it.
Oh hey, the N64 behaves in a faulty way (crashing with stick on B) due to a programmer oversight, we should fix this because we don't like it!
But hey, OoT behaves in a faulty way (BA being one of many examples) due to a programmer oversight, but we shouldn't fix it because that's just the way the game is!
I do hope I'm not the only one finding this a horribly arbitrary point of view. And yes, you might be able to use Stick on B on GameCube and Wii, but unless you're TASing those (hint: you're not, or you're in the wrong forum) and not the N64, you should stick to what the N64 can do.
My first language is not English, so please excuse myself if I write something wrong. I'll do my best do write as cleary as I can, so cope with me here =)
(ﾉಥ益ಥ）ﾉ
