I thought the castle was made up of three entirely separate areas. However, I do know from my own programming experience that it's sometimes better to have objects and area's loaded way off-screen, then move and manipulate them on screen once the player achieves certain conditions.
I thought the castle was made up of three entirely separate areas. However, I do know from my own programming experience that it's sometimes better to have objects and area's loaded way off-screen, then move and manipulate them on screen once the player achieves certain conditions.
It is, but when you exit a course you appear in the lobby.
So he goes up the stairs, then out to bowser in the dark world hallway, then over to the ledge.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
So now begins the debate: Does a VC-only glitch count towards reducing the A press count? The run would freeze on N64, but play back fine on emulator / virtual console.
If Dolphin's tools were good enough you could try to reproduce it there. I strongly doubt that's worth the time/effort though, especially considering how much less mature Dolphin is when it comes to TASing tools.
My thoughts on the situation of whether it counts probably puts me in the minority, but I'd say no. I hate the fact that Virtual Console can be used for speedrunning when other emulators can not, especially when the whole reason it works is that the emulation is subpar.
Does anyone actually know why emulators don't crash when the camera goes OOB?
I think it's because if the camera's position is too large a value, it will overflow an N64, but not a virtual console, because it has more memory and more modern memory management.
Does anyone actually know why emulators don't crash when the camera goes OOB?
I think it's because if the camera's position is too large a value, it will overflow an N64, but not a virtual console, because it has more memory and more modern memory management.
Going from a N64 to a VC version of the same game does not change the memory layout or give the game more memory. (This was way, way before console games were designed to be able to handle arbitrary amounts of memory, and no one would ever write a camera's co-ordinate system to have arbitrary sized memory for its numbers, because that is hugely over-engineered. Besides, why would the camera's position overflow if Mario's position is not overflowing?)
I think it's actually to do with exception handling. In general, emulators of games crash on less kinds of invalid instructions/operations than the actual console does, unless coded extremely accurately. Maybe an out of bounds camera causes a floating point exception, or something like that.
Answers to questions like "how few times can we press A in SM64" have answers relative to (ROM, execution context) pairs. There's no such thing as a "correct" pair, and when different pairs give different answers, run authors must make a decision about which pair to use.
In general, it seems like people like it when we pick pairs that have been "officially released". Sometimes what that means is unclear, but at least with a first-party Nintendo game there's not much ambiguity there.
However, almost all of the runs on this site actually fail to answer questions relative to such pairs - only a few runs have been console verified, and it is unclear how many depend on emulator-specific behaviors. Out of necessity, we have generally accepted that our emulators are good enough.
So, I'm personally fine with answering this question in the execution context of "the best available BizHawk core", especially because it seems clear that in all known ways, that core is equivalent to an officially released context, the Wii Virtual Console. Given that Dolphin isn't good enough yet and we have no console verification tools for the Wii, this seems like the closest we can come to matching a released context with the tools we have.
However, a fine argument can be made that we should really be targeting the physical N64 as our execution context - after all, we DO have console verification tools for that, so even though our emulators can't replicate its functionality exactly, we can still find the differences and verify that we've successfully avoided relying on them.
In the end, both choices have claims to legitimacy, and no one cares enough to make both TASes. So someone has to just choose, and by default that is the people doing the TASing, and they can make the choice however they want. I hope they pick the one that results in the more entertaining video.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I'll briefly weigh in with what I've said in the past: the emulator is an intrinsic part of the TAS. It's not about what can be accomplished on the console, it's about what can be accomplished on the emulator. In addition, the best and most preferred emulator offers the closest emulation of the console, so we will inevitably drift toward TASes that are more console-accurate, even if today's TASes aren't.
So I say let emulator-specific glitches stand. To do otherwise invites a slippery slope argument towards invalidating any TAS that can't be console-verified. After all, if a run desyncs on the console, that means the emulator "glitched" in a way that the console didn't.
(Also, get back to TASing, Personman!)
I'll briefly weigh in with what I've said in the past: the emulator is an intrinsic part of the TAS. It's not about what can be accomplished on the console, it's about what can be accomplished on the emulator. In addition, the best and most preferred emulator offers the closest emulation of the console, so we will inevitably drift toward TASes that are more console-accurate, even if today's TASes aren't.
So I say let emulator-specific glitches stand. To do otherwise invites a slippery slope argument towards invalidating any TAS that can't be console-verified. After all, if a run desyncs on the console, that means the emulator "glitched" in a way that the console didn't.
(Also, get back to TASing, Personman!)
Not really, it could just be due to lag frames or other timing differences.
I'll briefly weigh in with what I've said in the past: the emulator is an intrinsic part of the TAS.
The process of making a TAS input file on emulators is an intrinsic part of making the TAS input file for emulators. Couldn't you in theory have tools that let you make input files for consoles that does not require any emulators?
Bobo the King wrote:
It's not about what can be accomplished on the console, it's about what can be accomplished on the emulator.
If this was the case, then shouldn't TASvideos sort their forum based on emulators->games instead of consoles->games?
Bobo the King wrote:
In addition, the best and most preferred emulator offers the closest emulation of the console
Best and most preferred emulators doesn't automatically imply closest emulation of the console? I can think of situations where the best and most preferred emulators would be able to avoid certain crashes from the original console or just reduce loading time.
Bobo the King wrote:
, so we will inevitably drift toward TASes that are more console-accurate, even if today's TASes aren't.
This isn't guaranteed unless best and most preferred emulators imply better console-accuracy.
Bobo the King wrote:
So I say let emulator-specific glitches stand.
Arn't emulator-specific glitches -> emulation inaccuracies by definition? Wouldn't it be better to strive for runs that could be run on the actual console instead of an arbitrary emulator? The most inaccurate emulator could have the fastest run possible.
Bobo the King wrote:
To do otherwise invites a slippery slope argument towards invalidating any TAS that can't be console-verified.
No? It only invalidating any TAS that either use known emulator only tricks, or any TAS that doesn't play back on console. Certain runs might get invalidated when there are console-verification tools for these games.
Bobo the King wrote:
After all, if a run desyncs on the console, that means the emulator "glitched" in a way that the console didn't.
Exactly? And shouldn't the console be the standard the runs (and accurate emulators) should try to achieve?
I feel this discussion could be had in a better thread.
To do otherwise invites a slippery slope argument towards invalidating any TAS that can't be console-verified.
No? It only invalidating any TAS that either use known emulator only tricks, or any TAS that doesn't play back on console. Certain runs might get invalidated when there are console-verification tools for these games.
From what I understand, that's exactly what he meant. And I think it would be a terrible idea to reject runs because they don't play back on console (I'm pretty sure this isn't the site policy at all, as several game end glitch TASes have been published despite the console verification failing).
To me though, there's a major difference between a TAS that doesn't play back on console and a TAS that uses a emulator-exclusive glitch. One of the goal of TASes have for a long time (if not always) been to create the "theorical maximum", the perfect run that could be performed on console. Anyway, emulator-only glitches have been frowned upon for a long time now, and I don't see any good reason to change this rule.
Now more on topic, about using VC/emulator-only glitches, I think it's fair only if you actually emulate the VC ROM (i.e play it on Dolphin which as far as I understand isn't possible?). So it should be documented, but I don't think it should be used on a emulator supposed to reproduce how a N64 run the game.
I problably made mistakes, sorry for my bad English, I'm French :v
From what I understand, that's exactly what he meant.
My bad in that case. I thought he meant that we automatically had to reject all runs that can't be console-verified as in not having any way of testing it for certain consoles. My point was that these runs arn't automatically rejected because of this. Only because of known emulator bugs. This doesn't mean that the run can't be rejected later if/when we have methods of testing the run on consoles.
If someone wants to make Super Mario 64 TASes and use known emulator inaccuracies then I have no problem with that. I just don't think it's fair to claim that these TASes represent the real console. And at the very least can't compare the run to runs that avoids known emulator inaccuracies.
Therefore my opinion is that emulator inaccuracies shouldn't be able to reduce A-press counts for Super Mario 64. If we were to accept emulator only tricks, we might aswell develop/modify an emulator to allow us to beat the game with 0 A-presses.
Therefore my opinion is that emulator inaccuracies shouldn't be able to reduce A-press counts for Super Mario 64. If we were to accept emulator only tricks, we might aswell develop/modify an emulator to allow us to beat the game with 0 A-presses.
But such an emulator would be less accurate and therefore would not obsolete the current effort, made on a more accurate emulator.
To rephrase my argument above, emulator accuracy is of primary importance, speed is secondary. To use the fancy notion of Lexicographical order, the ordered pair looks roughly like this:
(emulator choice, speed)
So suppose we have a run on SNES9x v. 1.43 in 12345 frames. We then have
(BizHawk, 12000) > (BizHawk, 12400) > (SNES9x, 12000) > (SNES9x,12345)
where > denotes the preferred movie to be published is on the left. A run that can be console-verified would trump all, but if it can't be console-verified, what's important is that we used the best emulation we had available.
Truth be told, I think the actual situation is far more complicated because a terrible run on a superior emulator is still a terrible run. I also think entertainment should be a factor, but that's a whole separate issue entirely.
comparing accuracies between diffrent emulators sounds very arbitrary. What if the most accurate emulator only had 1 inaccuracy that let you beat the game super fast or with 0 a presses? Who should decide (arbitrarly) which emulator is the most accurate?
Also, as far as I know, SoulCal have a controller that plays back N64 games from input file on consoles. And as far as I know, it played back several Super Mario 64 runs on N64 already.
Do you still think that this trick that would crash the N64 should be allowed to reduce the A press counts? Because that's what it sounds like to me...
Arguing that it's possible on Wii's VC would only reduce A presses for Wii's VC runs.
I think using emulators should be considered tools when making TAS inputfiles for runs that can be verified on console. If you use a more accurate emulator you're just using a better tool for your tool assisted run. If you're aware of flaws in the tools you use, then you have to adjust how you use the tools.
Joined: 6/23/2015
Posts: 22
Location: United States
Hophoolio wrote:
comparing accuracies between diffrent emulators sounds very arbitrary. What if the most accurate emulator only had 1 inaccuracy that let you beat the game super fast or with 0 a presses? Who should decide (arbitrarly) which emulator is the most accurate?
Also, as far as I know, SoulCal have a controller that plays back N64 games from input file on consoles. And as far as I know, it played back several Super Mario 64 runs on N64 already.
Do you still think that this trick that would crash the N64 should be allowed to reduce the A press counts? Because that's what it sounds like to me...
Arguing that it's possible on Wii's VC would only reduce A presses for Wii's VC runs.
I think using emulators should be considered tools when making TAS inputfiles for runs that can be verified on console. If you use a more accurate emulator you're just using a better tool for your tool assisted run. If you're aware of flaws in the tools you use, then you have to adjust how you use the tools.
I completely agree with this. You could make an emulator with perfectly accurate lag, but screw up the exception handler and allow ACE on every game. Glitches due to emulator inaccuracies really shouldn't ever be considered part of the game. Wii VC is a little different because it'a an official emulator, but in that case, it's really just a very similar remake of the original game. Wii VC Super Mario 64 is a separate game from DS Super Mario 64 and N64 Super Mario 64. As for the SA entry in ABC 100% TAS, I don't think it will be included. Plush and I are both against it. Ultimately pannenkoek's opinion matters the most, but I think he's leaning towards no as well.
It's definitely a cool trick however, and is a great example of how the smallest discrepancies in emulation can make a big difference. Pan did a great job planning and executing the route; anything involving PU strats is a lot of work. Hopefully we can find a lower speed strat that will put this all to rest.
comparing accuracies between diffrent emulators sounds very arbitrary. What if the most accurate emulator only had 1 inaccuracy that let you beat the game super fast or with 0 a presses? Who should decide (arbitrarly) which emulator is the most accurate?
Also, as far as I know, SoulCal have a controller that plays back N64 games from input file on consoles. And as far as I know, it played back several Super Mario 64 runs on N64 already.
Do you still think that this trick that would crash the N64 should be allowed to reduce the A press counts? Because that's what it sounds like to me...
Arguing that it's possible on Wii's VC would only reduce A presses for Wii's VC runs.
I think using emulators should be considered tools when making TAS inputfiles for runs that can be verified on console. If you use a more accurate emulator you're just using a better tool for your tool assisted run. If you're aware of flaws in the tools you use, then you have to adjust how you use the tools.
I completely agree with this. You could make an emulator with perfectly accurate lag, but screw up the exception handler and allow ACE on every game. Glitches due to emulator inaccuracies really shouldn't ever be considered part of the game. Wii VC is a little different because it'a an official emulator, but in that case, it's really just a very similar remake of the original game. Wii VC Super Mario 64 is a separate game from DS Super Mario 64 and N64 Super Mario 64. As for the SA entry in ABC 100% TAS, I don't think it will be included. Plush and I are both against it. Ultimately pannenkoek's opinion matters the most, but I think he's leaning towards no as well.
It's definitely a cool trick however, and is a great example of how the smallest discrepancies in emulation can make a big difference. Pan did a great job planning and executing the route; anything involving PU strats is a lot of work. Hopefully we can find a lower speed strat that will put this all to rest.
Or another tech to prevent the crash. Though the best way to come up with them is figure out what causes the crash, AFAIK this is still not known. Though I'm aware you may correct me on this. Or find a way to jam the camera.
As for emulator bugs, consider this. What if someone TASed using an emulator with obscure bugs they put in on purpose?
