It seems Zelda stores some important information about the Sprites in PPU.OpenBus1 and PPU.OpenBus2.
Adding those to the list of saved parameters in the snapshot file, seems to solve the desync problems with Zelda.
How I did it:
After trying _all_ possible Parameters in CPU (that were not yet saved) without much success (and spending hours of frustrating work), I had the right idea.
I outcommented the S9xReset() before loading a Snapshot.
And then I could notice, that when I loaded a savestate the sprites seemed to move around quite random.
So, there must be a variable, that is set, and if you do _not_ reset it, the behaviour is (almost) random.
So I did do the same with all functions in S9xReset allowing them to be just called once. (with a static first var, which is set to false after one going through)
I found out its in S9xPPUReset, then I used the same trick as above to corner the variable, which makes random behaviour. Finally I found them.
So, please test it and finally make a great Zelda-Time Attack!
cu
Fabian
PS: Could someone please forward this to Snes9x authors, if the patch works for you?
Hmm, nice. Do you think this will fix any other games?
This might fix problems, when running the movie gives a slightly different result then loading a save-state and rewinding the movie.
But I have not heard of any games with that problem - except for Zelda.
I think only time will tell. :-)
[edit:]
Yes, this might fix many other games as well. I think desyncs happen, because of:
- You run the movie
- You save a savestate, but its missing information
- You load the savestate to re-edit (the console is now in a slightly different state)
- You record the movie
-> You watch the movie -> it could desync, because the "console-state-change" of course does not happen in the movie.
So one might need to check the list in http://nesvideos.stc.cx/viewtopic.php?t=542 again.
However I'm still wondering how setting other sound settings can influence some games, but this might be another missing bit of "information".
cu
Fabian
Hmm, nice. Do you think this will fix any other games?
This might fix problems, when running the movie gives a slightly different result then loading a save-state and rewinding the movie.
But I have not heard of any games with that problem - except for Zelda.
I think only time will tell. :-)
Super Mario: RPG does. And thank you. I might be able to get it finished now.
Also strange with SM:RPG. It desyncs if I
-load a different ROM before I load SM:RPG
-start playback then restart it
-start playing normally, and then I decide to watch the movie.
If you feel like trying to tackle this. (Please? ^^;;) I've uploaded a save file to http://www.nerdparadise.com/crap/SMRPG.zip .
It desyncs with 1.43final on the rotating flower during the battle (when I had played it through it gave me a Full HP flower, now it doesn't). But if you do any of the aforementioned things it'll desync anywhere from the first battle in the Castle, to the text with Bowser, to my missing the save point, to my missing a few coins on mushroom way, to encountering an extra enemy. It seems like it drops a frame every so often. But I'm not the coder.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
It would be nice if we could fix Out Of This World so we wouldn't have to watch a silent movie of it.
Thats what I worked on today, but with not much success :-/.
What I can say now is that the APU (Sound-Processor) is acting differently each time if Sound is on in Frame 2317.
Argh ...
I might know why ...
Lets check ...
There were some rand() somewhere ... Those could lead to this behaviour ...
[edit]
Nope, I was wrong. It even has "random" behaviour, when I removed thos rand() calls.
But if I remove the write()-Call to the Soundcard it magically starts to be "deterministic".
I really don't know what I should think of that ...
My only left idea is memory corruption somewhere or some value, which is not reset and such "random".
I'll now make a Load-Movie at Beginning function to reduce the "randomness" factor.
[edit2]
Its getting worse. After re-adding the code using threads or setitimer under unix, I got again "random" behaviour. That really sucks.
I will give up on the Sound desync for now as I'm out of ideas at the moment.
[edit3]
Ok, I now understand at least the "randomness".
The problem seems to be (that occurs on all systems) that the sound buffer of the APU is not cleared in constant time intervals, but just when the output buffer of the soundcard gets too small.
Of course this will fail to have a deterministic behaviour, which is badly needed for our movies.
Solution seems for me to implement another ring buffer and to drop any samples that are "too much" in it.
But I'll investigate this further tomorrow. I hope this explanation might help someone.
cu
Fabian
For those who want a Windows version of Snes9x that has this patch applied and thus never desyncs when recording Zelda 3 (and likely others like Mario RPG), here it is:
http://www.filespace.org/nitsuja/Snes9Xw-ZeldaFix-v3.zip
(edit: changed link to newer version -- see my later post about this)
The movie files it makes are still compatible with the official 1.43 final. (Someone else may want to host this somewhere better if people are still interested in this.)
Oh, and as "proof" that it works, I offer this SMV and the assurance that it was very easy to make:
http://www.filespace.org/nitsuja/zelda3intro.smv.zip
(edit: ROM = "Legend of Zelda, The (U).smc", emu = 1.43 Final.)
Right now I'm not up to making a full time attack of the game, but I hope someone is now that there are no desyncs to worry about, because I'd really like to see a complete perfect run of it.
Note to Fabianx:
I added the following lines before the other 2 added by your patch:
{OFFSET (OAMWriteRegister), 2, INT_V},
{OFFSET (BGnxOFSbyte), 1, INT_V},
because a comment indicated that the developers thought these belong in the snapshot as much as OpenBus1/2, and I think I saw it still desync sometimes until I added these. I'm not 100% sure they're necessary, but it seems to work perfectly with them and I think nobody will mind if their save states are 3 bytes too large.
I also got rid of one of the two lines that go:
{OFFSET (Need16x8Mulitply), 1, INT_V},
because the duplication is obviously unintentional even if not harmful.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
That is SO amazing. :) Great job, Fabianx and Highness. I can't wait for Zelda's tool-assisted run. It'll be one of the best movies on the site when it's done.
Note to Fabianx:
I added the following lines before the other 2 added by your patch:
{OFFSET (OAMWriteRegister), 2, INT_V},
{OFFSET (BGnxOFSbyte), 1, INT_V},
because a comment indicated that the developers thought these belong in the snapshot as much as OpenBus1/2, and I think I saw it still desync sometimes until I added these.
Yes, thank you very much! I'm glad finally someone made a windows version. Those seem to also have been necessary though I could not get a desync with them missing, but perhaps I have not tried hard enough.
cu
Fabian
Big thanks to FabianX and nitsuja. The zelda desynch problems finally seem to be gone, the movie worked like a champ for me too.
About the movie, I'm thinking it's probably a good idea to get money from the one-hit-kills enemies along the way, otherwise you'll end up getting it from much more difficult enemies. But I guess it has to do with enemies' different drop rates as well... anyone who decides to tackle this game has a lot of work to do.
Oops, I just found out something's wrong with the fixed version I posted: I linked with a different CPU core than the official version uses (the readme said they're identical but I guess they're not), so it'll still go out of sync between versions sometimes (it just happened to not do that in the one demo I made). I fixed this, so here's the new version that makes movies exactly compatible with 1.43 final, for real this time:
http://www.filespace.org/nitsuja/Snes9Xw-ZeldaFix-v3.zip
Also, even if you're not making a Zelda run, if you're on Windows I think you might want to use this because I improved some other things that were bugging me. (Mainly: The ugly black bar at the bottom of the screen is now an option that's off by default, frame advance has sound, and hotkeys are customizable.)
got a question... if zelda was recorded done on zeldafix version, then can be viewed on regular snes9x with no zeldafix?, or do we need zeldafix version to see run?
Can be viewed with regular Snes9x 1.43 (Final, not the WIP). The only really important difference is the way the zeldafix version handles save states, and since the movie contains only input and no save states, the movie will play back exactly the same in both versions. (This is only if you record "from reset" but that's ok because only from reset movies can be accepted anyways.)
I believe the sound desync fix will not be this way, though; that will probably require a version whose movies are not compatible with the current one. Which is why the sound desync fix is not included in this version (well that and the fix hasn't been figured out yet). Luckily Zelda 3 (and actually most games) aren't affected by the sound desync bug.
Hi,
sorry to be picky, but in OpenGL-Mode, a good part of the bottom of the screen is cut off with this hack. And the keyboard input isn't displayed either.
Switching OpenGL off, fixes both problems.
Oh and while already posting in this forum: Can anybody tell me how I reset my Snes9x-Window to the correct aspect-ratio? I've unfortunately resized it and now I can't get it back to how it was before.
Philip
Hi,
sorry to be picky, but in OpenGL-Mode, a good part of the bottom of the screen is cut off with this hack.
Whoops, I thought I tested that... it's super-easy to fix, but should I keep posting versions for re-mirroring when things like this turn up?
(Or maybe while I'm at it, anybody have any feature requests?)
pilif wrote:
Oh and while already posting in this forum: Can anybody tell me how I reset my Snes9x-Window to the correct aspect-ratio? I've unfortunately resized it and now I can't get it back to how it was before.
This I don't know. Maybe I'll see if I can add a menu option that does this. (Do you mean just correct aspect-ratio is ok, or is a specific multiple of 100% size also needed?)
Whoops, I thought I tested that... it's super-easy to fix, but should I keep posting versions for re-mirroring when things like this turn up?
(Or maybe while I'm at it, anybody have any feature requests?)
as I like the OpenGL mode very much, a fix would be very convinient. If you want, I can provide you with ftp to a decent server with enough bandwidth to please everyone. PM me for this.
nitsuja wrote:
This I don't know. Maybe I'll see if I can add a menu option that does this. (Do you mean just correct aspect-ratio is ok, or is a specific multiple of 100% size also needed?)
An option to set 100% and 200% would be enough for me. The deluxe-Version would be an option to always keep the aspect ratio while resizing, either creating black borders or disallowing size changes on one or the other direction.
Oh and while I'm at it: Your hacked version seems to have some slight problems with the sound. It's a bit distorted and clicking on my machine, but this may be a configuration problem.
Thanks very much for what you are doing!
Philip
