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/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: 6/22/2007
Posts: 181
Location: Eastern Michigan University
Super Smash Brothers - Optimized Entertainment Run
Loading => Hitting Start at the earliest possible frame for each menu/sub-menu.
Selecting => Move Cursor on earliest frame at 100 force to select character at earliest point on earliest frame. Followed by selecting one stock by hitting 'A' every other frame until one stock is selected, keeping cursor at closest point to difficulty select, at that point (first frame possible) move to difficulty and select Very Hard by hitting 'A' every other frame, and then followed by an earliest start...
Waiting => Earliest Frame Press 'Start'.
(More to come)
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
nico wrote:
that's not a combo. don't let the opponent hit the ground for one thing. that makes it escapable.
It only is escapable if the CPU escapes it. :)
I know the difference, and your right, most of them aren't true combos..., the one on fox's level is though.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
The Great Morphologous wrote:
okaygo wrote:
Besides, I know Malva... I doubt he could do a run like that
Blasphemy!
Anyway, the missed hits on the dairs look sloppy. I think they're still getting killed a little too fast... Maybe knock them off, let them fall to where they couldn't recover, then u-air them back to the stage, and make it back yourself?
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
laughing_gas wrote:
Normally I would be entertained, but having watched many Isai combo vids I think this isn't much different, just on single player.
Malva never made a combo video, he only does combo singles. Some person just took his combos and made a movie. Besides, I know Malva... I doubt he could do a run like that, its just too hard to play on very hard without getting hit... but I know what you mean. I almost beat won one of his FFA, but then the game lagged out.
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/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.
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.
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.
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.
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
<okaygo> When I ran Nightmare creatures at 100%
<okaygo> I synched
<okaygo> while I ran it at 1000%
<okaygo> I desynched
<okaygo> My cpu wasnt hitting the target frame rate, or maybe the game has a internal limitation.. and while that was limited, i was reading my input data at the same rate
<okaygo> Which explains how some games desynch from the start
<Raiscan> Is that why I'm one of the few people that can sync Majora's Mask? because my PC is better?
<okaygo> Possibly
<okaygo> Also, a factor is plugins
<okaygo> Video plugins handle how video is updated
<okaygo> but they are consistent
<okaygo> Do some testing Raiscan
<okaygo> Try to put your speed limit
<okaygo> for the game
<okaygo> at about
<okaygo> 30%
<okaygo> and see if it syncs
<okaygo> nightmare creatures
<Raiscan> for the Nightmare Syncers?
<Raiscan> okay, if I disappear I've crashed my PC
<okaygo> Yes playing your video at about 50% synched me
<okaygo> While 1000% got me into the zombie battles
<Raiscan> I still don't get why the game takes input so much
<okaygo> Why don't you call the creators?
<Raiscan> :D
<okaygo> It's possibly that they wanted to take shortcuts, or be 'precise'.
<okaygo> But did it sync?
<Raiscan> yeah my movie syncs at 30%
<NesVideoAgent> New reply by Sir VG (GBA: Kirby And The Amazing Mirror): http://tasvideos.org/forum/p/134598
<okaygo> Exactly...
<Raiscan> I think you're onto something :)
<okaygo> So can I call this myth busted/plausible/confirmed?
<Soulrivers> WHAT AN AMAZING DISCOVERY
<Raiscan> plausible
<Soulrivers> seriously I'm not sure what you're talking about :)
<okaygo> :o
<Raiscan> you have a valid idea, just need a fixed implemented and let it loose to the hungry n64 TASers
<okaygo> Well! Input per frames, seems almost logical
<okaygo> But more testing
<okaygo> more theories are needed
Joined: 6/22/2007
Posts: 181
Location: Eastern Michigan University
laughing_gas wrote:
Example: in Ocarina of Time if you save at a certain place and reset the game, you warp to a different place. This is called save-warping, and it is a nifty timesaver. However we can't use it now because the current Mupen cuts off the movie (?) after a reset, so that's why reset recording is so desired.
I am thinking in order to keep consistent with the structure, I will make all the values set to on. Which I'm pretty sure is never used in a game... who puts the analog stick to max X, and max Y, presses all the buttons (a,b,start), all the triggers (l,r,z), the two unused values (un1,un2), all four c buttons (l,r,u,d), and the digital directions (u,d,l,r) all at the same time? This sequence I will make trigger a reset...
