Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
feos wrote:
Looks like we need some notes about MSX too.
http://tasvideos.org/forum/viewtopic.php?p=458992#458992
It's easy to miss because of the variety of machines, so every time it should be verified explicitly that the ROM and the machine belong to the same (or compatible) region.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
When I judged this, I had both BIOSes available to me, and thus did not notice that this was an issue as it synced just fine.
It is indeed a strange issue, and I'm not sure why or how it works.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
feos wrote:
Fog wrote:
Then the issue becomes if we're branching it, are the differences big enough to warrant a branch?
I would have to say no, there.
A huge part of the audience disagrees with you.
And let them disagree with me, but if we let the audience dictate all of the rules then this site would be very different then what it is now (and not for the better).
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
feos wrote:
Fog wrote:
If this run was aiming for in-game time (hint: it's not), then your point about actual gameplay differences would mean something. But since these TASes are taking real time into consideration, both gameplay and non-gameplay elements of a run must be considered.
I'm talking about differences that can qualify for separate branches in Moons. Marginal timing differences don't matter if the run claims to become a new branch.
Then the issue becomes if we're branching it, are the differences big enough to warrant a branch?
I would have to say no, there.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
feos wrote:
I know the actual gameplay differences (which is the only thing that matters when we compare optimization attempts), and after seeing this comparison of marginal timing differences regardless of what the actual gameplay is, I state how much my opinion have changed: it didn't. And my opinion is consistent with all I've been saying in this thread:
This judgment is absurd.
If this run was aiming for in-game time (hint: it's not), then your point about actual gameplay differences would mean something. But since these TASes are taking real time into consideration, both gameplay and non-gameplay elements of a run must be considered.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
Because the mesh is visible with S-Video and RGB, and the console officially supported these two output types, there should be no reason why the original dump should not be used.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
I would like to point out that any differences between non-gameplay elements (such as title screen, loads, etc.) are not taken into consideration when judging for obsoletion.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
I personally feel that this run should be rejected according to the current rules of the website.
PAL ports of early generation console games have been consistently bad, and the rules clearly state that NTSC U/J runs are preferred over PAL:
"Console versions of PAL games run at a lower framerate than NTSC games, running at ~50Hz compared to NTSC's ~60Hz, and the games themselves are often not modified or poorly modified to accommodate to the change in timing. Due to this, PAL versions of ROMs are generally not allowed, unless there are significant technical and/or entertainment merits to using this version. See Rygar and Blaster Master for examples of good usage of the PAL ROM."
Taking this at face value, there are barely any differences between the two versions of the game. Also, the glitch in question which is used is exclusive to the PAL version of the game. It's most likely that the port of this game from NTSC to PAL has introduced this glitch, as it does not exist in the NTSC version of the game.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
My suggestion would be to default C64 runs to PAL, with NTSC only being used in specific circumstances.
All of our current publications run on PAL, having runs obsoleting them by solely being NTSC would make for some pretty bad precedents on a judging standpoint.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
owlgame wrote:
Alyosha wrote:
http://tasvideos.org/userfiles/info/40608078650579692
Here is a converson from Mupen to BizHawk for this run. I didn't see that exact plug in settings to convert with so I just used the defaults.
(I'll even submit it if you want, since it's been like a week already might as well wrap this up)
How did you convert it from Mupen to BizHawk?
I just played it back and was surprised with how well it ran. I'd love to be able to convert other Mupen runs to a native BizHawk format, since the Lua script bugs out on me often
There is a lua script provided with BizHawk which can attempt to convert Mupen to BizHawk movie files. The only game known to work successfully with it is SM64.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
Habreno wrote:
To ask a slight aside question: What about Wii U Virtual Console? Is Wii U VC accurate to original releases or are there emulation quirks with this as well? I'm aware that, as of now, emulation of the Wii U is not up to TAS standards, but at some point it is likely to be, and the question will get raised eventually.
As a slight aside to that question, if Wii U VC of an original Wii game is identical, is it okay, for TASVideos standards, to take the game and TAS it in Dolphin and ignore the disc read speed limits imposed in Dolphin or would emulating the read of the game from source other than disc (I assume console hard drive, or however you would have the game stored on a Wii U) be not allowed for TASing it in Dolphin?
In short, since we don't have Wii U emulation, assuming the Wii U "emulates" the Wii identically for Wii games on Wii U VC, and since Dolphin is an acceptable Wii emulator, are we able to substitute Dolphin for a Wii U emulator for Wii U VC games that were Wii games, and use loading times other than disc since the game isn't technically on disc?
Wii U is the same deal as Wii for Virtual Console. The Wii U version of Donkey Kong 64 runs with significantly less lag compared to the original N64 version, and contains some additional quirks.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
jlun2 wrote:
Fog wrote:
For an encoding point of view, it's better to have the credits, and we can cut out the save your progress bit afterwards (like what is done for for Harry Potter PSX)
I rather have the encode be extended with a note that the last input has been changed to show the credits rather than extend the displayed time by ~10% of the run. I have poor experience with people who seem to only look at the displayed time on Youtube at a glance, and go "your run is slower than X" without actually knowing why it was longer. Sorry.
You don't need to have any inputs with the save now screen, just end input on the last required input to get credits.
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
For an encoding point of view, it's better to have the credits, and we can cut out the save your progress bit afterwards (like what is done for for Harry Potter PSX)
Experienced Forum User, Published Author, Experienced player
(626)
Joined: 4/5/2014
Posts: 459
ais523 wrote:
I still believe this particular choice for what to include in the movie file should be flagged as a speed/entertainment tradeoff; the game's either completed as soon as it enters a postgame state, or it isn't legitimately completed at all, and adding extra input to show the credits is thus ending input late.
I'm against the idea that entering a cheat code can ever be considered part of a legitimate completion of a game. (It can be considered a legitimate way of unlocking a game mode or character, at the most, but in such a case that's happening outside the actual gameplay.)
Things become blurred when a game-end glitch is involved. In absolutely no terms is this a normal way of beating the game. However, we still need a way to show that the game considers itself beaten. The Konami code is the fastest way to do this, and can only be used once in a post-completed state.
