This topic is for the purpose of discussing #5000: Spikestuff's SNES Clue in 00:27.17

If this improvement is only because of an emulator switch (i.e. the 1 frame improvement cannot be reproduced in snes9x 1.43), then this is not an actual improvement and will not be accepted. (see precedent) EDIT: Spikestuff confirmed to me on IRC that this is indeed the case.

om, nom, nom... minty!

I have to say I do not think that is very good precedent. If spikestuff's run is faster (in terms of gameplay) on a more accurate emulator then it should be the one published, not the inaccurate one. It's not what can be done on snes9x 1.43 that should be the benchmark, but what can be done on console, and spikestuff's explanation make's it clear why he saved one frame. Of course this is only hypothetical without actually being tested. I would gladly send any of our amazing console verifier people a copy of this game to get it done. Pokemon yellow probably had little chance of syncing anyway regardless of core, but this is comparing bsnes and snes9x we're talking about here, I htink it's a good chance to make a new precedent.

My viewpoint here is that by obsoleting a run that has not actually been improved in itself would be unfair to the original author of the movie. And I don't see getting better RNG because of an emulator switch to be a real improvement. It's not something that was in the previous author's control. Please read the submission judgment note and the discussion topic of this submission that I linked last post. As far as I can tell, exactly the same arguments apply here.

I've read through the pokemon yellow one and I don't think the situation is the same. The difference between VBA and Gambette is not particularly well demonstrated as far as I could find, however the difference between bsnes and snes9x 1.43 is pretty plain. Almost certainly, the result in Deign's run is just plain wrong, and I don't see how you cannot obsolete an incorrect result with a correct one. (But as mentioned above this is hypothetical until tested.) The correct one is even faster by 1 frame of gameplay improvement. Being Overcome By Events is something that happens all the time. Deign didn't have control over it, but that doesn't mean its unfair to obsolete a run that is inaccurate with one that is. At worst, just put 'Deign & Spikestuff' as the authors. Assuming that it is demonstrated to be so of course, which is the crux of my argument I guess.

I wait for submission №5000 and it's not so great movie.

I've read through the pokemon yellow one and I don't think the situation is the same. The difference between VBA and Gambette is not particularly well demonstrated as far as I could find, however the difference between bsnes and snes9x 1.43 is pretty plain.

Wiki: EmulatorResources/GBAccuracyTests

Almost certainly, the result in Deign's run is just plain wrong, and I don't see how you cannot obsolete an incorrect result with a correct one. (But as mentioned above this is hypothetical until tested.) The correct one is even faster by 1 frame of gameplay improvement. Being Overcome By Events is something that happens all the time. Deign didn't have control over it, but that doesn't mean its unfair to obsolete a run that is inaccurate with one that is. At worst, just put 'Deign & Spikestuff' as the authors. Assuming that it is demonstrated to be so of course, which is the crux of my argument I guess.

There is no certainty at all that Spikestuff's run is any more right or wrong than Deign's run. bsnes is a more accurate emulator, but there is no telling at all that the RNG is the same as on console on the frame where the Clue outcome is determined in the run. As you said, a console verification might prove otherwise, but until then, stating that the RNG result in this run is correct (and Deign's is incorrect) is just guesswork. Even so, I'm still iffy about obsoleting a run by another run that only beats it by emulator switch, and not by any technical run improvement. Update the publication in some other way maybe (as was discussed in the other topic), but not obsolete it by another submission. And no, I still do not count a different RNG allowing a shorter menu option to be a frame of "gameplay improvement".

Couldn't this be published and both players made the author of the new movie? I'm sure the previous TASer would have gotten the same result, if he had used the new emulator. Both TASers have done pretty much the same work on the game, so why not publish the new movie as a team run?

Quality waste of the number 5000 on TASVideos, Cancelled for stupidity.

You have no clue. Oh, wait...

@Mothrayas: Well I definitely agree that only console verification will be definitive, just talking about it won't resolve anything. But, it seems things are more interesting then just accuracy differences. I looked into the game code a bit, and what I found is the RNG depends on uninitialized memory. Specifically, a counter at $09 is incremented from its power on position as the game runs. The game does not initiailize memory, so the chosen emulator power on state is used. Eventually, once the menuing starts, the value is used to store an RNG seed of sorts in $C3. From here various operations are done to get the game solution. You can easily demonstrate this by changing the initial value of $09 in hex editor on the first frame of spikestuff's movie, or by trace logging the game from power on, the first instruction you will find for $09 is INC Interesting!

Just a little follow up here. As Spikestuff mentioned in the submission text, selection input is only accepted on the second frame after input starts for the culprit/weapon/location screens, while movement is accepted on the first. Since you can move up,down,left, or right on each screen (the menus wrap around) this means 5 people, 5 weapons, and 5 locations are all reachable optimally in terms of gameplay. So 125 of the 324 possible outcomes are actually optimal in terms of gameplay. (Well $09 is only one byte so maybe only 256 of the total possibilities are included in the game but I didn't check.) Anyway, this means 1/3 to 1/2 of the possible solutions are optimal ones. So Deign just got bad luck that snes9x chose a bad RAM start up state, how unfortunate. Nevertheless, this is a real improvement, as it takes 2 movements to reach the ballroom in Deign's run, but 1 or fewer is optimal. It's not really a question of emulator accuracy anymore, but one of RAM initialization, which is a very different matter. @Spikestuff: would you consider un-cancelling this run given this new information? It's an interesting case and I think a good use of the 5000th submission!

I would... but...

<Mothrayas>  I still find it tenuous to obsolete a run entirely because of different rng
<Mothrayas>  I said this a million times by now and still haven't seen anything to convince me otherwise
<Mothrayas>  or anything that convinces me that the run can be counted as an actual gameplay improvement

Unless an "actual" reason to uncancel it like, a console verification:

<dwangoAC>  I do not own Clue but I do have the appropriate hardware to console verify this...
<dwangoAC>  I don't know if I want to confess that though :)

Well nothing can come of this as long as the run remains cancelled, might as well give it a shot right? I've pm'ed dwangoAC about console verification, I am willing to acquire the game at any rate. Well I think people are open to alternatives, both Agfaq and I mentioned co-authorship. In terms of whether this is a gameplay improvement or not, for this game moving the selection box on the screen is the only action, that is how the game is played. In Deign's run he needs to go to the middle box, the input for this is L,D,A, each in it's own frame as this is how the game accepts input. In Spikestuff's run, the input is _,A, as confirming a selection cannot happen on the first frame, and no movement is needed. This is the only possible type of improvement there is, as this is all the game does. So I hope this is clear at least on why the 1 frame of savings is a real savings and not fabricated by the emulator. In fact any RNG that created the situation of (U|D|L|R),A would have the same improvement, which should be about 1/3 of them. EDIT: Oh and the solution is set at the time when the game asks you to start. This is long before the final room selection where the improvement frame is.

As brought up in the second half here. Emulators are more deterministic than consoles. We are therefore more fair in terms of least amount of frame competitions. Read there for rationale. In terms of what we do on the site, our competitions are based on what the approved emulators are doing, barring anything we know for a fact is based on an emulation mistake. However doing something fixed where a console is more random is not an emulation mistake. That being said, comparing one emulator against another brings up an interesting can of worms when the only improvement is due to emulator change. I agree with Mothrayas' precedent that we should be reviewing what gameplay actually changed, and if the run is merely synced against a different emulator by minor tweaks due to whatever variations while still keeping the same gameplay, the newer version should be rejected. I do fully support of replacing the less accurate emulator submission file with the better one on the existing publication, and adding to the page's information that the new player was responsible for the update. I do want to stress that Snes9x v1.43 is a very inaccurate emulator, which even provides silly options that players check to make it even more inaccurate. I also want to reiterate that the original publication's acception was extremely tenuous. Personally I did not think the run truly warranted publication, although I erred on the side of the discussion. Seeing the ratings however, it would appear my original instincts were correct, and I probably should have rejected it. Part of what the previous run had going for it though was the dialogue the result produced. That's not true of this run, making it Vault, and this game is too trivial for the Vault. Therefore, I'd reject this for further issues on top of what Mothrayas mentioned.

<Nach> SpikedMuffin: Also, if I were you, I'd redo this TAS with lsnes, and doing so, you can probably make an even shorter movie, since lsnes doesn't have BH's silly limitation of requiring input frames to equal video frames

Well, here it is. lsnes version Prof Plum | Rope | Library I hope someone who can handle lsnes much better than me to look into the input.

^wow so fast D: I was going to try in lsnes but I quickly got lost, I guess I am too spoiled by TAS Studio. @Nach: well it is possible to get the same accusation (scarlette accusing herself) as in snes9x, you would just need the right starting value for $09 to have an optimal room. It would still contain the same 1 frame improvement. But since the published run has 17(.5) votes and an entertainment rating of 4, maybe it's not as important and it just belongs in the vault, it's still technically interesting if nothing else. EDIT: uh oh, looks like lsnes has a bad RAM initial state too (setting everything to 55) giving the rope as the weapon, oh well. Can it be set manually?

Well, looks like there is still more to consider that I initially got wrong. After reading Deign's submission text a bit more carefully, it turns out he is referring to the time needed for the animations and such to play out after the accusing is done, not just the time it takes to make them. This holds in Bizhawk too. http://tasvideos.org/userfiles/info/28692715932855699 here for example is a 3 frame faster movie that still has mustard using the knife but has a suboptimal (in terms of input) room selection. Looks like there is still more to document in this game. the first thing I will do is properly document which room goes to which hexcode, unless you already have that info spikestuff? It will still come down to uninitialized memory though, so this doesn't really address the original problem.

<Nach> SpikedMuffin: Also, if I were you, I'd redo this TAS with lsnes, and doing so, you can probably make an even shorter movie, since lsnes doesn't have BH's silly limitation of requiring input frames to equal video frames

Well, here it is. lsnes version Prof Plum | Rope | Library I hope someone who can handle lsnes much better than me to look into the input.

Wasn't there an option to disable that? I know there is at least for the GB core, since else I won't be able to copy paste input for Harry Potter.