I realize I'm late to the party, but I'd like to weigh in. I voted for "fastest" because as far as I'm concerned, syncing on the console is almost irrelevant.
Consistency is the most important criterion when evaluating a run. Suppose we have a terrible emulator that wreaks all sorts of havoc on the gameplay. (I'm having a little trouble thinking up examples, but let's say the RNG is inaccurate, text boxes don't load properly, and the game's intro sequence doesn't load properly and is skipped.) For the purposes of publishing a run, it is irrelevant that it isn't console-accurate but rather that this emulator is the standard for TASVideos. Our goal, as I see it, is to compare TASes with other TASes, not TASes with unassisted speedruns (not directly, at least). Taken to a ridiculous extreme, if SNES9x takes Earthbound's code as its input but reproduces Super Mario World on the screen, but the game is beaten as fast as possible, then that is all that matters.
With that said, the scenario cooked up by DarkKobold seems to be deliberately controversial. If a run syncs up at a cost of just 100 frames, I'd be tempted to opt for the synced version. As a matter of principle, though, I have to side with the fastest version.
Suppose we have a terrible emulator that wreaks all sorts of havoc on the gameplay. (I'm having a little trouble thinking up examples, but let's say the RNG is inaccurate, text boxes don't load properly, and the game's intro sequence doesn't load properly and is skipped.) For the purposes of publishing a run, it is irrelevant that it isn't console-accurate but rather that this emulator is the standard for TASVideos.
It was never supposed to be any close to this, and, to be honest, I was quite miffed DeSmuME was used as soon as it was (really, we could have waited another couple months for a much better version that came out in that time). In order to exploit a game and its code we need for it to be interpreted and run correctly, and for that we need correct emulation that doesn't introduce artifacts of its own.
Bobo the King wrote:
Our goal, as I see it, is to compare TASes with other TASes, not TASes with unassisted speedruns (not directly, at least).
The original notion has been misunderstood throughout the years since its original proclamation somewhere in 2004. Yes, we do want TASes to be comparable to unassisted play. No, we don't want TASes to compete with unassisted play.
TASes are more than a self-contained game-related art form; you need to think more global than that. Being comparable makes either kind of speedruns relevant to both parties, involving more people and providing a common benefit. Sticking them in the same league is, of course, pointless, but you need to understand the difference. Making them incomparable due to artifacts of emulation is not a way out of anything... whatever needs one to begin with.
creaothceann wrote:
Or you could just switch to bsnes (or SSNES, or libsnes with the SNES9x interface) and be done with this issue.
Wait... Really, we can just switch to a bsnes core with Snes9x GUI? Why haven't we done that yet? :o
It's like... we have a delicious cake already baked for us, and we just ignore it.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Or you could just switch to bsnes (or SSNES, or libsnes with the SNES9x interface) and be done with this issue.
Wait... Really, we can just switch to a bsnes core with Snes9x GUI?
I mean 'you' as in 'the members of TASVideos', i.e. including the programmers who are maintaining SNES9x builds.
You'd basically go through the code and comment out everything that accesses the emulator core, until all that's left standing is the "skin" (input/output drivers are initialized, windows and dialogs appear as usual, buttons can still be clicked etc., but all the main window shows is a black screen).
Then add the code that creates/destroys and accesses libsnes, using the source code of SSNES for comparison.
I mean 'you' as in 'the members of TASVideos', i.e. including the programmers who are maintaining SNES9x builds.
You'd basically go through the code and comment out everything that accesses the emulator core, until all that's left standing is the "skin" (input/output drivers are initialized, windows and dialogs appear as usual, buttons can still be clicked etc., but all the main window shows is a black screen).
Then add the code that creates/destroys and accesses libsnes, using the source code of SSNES for comparison.
If it is so easy, why don't you do it? You are seriously trivializing a massive amount of work.
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.
My post was about complexity, not quantity. Of course there's a lot of work, but it can be divided into these parts.
I'm not a C++ programmer, I work mostly with Object Pascal. My codebase would not find many contributors, and my GUI would be different - and at that point using SSNES would have more advantages.
I asked about bsnes a few months back
http://tasvideos.org/forum/viewtopic.php?t=11426
Ilari had a few good points, but more important than his response was the fact that he was the only one who responded. I just don't think there's much community interest here in more accurate emulation. And not to get the -rr coding work done; one sufficiently crazy dude could handle that. To get tases made! No point making bsnes-rr when people are still using snes9x 1.43 to record.
No point making bsnes-rr when people are still using snes9x 1.43 to record.
After having bsnes-rr done, the site could simply stop accepting movies made in snes9x -- that would take care of this issue.
Or just Snes9x 1.43 movies. One can tell between 1.43 and 1.5x based on the .SMV header version number field.
IIRC, there was idea to obsolete Snes9x 1.43, but nothing much came from it.
The reasons to use Snes9x 1.43 seem to be:
* The good: 1.43 has better tools than 1.5x (esp. 1.52/1.53)
* The bad: 1.43 has less lag than 1.5x (faster times / comparing with previous runs).
Or just Snes9x 1.43 movies. One can tell between 1.43 and 1.5x based on the .SMV header version number field.
From what I gather, bsnes is so much better in terms of accuracy that there seems to be little point.
Ilari wrote:
The reasons to use Snes9x 1.43 seem to be:
* The good: 1.43 has better tools than 1.5x (esp. 1.52/1.53)
* The bad: 1.43 has less lag than 1.5x (faster times / comparing with previous runs).
So one bad excuse (better tools) and a terrible excuse. Why hasn't Snex9x 1.43 been deprecated already? It stands to reason that doing so would already benefit 1.52/1.53 by encouraging further development, as opposed to forcing the developers to maintain two increasingly different versions of the emulator.
* Oh, and it is somewhat slow: You need pretty fast computer to run compatibility accuracy core (really the only core that matters with rerecording) at full speed.
