Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
mwl wrote:
Also, there's that nasty five-second delay when loading up the subscreen menu in OoT.
That has nothing to do with anything... the whole emulation pauses while that data is loaded if I recall correctly.
--
I believe a sample core is called for to test synching at frames, versus the 'process as you go', this way... you should have an equal amount of input corresponding to the number of frames. So regardless of how a game plays back, X frame must equal X input.
Can you also fix the color change (or lack thereof) in the life force doors in Jet Force Gemini?
What about bad textures in Chameleon Twist?
What about the whole emulation thing with Donkey Kong 64?
Jesus, give the man some time.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
After doing some testing, I think I can confirm one theory as fact.
It confirms that frames are consistent while VI's are only consistent under the same settings.
Thus, any anomaly or iterations in settings will cause the movie to desynchronize.
To test this statement for yourself, I have provided a small core modification that replaces FPS with total Frame Count.
http://okaycreations.com/frame_test_core.rar
Try this against the pause screen glitch in OOT. Watch how the frame count doesn't move, while the recording counter still increases.
The recording still needs to use VIs to determine the movie duration, as there is simply no correspondence between frames and time. But, since you plan to make playback independent of VIs, this implies that not everyone who is able to play back the movie will see the movie complete in the same amount of time the movie claims to be. In the interests of keeping the movie duration tamper-proof, you could display a noticeable warning if the playback duration exceeds the (reported) recording duration, but somebody could still edit their movie to contain a shorter duration and then say "it really ran that much faster with my settings, maybe something is wrong with your settings".
okaygo wrote:
That [the OoT pause screen delay] has nothing to do with anything... the whole emulation pauses while that data is loaded if I recall correctly.
The music continues to play during the pause, which I think means the emulation must be continuing. But it appears to be a graphics plugin problem, one that most graphics plugins intentionally ignore for performance reasons. Graphics plugins have access to memory that the emulation core can read, and certain games expect them to write specific things to that memory.
As for reset recording, I tried implementing it but encountered about a 30% chance of desync per reset during playback. It might have something to do with using a makeshift (probably incorrect) hard-reset because of the apparent absence of any support for soft reset in the emulator.
Question: Why do you think the speed throttle settings are affecting playback? There is no inherent reason that an emulator should emulate differently depending on the speed of the system being used to run it, of course. It seems likely that a specific component (or plugin) of the emulation is to blame.
(Thank you for attempting this, by the way.)
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
nitsuja wrote:
The recording still needs to use VIs to determine the movie duration, as there is simply no correspondence between frames and time. But, since you plan to make playback independent of VIs, this implies that not everyone who is able to play back the movie will see the movie complete in the same amount of time the movie claims to be. In the interests of keeping the movie duration tamper-proof, you could display a noticeable warning if the playback duration exceeds the (reported) recording duration, but somebody could still edit their movie to contain a shorter duration and then say "it really ran that much faster with my settings, maybe something is wrong with your settings".
okaygo wrote:
That [the OoT pause screen delay] has nothing to do with anything... the whole emulation pauses while that data is loaded if I recall correctly.
The music continues to play during the pause, which I think means the emulation must be continuing. But it appears to be a graphics plugin problem, one that most graphics plugins intentionally ignore for performance reasons. Graphics plugins have access to memory that the emulation core can read, and certain games expect them to write specific things to that memory.
As for reset recording, I tried implementing it but encountered about a 30% chance of desync per reset during playback. It might have something to do with using a makeshift (probably incorrect) hard-reset because of the apparent absence of any support for soft reset in the emulator.
Question: Why do you think the speed throttle settings are affecting playback? There is no inherent reason that an emulator should emulate differently depending on the speed of the system being used to run it, of course. It seems likely that a specific component (or plugin) of the emulation is to blame.
(Thank you for attempting this, by the way.)
Well, basically... if your reading data too fast, its kinda overloading itself. Such in a case were emulation will slow down due to errors, or what be... data gets read to early, and gets missed by the ROM.
I am thinking maybe the best way to sync a game is to buffer all the input over one frame, called for by a game and use a marker point.
Example: (This game reads data 3 times a frame)
FRAME 1: SA | A | | X
FRAME 2: A | A | A | X
FRAME 3: | S | R | X
Each time a new VI is called, check to see if there is any input left in the buffer, then upon completing the frame, check if any VI's were not processed, and alert a desynch.
Well, basically... if your reading data too fast, its kinda overloading itself. Such in a case were emulation will slow down due to errors, or what be... data gets read to early, and gets missed by the ROM.
Data is read synchronously with the emulation, in the same thread, so the emulation can't accidentally "miss" the data if it's coming in at a different speed. But I guess that doesn't matter... there could be some bug somewhere in the emulation process that makes it act like that, and if the method you're proposing can make the symptoms of that go away (and it remains tamper-proof) then I see no reason not to go ahead with it.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
Try recording a game that has about 180 VIs a frame. The play it back at highspeed, your frame rate doesn't speed up however your VI's go even higher, thus reading too much data per one frame... thus causing a desynch.
VIs represent vertical refreshes on the actual system, so what you describe seems to be a horrible bug in either (1) the emulation or (2) the process of counting/recording the VIs. If it's the former, I have to wonder if any amount of storing extra input data and markers could be enough to compensate for emulation that is not even "synchronized with itself". If it's the latter, your method might be overkill. It's worth a try either way though.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
nitsuja wrote:
VIs represent vertical refreshes on the actual system, so what you describe seems to be a horrible bug in either (1) the emulation or (2) the process of counting/recording the VIs. If it's the former, I have to wonder if any amount of storing extra input data and markers could be enough to compensate for emulation that is not even "synchronized with itself". If it's the latter, your method might be overkill. It's worth a try either way though.
I've been doing a lot of thinking this past week, but I've also been quite busy...
I'm not quite sure where the real problem is, but its clear there are some problems to be fixed. I will most likely do some work over the weekend.
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
Me too. Two of my runs in the making would greatly benefit from having a fixed mupen with some new tasty features (mem watching, start from SRAM, record reset, desynch free, etc.)
Best of luck!
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
Teaser video:
Resets to SRAM in recording/playback.
http://okaycreations.com/mupen_reset.avi (I got fox 5/5 tests)
as of the current date: no emulator accurately emulates soft resets, not even Project64 1.7 (to my knowledge).
So you can count out that feature ever being included.
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
Great, now Comicalflop has no excuse to further delay Mario Kart N64 :)
Edit: *Prepares for a long Comicalflop speech* O_o
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
I still do.
[18:27] <okaygo> No, cold resets.
[18:27] <okaygo> Hard reset = clear sram, and data
[18:28] <okaygo> cold reset = power on/off
[18:28] <okaygo> soft reset = reset button
A look at the site rules on using cold resets and if they'd be allowed.
I'm also slightly curious why you're all so adamant about me using resets to shave a boring 3 minutes of the same cinematic 3 times repeated off the MK64 run.
And deathwarps removed the need for recording resets for OoT. I'd rather have synch stability and no pause bug before working more with that run.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
comicalflop wrote:
I still do.
[18:27] <okaygo> No, cold resets.
[18:27] <okaygo> Hard reset = clear sram, and data
[18:28] <okaygo> cold reset = power on/off
[18:28] <okaygo> soft reset = reset button
A look at the site rules on using cold resets and if they'd be allowed.
I'm also slightly curious why you're all so adamant about me using resets to shave a boring 3 minutes of the same cinematic 3 times repeated off the MK64 run.
And deathwarps removed the need for recording resets for OoT. I'd rather have synch stability and no pause bug before working more with that run.
Beggars mustn't be choosers.
Recording resets
Supports recording of soft resets, or hard resets or power cycles that don't clear SRAM.
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
Ah. Well, don't forget that if all else fails, I can always rely on my laziness and distractibility to keep those runs and others waiting for years to be finished.
Raiscan wrote:
Or Ocarina of Time.
And yeah; if adding record reset doesn't work, would fixing synch stability and the pause bug for OoT at least work?
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
AVI Capture using the internal recorder:
http://www.youtube.com/watch?v=PYXXkv74s2k
Although the character is different from the first run, I made changes in the core since then, and Mario is now 10/10.
Expect a public release soon, as soon as others confirm sync with other games.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
The reseting has been reported to desync for some people, which is okay as the version is not supported yet. I will be fixing all this stuff in the meantime. It should be okay on games which aren't full of random triggers.
Can you also fix the color change (or lack thereof) in the life force doors in Jet Force Gemini?
What about bad textures in Chameleon Twist?
What about the whole emulation thing with Donkey Kong 64?
Jesus, give the man some time.
