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
OK, looks like the first release really will be ready this weekend. :) This version doesn't change how "smart" frame advance works, but instead shields it from the situations it mishandles. Obviously I'm not hoping for this to be part of the next official release.
Temporary new feature: "fast forward to frame". That should give you a way to overwrite your savestates with correct ones, other than loading up a movie and hitting frame advance 100,000 times.
I mostly just need to test it more before releasing. The workaround did its job from day 1, but it created several bugs at first.
Goal for v2: replace the "smart" frame advance code (which won't ever work right) with movie rewind support. Then the feature is trivial to add, robustly this time. The frame advance-advance-rewind sequence will probably look stupid, but contrast to how the workaround release has to misbehave:
* You won't be able to record actions like ending a movie's input or recording a reset the way you did before, or they will happen a frame late.
* If you close the window in frame advance, the emulator will have to finish up the frame. Under wine a nasty graphical glitch results (bits of SNES graphics plastered onto my menu bar). I am afraid that it might crash under Windows.
Thanks for your patience phil (and anybody else watching). Let me know if you have any suggestions.
This is very interesting. Movie rewind is a very useful feature by itself, and I would love to see it as well.
Will the v1 be fully useful without desyncs nor additional bugs?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
The main use of this version will be to answer exactly your question. Like I've said, going back to 1.5/1.501 or 1.4x style frame advance--and re-creating your savestates--completely avoids the bug I'm fixing. And you can even get 1-frame-late notification about ignored frames under 1.51, so for instance during fadeout lag you could hit save-advance-save-advance... and know exactly when to reload and resume input.
Which reminds me, if you hit save-reload-save-reload (nothing else) in "desyncless v1", it will advance one frame each time because of how the workaround works. Another reason I won't consider the code correct until it's scrapped in favor of rewind.
But I've heard nobody say "wait a minute, I never turned on that setting" to me or "wait a minute, my desyncs aren't related to fadeout lag" to Phil or Hero. So I'm pretty confident about my work!
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Works for me with wine-0.9.45. In fact the graphical problems I'd had running 1.43+ v10 seem to be gone! I am also building 1.51 with MinGW. But if I weren't trying to work on a fixed Windows version I'd definitely be using a native Linux build.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
http://www.fileden.com/files/2007/9/22/1451488/snes9x-1.51-nitsujrehtona-v1.zip
Includes source-code diffs from vanilla 1.51.
"Fast Forward to Frame" is under the file menu.
Please back up your work (or play?) before using it. Please expect desyncs if you load a savestate created with the unmodified 1.51.
In general I'd like to know if this holds up better than the unmodified 1.51. I'd appreciate it if people could try abusing it in these specific ways:
1. Go into frame advance (with--not to get too repetitive--[Settings\Win]FrameAdvanceSkipsNonInput = TRUE), hit the button to create a savestate, and (ignoring the "Action deferred" message) close the program.
Tell me what happens (including whether it's able to save the file).
2. If you TAS with this, keep an eye out for one-frame "seams" in rerecords or reset-records. The nature of the workaround makes the emulator less responsive to some things you'll want to do.
Thanks for testing. :)
I still have the same desync problems with SCV4.
Anyway, that "FrameAdvanceSkipsNonInput", by default, is set up at FALSE. So I guess it's not the problem. And yes, I did tested with "TRUE" and no differences.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Now you tell me you had it turned off!! ;)
You are right: this proves there is another desync-causing bug, which I haven't found. May I waste your time asking questions (instead of wasting your time with a "desync fix" that doesn't work)? You are much more successful at triggering this bug than I am.
OK, here goes.
* Just to be sure: had you never set the option to TRUE before?
* Are you still (90%) sure the problem only happens if you use savestates during fadeout?
* Is it easy for you to reproduce the desync with clean savestates?
That last point is key, because that's what I have to do before I can figure out what is going on. Your SCV4_desync.zip, for instance, was helpful but not enough information to make a diagnosis. The out-of-sync savestate took 984 rerecords to make, and without all those steps I can only make savestates that stay in sync.
Anyway, I'll keep looking. If you can help, great. If you only run into the bug doing complicated stuff, I can make a "spying" version of snes9x which records every little thing you do. Maybe that would help?
Yes, sorry. I didn't know what it was and didn't see it in the GUI, maybe it's hidden somewhere but was to lazy to search. So when I saw "= TRUE", I did guess I should check in the .cfg file. And it was set to FALSE and that feature is experimental. So, it's probably not in the GUI itself.
nitsujrehtona wrote:
* Just to be sure: had you never set the option to TRUE before?
No, like I said, I didn't know it exists and even if so, I wouldn't use it. It doesn't interest me and each frame is important when making a movie.
nitsujrehtona wrote:
* Are you still (90%) sure the problem only happens if you use savestates during fadeout?
Now, I'm still sure it isn't when using savestates during fadeout but I am 80% sure it's related to fadeout or some sort of lag. Using savestates during fadeout does indeed desync but using savestates while playing/recording a movie before a fadeout does indeed desync the movie. The trick is to save/load after a fadeout.
* Is it easy for you to reproduce the desync with clean savestates?
Really easy, well, in SCV4. We've got troubles at beginning of stage 2 because we use savestates before and during fadeout between stage 1 and 2. It took 2 days to fix the thing. Because we wanted to not lose a single frame because of desync and such while making the movie playing correctly. It was really annoying but now it's ok. I am afraid we will encounter such problems at beginning of other stages. I think it is worse if the fadeout is long.
An easy way to reproduce it is to record a movie and stop at stage 2-2. Then play the movie in read only then save and load before the boss at stage 1 then immediately load it. I am 100% sure it will desync. If not at the boss, it will be at start of stage 2.
nitsujrehtona wrote:
Anyway, I'll keep looking. If you can help, great. If you only run into the bug doing complicated stuff, I can make a "spying" version of snes9x which records every little thing you do. Maybe that would help?
I think my explanation to do it should help. Otherwise, I can send you the WIP. If you still fail, then you may do that "spying" feature but I doubt it will help you since it's rather simple as how to do it.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
This is just a guess, but we've been incredably bad about keeping state info up to date with each version. We've had save state info for certain chips added years after we added support for that chip.
Since we made a major overhaul to the sound code in 1.5, I think it may be worthwhile to check if we're using any new variables there that aren't being saved.
I could be way off, but save state save and load causing a desync by itself sounds like a situation of not saving everything.
Although it'd be crucial to double check that the save and load is causing it, and not a save by itself, since if a save by itself is causing it, it means the bug is in the save process modifying something it shouldn't, without restoring it when the process is completed.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Agreed.
Most suspicious objects I've seen are PPU.RangeTimeOver and some sound-related things. But I certainly don't understand them well enough yet to blame them.
I've found a (very long) save-reload sequence that can get a few bytes of RAM and CPU.Cycles out of sync (i.e., doing 2 sequences of save/reload with the same read-only movie and freezing the result on the same frame gives you different values in those fields). At that point I assume you're fucked, so I'll try shortening the sequence and then tracking how the static data diverges.
BTW, the SoundData struct should be irrelevant now that the fake mute fix is always used, right?
Also, when you will get rid of those problems may I ask you if you could remove those "Snapshot inconstitent with movie" that are REALLY from the movie bug? Because of that, we are forced to play back from very beginning of a movie and it's really really annoying.
Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya
Edit: Fixed other cause of desync in newer version.
gocha wrote:
I think I fixed the problem. If you interested, try my improvement11-fix2!
Download
- My Snes9x-MOD Binary Dir
- My Snes9x-MOD Source Code Dir
- Related Link: gocha's MediaFire Root
Should I prepare for releasing 1.51-improvement series seriously...?
Note: keep in mind that this is still experimental.
snes9x watch settings for fix-v2:
Note
- Snapshot version is now incremented, and I added a new block "IAU" for a few variables in IAPU.
-- You can load older snapshot (but this will cause desync).
-- You cannot load new snapshot with official 1.51.
- Movie's timing is not changed at all.
- I also applied some of the fixes from my 1.43-improvement11.
- I didn't applied nitsujrehtona's patch.
Desync Fix Patch
See source code diff.
--
温故知新 "Taking a lesson from the past"
I studied about the desync from 1.43-official.
Not to be the pessimist guy but there are still desync issues in SCV4 at very same place. Maybe there is something specific to that game only.
Or maybe I need to select special options such as "sync samples with cpu?
Our movies does have the left+right and "fake mute desync workaround" checked. Maybe the "fake mute desync workaround" should be unchecked?
But anyway, thank you for trying out. Your fix might indeed reduce desyncs in most games. I don't know.
Also, what "Fake mute desync workaround" is supposed to do? Is it really necessary? I never know if it's good or not to check it as well as sync samples with cpu. I think we need one and only one reliable thing.
Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya
Phil, sorry to hear that. How can I reproduce the desync? I couldn't download your movies from filespace.org :(
Also... Didn't you load the savestate created by older version (official 1.51)?
http://dehacked.2y.net/microstorage.php/get/1000052085/Super%20Castlevania%20IV%20%28U%29%20%5B%21%5D.smv
Since states are no longer valid, I think you can create one. Just save when Simon touches the bridge after the elevator at block 2-2. And toy with savestates there. You'll quickly notice that most of the times, the bats don't move the same direction even if your inputs are the same.
No, I did create new savestates. And I even created a new cfg file in case of.
Edit: And I don't think WIP 1 support is needed. That feature was implemented in 1.43 Final as some games desync when 1.43 WIP didn't.
Should I prepare for releasing 1.51-improvement series seriously...?
Note
Snapshot version is now incremented from official 1.51:
- Re-added "IPU" (IPPU) block and stored HDMA variables, also added more to "IAU" (fix-v3).
- Added a new block "IAU" for a few variables in IAPU (fix-v2).
- You can load older snapshot (but this will cause desync).
- You cannot load new snapshot with official 1.51.
- Movie's timing is not changed at all.
- I also applied some of the fixes from my 1.43-improvement11.
- I didn't applied nitsujrehtona's patch.
Gocha, awesome work again.
I disagree with Phil though. And as I've pointed out many times, he's yet to show that 1.51's timing is actually more accurate than 1.43's (or vice versa), despite his claims to its superiority. Jumping to a new emulator just because the version number is higher without thorough testing is how the situation gets bad in the first place (hello VBA).
I'd gladly accept some console comparisons to 1.51 and 1.43, though. If I could record console play myself, I would have done this already.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
