Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
I changed the file format for savestates, and modified the way flashram is used.
www.okaycreations.com/antids-mupen.7z
Try this and tell me if it desynchs with savestates.
NOTE: I changed the way savestates work in this build, so you need to make new ones.
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
the "no desynching whan TASing the game" part is kind of what I wanted to be fixed more for N64 TASers than the actual watching .m64's part....
But a work in progress is a work in progress I guess, good work.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
comicalflop wrote:
the "no desynching whan TASing the game" part is kind of what I wanted to be fixed more for N64 TASers than the actual watching .m64's part....
But a work in progress is a work in progress I guess, good work.
When I tried it, it desynced when creating the file. And I know about the usual desync there, it's just that it did it EVERY time, instead of just the first. Seems like that new thing still needs work.
I could watch it on the other Mupen64 I have, so no problems. Mukki, excellent work. It just gets better from here, too, with GBT and Stone Tower coming up.
Anyways, on the subject of Stone Tower, I finally got this to work. I'm not sure if it's faster than the current route, but it's something to test, and it looks awesome.
http://youtube.com/comment_servlet?all_comments&v=WRWjcrquVoA
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
petrie911 wrote:
When I tried it, it desynced when creating the file. And I know about the usual desync there, it's just that it did it EVERY time, instead of just the first. Seems like that new thing still needs work.
I could watch it on the other Mupen64 I have, so no problems. Mukki, excellent work. It just gets better from here, too, with GBT and Stone Tower coming up.
Anyways, on the subject of Stone Tower, I finally got this to work. I'm not sure if it's faster than the current route, but it's something to test, and it looks awesome.
http://youtube.com/comment_servlet?all_comments&v=WRWjcrquVoA
Sorry to burst the bubble, but the current run actually starts from FlashRAM which is to my knowledge against the rules. Thats the reason why it doesn't work in the new one, because the new one actually clears FlashRAM now, and saves it correctly in savestates.
Oh, I see. That explains the desync. Although it's not really against the rules, as at the time it was made there was no other way.
But then how do we rectify the desync?
Why do you need to do the stuff with Epona and Romani ranch?
To get the 3rd bottle needed to carry all of the eggs in Pirate's Fortress in one trip.
Finishing Pirate's fort is next followed by GBT. Do you see doing Stone Tower in the same cycle or will it have it's own cycle?
Also, I'm wondering why you use Zora for that one jump prior to the Forest Boss.
EDIT: Also, is it possible to wait outside Central Clock Town until midnight to avoid the cutscene, or is this different in the first cycle? (Or would it not be faster anyhow)
I doubt the run would be rejected for minor save issues. It can easily be made from the rom and there's no chance of you having rigged the save. It may be possible to hex-edit the file too. Just add a few more frames of blank input for what I assume is the lag caused by writing the initial memory.
Excellent WIP. I eagerly await the completion of this run, it's definitely my most anticipated at the moment. I particularly liked how you killed several aliens with one arrow, I didn't actually know that was possible.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
petrie911 wrote:
Oh, I see. That explains the desync. Although it's not really against the rules, as at the time it was made there was no other way.
But then how do we rectify the desync?
By using reset recording, or hex editing. If you use reset, although it will make the run longer then it is, the FlashRAM will stay or... you can hex the title screen to work. I would strongly advice fixing that, because the version is available now that clears up this issue.
I was just about to bring that up, if you watch the following video you'll see Link doing a mega flip with bombchus.
http://uk.youtube.com/watch?v=S5pkYq98EBM
Now if you watch the following two videos one from MM the other from OoT you'll notice something.
http://uk.youtube.com/watch?v=Bh4HVfpV-LMhttp://uk.youtube.com/watch?v=s5dw_OHMns8
The effect is exactly the same although it takes a more complicated setup to pull off in OoT, while in MM it could be done entirely with a bomb/chu. Now if you were to plant a bomb or setup up a chu the liklyhood is you could perform a mega flip, which can potentially save a lot of time over endless sword techniques and could allow link to reach over long gaps say in parts of the GBT.
How to make this movie sync, by Halamantariel.
1) Use the Rice 6.0.0 video plugin
I gotta say, rice 6.0.0 is a horrible plugin in many places of MM. But it played all the way through without any hiccups. Actually, it desynced 1 more time at the start screen, but I was fast-forwarding then. I played the intro without fast forward, and it was perfect.
Some of the colors are pretty messed up, like when you get the deku mask. or a hookshot.
IMO the best-looking plugin for MM is jabo 1.6. the second best is direct64. jabo 1.5 and rice are kinda tied for crappiness. 1.6 always desyncs for me when deku link is just messing around wasting time between 10pm and midnight of the final day of the first cycle. if this antidesync mupen could play the m64s that would be awesome because then I could make videos using jabo 1.6 so that fog effects and dynamic lighting are intact. However, when I try to get the wip working, it desyncs on the menu screen the same way it does on normal mupen without a new .fla file. When I save a savestate in the old mupen and try playing it back in the new mupen loading from there, it just closes.
So, is there a way that I'm missing for full playback in the new mupen?
In the meanwhile, I'm still encoding the run using direct64. I started from the first time you enter the great bay thing to get the zora mask. so the movie will be pretty long. I'd say it will be done in a few hours.
Yeah, Jabo's 1.6 seems to give the best graphics for MM, but for some reason, it won't sync. Such a shame, too, as Jabo's 1.6 would have made an excellent avi when this gets submitted.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
Like I said before, the current run needs to be fixed because in it's current state it doesn't comply with the TASVideo rules. The easiest fix would be to place a reset right after the initial FlashRAM is made, then the movie should sync up.
Joined: 8/26/2006
Posts: 1139
Location: United Kingdom
The issue with flashRAM was adressed and resolved a long time ago.
comicalflop on the 12/01/2007 wrote:
the .fla file I was mentioning in IRC is more of a problem on my side, not as much for Linux viewers.
This is specifically for me (when watching from the very beginning):
I have to delete the .fla file in the mupen save directory beforehand, play the movie, and let it desynch at the menu.
after it desynchs, replay the .m64 again, letting a .fla file be generated.
This is probably because I use windows and not Linux. it probably works differently for Mac and Linux users.
DeHackEd's mention of rejecting it has been mostly resolved, since it was more concerning if the movie started with SRAM.
I think that's the gist of it.
AKA's currently trying to hex everything to make it work, today I might try and review the entire thing from scratch to see if everything synchs up from the beginning. keep up the good work!
This movie never started from SRAM. The memory was completely clean when I started as far as we all knew. I can't think how the flashRAM that you are refering to changes anything in any way.
I doubt this will lead to the movie's rejection. Anyway I'll be finished this in the next few weeks (hopefully) so I'll carry on regardless.
Also, hex-editing anything won't work, there is a large amount of luck manipulation in this movie so it would desync pretty quickly.
Game looks great to me, and I'm using Rice's Video Plugin 6.1.1 beta 10.
I wasn't able to get it to sync using that plugin. It's a good one too. However, it's "ass" slow in terms of fast forwarding compared to the jabo series.
Has anyone tried Glide (I think GLN64)? IIRC, that was the best plugin to use for any n64 game.
Click here for the "high quality" version of the latest progress. it's about 115MB and over half an hour.
And now that the "low quality" vid is ready, click here if you so choose (IMO it's pretty much worse than youtube but hey it's a smaller file and I don't care).
