Joined: 11/20/2004
Posts: 236
Location: United States
Emulator InformationEmulator:Visual Boy Advance Re-RecordingEmulator version: v23.6 svn480
Problem?: De-sync due to SRAM/clock settings...?
----------
I have a rather odd scenario which I'm not sure can be helped, but I figured if anyone could, it'd be the guys who modified the emulator.
Long-story short? All but one of my recordings in Pokémon Crystal de-synchronize upon playback. And I'm 100% sure I know why.
Recording 1 was started using the "From start (power-on)" option which clears the SRAM.
Recordings 2-7 were started using the "From reset (SRAM)" option, which does not.
In using that choice, however... apparently, certain counters, variables, and whatever else didn't line up right when trying to play the footage back.
I'm a little irritated this happened, though I understand why. If I'd started recording using the "From now (snapshot)" option after setting the time, everything would probably be fine. Live and learn. On top of that, I know Super/Game Boy/Color emulation in Visual Boy Advance is a little iffy compared to a lot of other emulators, such as GBG BGB and BizHawk (using Gambatte's cores), so I guess I'm not terribly surprised...
Anyway, to get to my my point, I was wondering if there was anything I could possibly do to salvage these movie files. I'm thinking not, but maybe someone out there knows something I don't which would be helpful...
Thanks in advance!
(And if anyone's curious, this isn't for a TAS project. I just like Re-Recording's movie options more than vanilla VBA's.)
I still wince when your Endless levels come up.
As far as salvaging the VBM files... am I correct in assuming that recordings 2-7 play back correctly when you have no SRAM file?
One thing you could do is hex edit your movie files. According to the movie file specs page VBM address 0x014 carries the flags for movie start. If these playbacks are supposed to start clean, 0x014 should have a zero value.
Directly hexing in a starting savestate is outside the scope of my knowledge, but could probably be replicated by playing back the movies in order, making a savestate-anchored 'recording' with no inputs, then diff'ing the old recording with the empty one.
Joined: 11/20/2004
Posts: 236
Location: United States
Pokota wrote:
As far as salvaging the VBM files... am I correct in assuming that recordings 2-7 play back correctly when you have no SRAM file?
I hadn't thought of trying that... and unfortunately, it seemingly made no difference whatsoever. They punch in a seemingly random time, seem like they play correctly for a little while, then usually during the first random battle, the movies just go full-derp. Slowing things down, it almost looks like the input is running a little faster than the game, or something... And playing back the same movie often returns different results for random encounters and even setting the time. Even stranger, though... I just noticed that if I stop the movie prematurely, the in-game time radically shifts (which can be pretty funny, but not very helpful).
But I think you're right. Making these recordings and tying them to save states is probably the better way to go, given the mechanics of the game. Not sure if I can figure out how to associate current movies with newly-made save states, though...
Thanks for the input! Oh, and...
Can you upload the VBMs to userfiles, and post the hashes for your game dump? I want to have a look at what's going on, maybe there's an easy fix (or at least a not-impossible one)
Joined: 11/20/2004
Posts: 236
Location: United States
Mmm... is MediaFire alright, instead? I don't want to waste server space on something that's not even for the site.
I uploaded it over here, if so. I also included a text file that has the hashes and stuff (obtained from ROM Hasher) within the ZIP.
I'm playing around with hex editing but I don't think I'll be able to make these sync because of the Real-Time Clock issue. I tried flipping the RTC bit in the movie file and the character wound up fighting a ratatta on Thursday Morning.
You may have to start over from part 2.
I know Super/Game Boy/Color emulation in Visual Boy Advance is a little iffy compared to a lot of other emulators, such as GBG and BizHawk (using Gambatte's cores), so I guess I'm not terribly surprised...
Saying VBA is a little iffy for DMG and GBC is more than an understatement. VBA is utter crap.
VBA is so bad that it causes random softlocks / crashes in a few specific games (Dark Duel Stories for example, randomly softlocks after a duel due to a memory timing error, which also randomly causes card ID 0x00 Blue-Eyes White D. to drop from every opponent).
It also loads the wrong opponent's data from time to time in a GBA game, Reshef of Destruction (confirmed by several people).
(and the emulator you're thinking of is BGB, not GBG :P )
I want all good TAS inside TASvideos, it's my motto.
TAS i'm interested:
Megaman series, specially the RPGs! Where is the mmbn1 all chips TAS we deserve? Where is the Command Mission TAS?
i'm slowly moving away from TASing fighting games for speed, maybe it's time to start finding some entertainment value in TASing.
Joined: 11/20/2004
Posts: 236
Location: United States
Joseph Collins (originally on 2016-08-03 18:58:29) wrote:
Mantidactyle wrote:
Saying VBA is a little iffy for DMG and GBC is more than an understatement. VBA is utter crap.
VBA is so bad that it causes random softlocks / crashes in a few specific games (Dark Duel Stories for example, randomly softlocks after a duel due to a memory timing error, which also randomly causes card ID 0x00 Blue-Eyes White D. to drop from every opponent).
It also loads the wrong opponent's data from time to time in a GBA game, Reshef of Destruction (confirmed by several people).
I did not know that. All I knew was that it wasn't the most accurate emulator for Game Boy stuff. It also likes to hiccup while playing Game Boy games, for some reason. But it's certainly good enough for casual stuff like I'm doing. Usually, ha hah.
(and the emulator you're thinking of is BGB, not GBG :P )
Noted and fixed!
Anyway... who would've guessed that real-time clock would have an impact on input replays? I mean... other than everyone who knows a thing or two about tool-assisted videos. If the time in-game is different in the replay than when you actually recorded it, chances are, you're not going to be able re-create the exact same circumstances... I genuinely have now idea how I made this work before, other than probably doing like I said and recording after the time was set. A little five-minute recording I did today, where-in I recorded from a snapshot after setting the time, seemed perfectly fine!
So, yeah... gonna have to restart. But at least I learned something, right?
Thanks for the input, folks!
----------
Quick update for the curious: Starting from a point after setting the clock did indeed fix my desync issues completely. I'm back up to five parts (of the original seven) without error!
