We actually had a very nice route idea for any%, but it would require Deku Stick on B as adault. Can somebody fix that in mupen? XD
Or at least combine the reset recording mupen with the pause bug fix mupen? That would be nice.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
If it crashes on the real N64 it's an emulation error in PJ64 and should not work in Mupen.
However, this might be a valid reason to be TASing the GC or VC version in the future as it has more interesting glitches.
If if crashes on the N64, can it really be used in TASing? Sounds like an emulation error to me.
I agree with this. It should be banned from speedrunning/TASing. People like to cheat and use the GC version for speedruns because it lets you hover with bombchus out of bounds, which causes a crash on the correct version.
What's the new route with deku stick on B, or just it's difference from the current route?
"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."
Well GC and VC are also official Nintendo versions and there it works. So I guess it depends on what your definition of error is.
VC is just 1.2 in an emulator. GC is somewhat changed, but in mupen the rom will also crash with stick on B.
Ofcourse you could go for max absurdity and TAS the VC version in Dolphin. XD
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
(Sorry if I am explaining the obvious, it's a bad habit I have)
Since emulators are supposed to mimic the consoles as good as they possibly can it's safe to say that Mupen does exactly what it's supposed to and crashes the ROM when you attempt a stick on B as adult. (Just as the real N64 crashes the game)
Since the VC and GC version does not behave like this it's a newly introduced glitch in the emulation wrapper (VC version) or in the ported code (GC version). Since either is done by Nintendo themselves it should be allowed to abuse that glitch in a TAS done on one of these versions. If the glitches currently used in the OoT run can be done on the VC and/or GC version, or this glitch saves more time than it costs to not have access to a different glitch, then it would be interesting to switch to that version for future revisions of OoT TASes.
Since the VC and GC version does not behave like this it's a newly introduced glitch in the emulation wrapper (VC version) or in the ported code (GC version).
Not necessarily. If the N64 crashes because some line of code that leads to undefined behavior is accessed, then an emulator wouldn't really have to emulate it exactly as the real console. It's not unlikely that Mupen crashes for slightly different reasons than the real N64.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
Kuwaga wrote:
Warepire wrote:
Since the VC and GC version does not behave like this it's a newly introduced glitch in the emulation wrapper (VC version) or in the ported code (GC version).
Not necessarily. If the N64 crashes because some line of code that leads to undefined behavior is accessed, then an emulator wouldn't really have to emulate it exactly as the real console. It's not unlikely that Mupen crashes for slightly different reasons than the real N64.
Since emulators are supposed to mimic the consoles as good as they possibly can it's safe to say that Mupen does exactly what it's supposed to and crashes the ROM when you attempt a stick on B as adult. (Just as the real N64 crashes the game)
But it doesn't crash the rom, it crashes the emulator, which I would categorize under bad coding. In no case should the emulator crash.
And well you could also argument that it's a hardware bug in the N64, which the developers had to work around and which was fixed in GC and VC versions. If you are a bastard like me that is. ;)
Since the VC and GC version does not behave like this it's a newly introduced glitch in the emulation wrapper (VC version) or in the ported code (GC version). Since either is done by Nintendo themselves it should be allowed to abuse that glitch in a TAS done on one of these versions. If the glitches currently used in the OoT run can be done on the VC and/or GC version, or this glitch saves more time than it costs to not have access to a different glitch, then it would be interesting to switch to that version for future revisions of OoT TASes.
Like I said it doesn't have anything to do with the roms, but the emulators. Which means you would have to run the VC emulator in Dolphin to use these glitches. Probably possible, but kinda overkill, don't you think?
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
Slowking wrote:
Warepire wrote:
Since emulators are supposed to mimic the consoles as good as they possibly can it's safe to say that Mupen does exactly what it's supposed to and crashes the ROM when you attempt a stick on B as adult. (Just as the real N64 crashes the game)
But it doesn't crash the rom, it crashes the emulator, which I would categorize under bad coding. In no case should the emulator crash.
And well you could also argument that it's a hardware bug in the N64, which the developers had to work around and which was fixed in GC and VC versions. If you are a bastard like me that is. ;)
Since the VC and GC version does not behave like this it's a newly introduced glitch in the emulation wrapper (VC version) or in the ported code (GC version). Since either is done by Nintendo themselves it should be allowed to abuse that glitch in a TAS done on one of these versions. If the glitches currently used in the OoT run can be done on the VC and/or GC version, or this glitch saves more time than it costs to not have access to a different glitch, then it would be interesting to switch to that version for future revisions of OoT TASes.
Like I said it doesn't have anything to do with the roms, but the emulators. Which means you would have to run the VC emulator in Dolphin to use these glitches. Probably possible, but kinda overkill, don't you think?
If the emulator itself crashes, yes, then it's just bad coding that happen to give the same "effect" as doing the trick on console. Sadly N64 emulation is not too great, with any emulator, I might take a whack at making a N64 TAS emulator in a year or so but I won't promise anything. (I am trying to learn how to code good emulators right now)
For the emulator in emulator, the way I understand it it's just a wrapper, not a complete emulator, either way, it's the way it's played on console so why not? :P
If the emulator itself crashes, yes, then it's just bad coding that happen to give the same "effect" as doing the trick on console. Sadly N64 emulation is not too great, with any emulator, I might take a whack at making a N64 TAS emulator in a year or so but I won't promise anything. (I am trying to learn how to code good emulators right now)
For the emulator in emulator, the way I understand it it's just a wrapper, not a complete emulator, either way, it's the way it's played on console so why not? :P
No it's a complete emulator, both with GC and VC. There are perfectly normal N64 roms in there. Funny enough the rom in the VC wad actually has the same checksum as the U[!] rom you can find on the internet. So it could very well be that Nintendo downloaded it from a rom site for their VC release, which is pretty fun imo.
These roms couldn't be played on GC or VC unless there was a complete emulator attached to them.
I guess TASing N64 in Wii cold be fun. :D Somebody should try it sometime.
But since TAS is timed from power on it would add a few seconds.
But dumps usually vary a little. So either the [!] really is a perfect dump or Nintendo just took it off the internet. It's not like they wouldn't be allowed to...
I'm pretty sure it would be really unlikely to have the same checksum if they used an old rom they had lying around. Usually at least headers or something differ. But ofcourse I have been known to be wrong. :D
Furthermore would they even have a rom lying around? If not they would have to either recompile it or dump it from a cartridge themself. We know it's not recmpiled, sicne the built date and checksum are the same...