Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
OK, I've been convinced to run with my ideas. Progress updates will go here, once I've made progress. :)
My goal is to fix the desync-causing bug I described here. Emulation won't be changed and movie compatibility won't be broken. However, if you turned on FrameAdvanceSkipsNonInput under the official 1.51 release, using your old savestates (in any version) will be very risky, more so under my version.
I hope to have this ready in a week.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Sure, if you had a strong quantum computer you could feed a combination of input states into an emulator, and in one of these "universes" the game would be completed successfully in a minimal number of frames. Then it's time for you, the speedrunner, to read out the number of frames it took and the input sequence that worked... whoops! With high probability, you've ended up reading the results from the *wrong universe*, and your results are garbage.
Even taking a less naive approach, you can't solve the "TAS problem" instantly. If you didn't understand Bisqwit's post alluding to a reduction of N inputs to O(sqrt(N)) inputs to search, try reading (for instance) http://en.wikipedia.org/wiki/Grover's_algorithm to get an idea of the limits of quantum parallelism.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Dear Hero,
Does this mean the appearance a desyncless snes9x-1.51 (one of Moozooh's 4 points) is unlikely to affect your decision?
[tangent]
Sure, I'd love to see you improve the 100% run instead of taking a lengthy, well-deserved vacation from SM. But I'm also trying to decide whether it's worth my time to produce a fixed Windows binary now that I've (possibly!) discovered the source of all these desyncs. An active 1.51-TASer could be extremely helpful for making sure my changes really fix the bug (and maybe for compiling them too).
[/tangent]
Thank you regardless for your efforts to bring "perfect" SM gameplay to the world. :) That goes for the rest of you players too.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
This submission looked more precise than the published run and about equally stylish. After carefully watching both, I'm voting yes. Good job, Cpadolf.
The next time an any% run is submitted, everybody will remember the reasons behind its performance in the polls and in the judges' eyes. Thus, I think that too much attention is being paid to the route or some phantom precedents that might be set, rather than the movie's enjoyability. Moreover, it's not contradictory to think this should obsolete the published run and (probably) in turn be obsoleted by Hero's improved realtime run.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
OK, I've wanted to help with this roaring bitch of a bug for a while, and I've been testing some ideas. I'm a bit new to S9x itself, but I've learned a lot already and I really want to see this fixed.
Could any sufferers--or runners of affected games who haven't had problems--answer some questions for me?
1. Are you using the win32 version?
2. If so, had you been playing in frame advance with "FrameAdvanceSkipsNonInput" enabled?
3. If the problem can happen in other circumstances, would you be willing to help me reproduce it (starting with at most a .smv)?
Thanks!
**UPDATE** (sorry for this post's length)
OK, I have proof of the mechanism behind at least one sync bug, which I'd bet is responsible for your problems.
Experiment to demonstrate the problem:
Grab the win32 release. Turn on [Settings\Win]FrameAdvanceSkipsNonInput in snes9x.cfg. Also grab Phil's very helpful smv/savestate demo from earlier in this thread. Now use two methods to play back the movie starting at the savestate:
Method 1: File->Movie Play. While the movie is running, hit F5 to load the savestate. Simon should gracefully make it through the door.
Method 2: File->Movie Play. This time, hit the frame advance key and wait until emulation pauses at an input frame (343 / 2257). Then hit F5 to load the savestate. When you unpause, the result is definitely unworthy of Simon (and Phil/AngerFist)!
My explanation:
A core emulator function, S9xGetCPU(), notices when the game uses joypad data. It can notify the emulator (via a callback) when this is about to happen. This is potentially a great way to support frame advance, since the emulator can just stop and collect your input on the frames when it's needed.
So this is used in the Windows version, when "FrameAdvanceSkipsNonInput" is on. But it's misused: the emulator actually stops, mid-instruction, to run the full event loop until your next frame advance. You see and interact with the emulator in this state when it's paused inside an input frame. Normally this should be happening between emulated frames, not in the middle of them--that's still true during non-frame-advance play *and* while the emulator plays through lag frames at full speed. And even if you use quicksaves, the emulator is going to return to what it was in the middle of doing, so if (for example) you save a state while skipping through lag frames and reload it when the emulator is paused, you'll inadvertently put the emulator in the wrong context and cause a desync.
I'm a bit suspicious that the timing of this pause for input (relative to when the joypad state is recorded in the movie) might cause snapshots to be inconsistent with their associated movies... not so sure about that though!
Workaround: disable [Settings\Win]FrameAdvanceSkipsNonInput. You can enable [Settings]MovieNotifyIgnored as a substitute, but if I understand correctly you'll only learn whether or not a frame accepted your input *after* you've entered it... not as convenient.
Bad news:A tempting workaround is just to do all your quicksaves/loads while paused for frame advance. If the game you're running reads input from two distinct points in its code, though, the mechanism I described can still ruin your movie. I think it's less probable though.
If you use my suggested workaround (after deleting and re-creating any savestates you created under frame advance) and you still get a desync, I really want to know.
Fixing the bug: I can contribute code, but I need help from a Windows user with a windows dev. environment that can build snes9x. It looks like nitsuja has been very busy lately, so why not team up with me and give it a try?
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Abstaining from poll since I'm hardly an active member. Here's my opinion FWIW.
Bisqwit wrote:
The question cannot be "should this movie be published".
The person who votes in the poll is not a judge. They are usually able to say how they liked the movie, but they are not able to determine what is good for the site and what is not.
I disagree, because I've always considered the ideal poll question to be mmbossman's proposal: "Do you think this movie would make a quality addition to the site?"
Of course viewers can't determine what is good for the site and what is not, but they clearly can determine what is good for their enjoyment of the site. And, after all, isn't that what we want to gauge in the first place? Imagine a submitted movie which matches the high-quality entertainment of its predecessor, but is a little worse technically (e.g. slower due to fadeout lag or door transition problems). The honest answer to the current poll question would be Yes, but I think most people would agree the "correct" vote would be No.
I also think that the question of obsolescence should be polled separately (to stop it from influencing the "main" poll question, or maybe to help in situations where it's not clear which older run(s) might have to go). This change should coincide with the move to Tub's layout of the movies page, which will tip the balance between the benefits and drawbacks of separating these questions.
Finally, I'd really like to see the judges weigh in on what they want to learn from the polls which are supposed to help them gauge support for a movie.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Check whether the ROM you are trying to patch is headered or unheadered.
This does not affect the CRC32 reported by the emulator (which discards the header before calculating it), but it does affect whether the IPS patch applies cleanly or instead turns your nice ROM into garbage.
You can download NSRT (http://nsrt.edgeemu.com/forum/viewforum.php?f=14) for this purpose.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
SaxxonPike wrote:
1.51 sound crackles. A lot. Changing sound cards, changing sample rate, changing buffer size... same result. When playing anything, videos or games, it crackles. 1.43 does not.
However, it would make no sense to change versions completely if you've already started and completed any significant portion of the run in a specific version. People seem to be slowly migrating to 1.51.
In case you haven't tried disabling "sync sound to CPU", it has helped. Phil's half-right: sound emulation is better in 1.51 (at least as long as FixFrequency is off), but some computers that were fast enough for 1.43 suffer effects like this under 1.51.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Personally, I think watching baby Mario cry for 10 seconds more than negates the entertainment of seeing what the author will do to gain 10 frames outside the level. Better to tag the run with "takes no damage."
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
As long as this is turning into an orgy of solutions... http://www.zophar.net/utilities/patchutil.html includes more, even a perl implementation which is even easier than wine+lunar. :)
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
That desync happens if you don't enable left+right.
This run made me wet myself, repeatedly. Next time I want a warning label.
It's actually exciting to think that there may be a next time... but this run sets a very high standard for anybody with ambition enough to improve it.
Yes vote, and I second the idea of giving this a moon. :)
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Awesome. Does it just replace the declarations like "DUMMY(FCEUD_MovieReplayFrom)" with the obvious implementations? (I was just looking into this since micro's last post...)
My hacked mupen is pretty bad too, because I've just cheated to work around the GTK-related deadlocks.
If you've done a better job with either modified emulator, I'm interested in mooching.
In return I can fix a few more snes9x-1.51/{x11,opengl} bugs... =)
Thanks.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
It sounds like you don't have much experience with source code packages. That's okay; if you stick with Gentoo you'll probably learn. Meanwhile, try the "app-emulation/wine" package.
"winecfg" is the command to set it up.
You can then download the modified FCEU for Windows, and run "wine fceu.exe".
If the screen looks black even though the sound plays back fine, it's probably because of an obnoxious viewport bug in wine. There's supposedly a patch here, or you can try moving the emulator window toward the top-left corner of your screen.
Sorry about not answering your original question---IMO this will get you up and running more quickly. :)
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Well, yeah. More pertinently, mupen64's "input termination bug" makes it record the full input, but a low input length count (so it stops playing early). If you look at prior SM64 submissions you'll see that judges/encoders usually change the byte or two needed to fix it and we all get on with our lives.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Rikku wrote:
Sometimes I thought it wouldn’t be completed, because some things are very hard to do (eg, Tall Tall Mountain, Dire Dire Docks, etc), but finally it is done.
Excellent work. For nine straight weeks I've only doubted whether you're human. Assuming you are, I hope you've been remembering to eat and sleep!
Also...
Rikku wrote:
People I’d like to thank (in no order) <p/>AKA, FODA, Mr_Roberts_Z, Swordless Link, Mukki, Soulrivers, Holzkopp* (for hosting the WIPs), Nitsuja, Moozooh, Comicalflop, FILIM0NAS, Hopper, Spezzafer, Weatherton, Hero of the day, Andypro, YautjaElder, Stanski, Zurreco, Healblade, VANDAL, Pweisger Laughing_Gas, Chamale, Titus Kwok, AngerFist, Mwl, Tompa Twelvepack, Kirbymuncher, AQwertyZ, Mmbossman, Bag of Magic Food, Asteron, JSmith, Kirkq, Radioactive Potato, Baxter, DeHackEd, Tragedy, TheFrigz, Maza, Arne the Ass, BkDJ, Jammer01, Phallosvogel, Hb2, Supermegavkoy, KDR_11k, JXQ, Cheetah 7071, NotBowen, Hina98, Adelikat, Turambar, BoltR, Mr. Pwnage, Jweb Guru, Nitz, Wouter Jansen, Paused and Ntsujrehtona </blockquote>
I, er, did what? Did you just dump a list of posters to the thread? ;) Anyway, I'd like to thank you. Congrats on the completion, the quality, and the timing. (It's a good week for SM64.)
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Kosherbacon: Your favorite emulator might automatically apply IPS patches with the same location and name as a ROM. But if not, you can find a graphical patch tool here: http://www.zophar.net/utilities/patchutil.html
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
That's not quite true. There are areas where less exciting camera angles will give the game less to draw, reducing lag. AKA posted a demonstration in Dire Dire Docks: http://www.youtube.com/watch?v=cNQxeDYSU5Q
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Thanks for the info. I hadn't noticed the existing stereo effects until Sir VG pointed out the NES itself is mono-only... my ears are dumb. :-/
Having basically no encoding experience I can just link to anecdotal evidence that AAC-in-AVI encoding works well with AVI-Mux GUI for Windows but poorly with mencoder, in terms of compatibility with players. But the former program can fix a movie screwed up by the latter. No idea about ffmpeg, avidemux, or other encoders that natively run under Linux.
Sounds like AC3 is a fine option too, but multi-channel vorbis would be a disaster. Anyway, I think I was out of useful stuff to say before I even started this post... good luck, and thanks for encoding!
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Out of curiosity, have you played with stereo or surround sound, e.g., having audio output from the games on the right come out of the right speaker?
It might just sound awful, but OTOH it might strengthen the impression you're watching four games on four TVs all wired to one controller.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
SpiDeY wrote:
Can someone post what did he write? Some times it is just too fast to read it.
The Tetris bit in the beginning was awesome.. Obviously YES vote.
I wrote a short perl script to display the "interesting" input frames like snes9x does, and rewind too many frames you like. PM if interested.
Thanks and congrats, JXQ, for an incredible run.
