I tried to record a movie of AoS bossrush, so I checked "From reset (SRAM)" and left other settings unchanged for recording. I've managed to press the START button as early as I could to enter BR mode as fast as possible before I replayed it. However, when I replayed the movie I found the fade-out after the "Licensed by Nintendo" was a little longer than that when I recorded the movie, which resulted in totally desync.
What's more, a few months later one of my friends sent me a run for AoS (J), and I found it just desynced in the beginning dialog. The movie was recorded from snapshot right after reset. Strangely, she said that she had no problems with watching the movie.
I'm sure that I've watched them with the right roms and I've tried to replay them with VBAR v17, v19.2 and v20 on two computers. But none worked correctly.
It seems that this problem will occur if a movie is recorded from reset or snapshot right after reset. I haven't tested other games. So I have no idea if it is a game-specified bug.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
It seems that v20 has a new bug that causes desync in the beginning of a GBA movie if you choose to record it from power-on or reset. Now I'll stick to v19.3 "the stable version".
EDIT: GBA movies recorded with v20 from power-on or reset will desync on any VBAR versions including v20 itself, while GBA movies recorded with v19 will sync on both v19 and v20.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
I think we should remove v20 from Emulator Homepages until it's been reworked to remove its plethora of bugs, because v20's original developer (Dwedit) doesn't seem at all concerned about it, so it could be a long time before it's done.
This is a problem that arises due to *zero* testing and verification on new emulators before making them an accepted emulator version here at TASvideos.
Please discuss this idea. Unless many others feel strongly against removing v20, I'm going to chop it pretty soon.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
I have the mentality of "If it ain't broke, don't fix it". VBA v20 and SNES9x 1.51 fall into that category for me. The prior versions have worked well for a couple years, but as soon as a newer version comes out, it's assumed it will be better than the previous version. They're obviously not, due to the amount of complaints about bugs present.
Note that I do not include Mupen in this category, since we didn't have a working N64 emulator before this. While some might not agree with me, I also tend to think that "A moderately workable emulator is better than no emulator at all."
That only depends on how much you're willing to suffer to have something done, instead of not suffering but just having nothing done.
We have a somewhat similar situation arising at the moment with upcoming DS emulation, and I don't feel like going the mupen way. It's a pain in the ass even to watch something this way, let alone record.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
v20 was released because of v19 and its predecessors to have really bad emulation for gbx games. It corrupts games where original system doesn't.
And I don't recommend such emulators for doing movies.
As for me, I've never seen people complaing to so supposed many bugs.
There is only one and it's desync problems with GBA movies. However, gbx games is working well iirc which was what that version was designed for.
So, no, it shouldn't be removed from the page but maybe a recommendation that v19 should be used to record gba games and maybe v20 for gbx.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
Phil wrote:
v20 was released because of v19 and its predecessors to have really bad emulation for gbx games. It corrupts games where original system doesn't.
And I don't recommend such emulators for doing movies.
I would contest that "corrupts" is a far cry from the truth, which is more of an innacuracy of echo ram.
The problem is that there are way too many bugs for it to be an acceptable release. Would you hypothetically try a new emulator (say, the next mupen) that has better compatibility, but introduces new bugs with things like frame advance missing frames or failing to work at all?
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Phil, how about all these bugs?
I also think that there aren't conclusive methods to show which timing method is more accurate. All we're going on in this case is Dwedit's posts. No one's verifying anything. Same with SNES9x 1.51. No one verified that, we all just took it as truth, and it turned out to make emulation less accurate for some games.
But, I don't know a good way to verify these things.
I guess since v20 has been used in submissions, there should remain a link to it on the EmulatorHomepages. But it definitely needs a warning by it. And I will continue to use v19 on all VBA submissions, GBA or otherwise.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
By recording two similar Castlevania - AoS movies, I found the cause:
Desynchronized movieSynchronized movie
The desynchronized one has its Lag Reduction flag mysteriously cleared by no one. In fact, I recorded both with v20!
I recorded them from the same SRAM because it is the fastest way to have differences in lags.
EDIT1: I am looking into the source to find the real evil now.
EDIT2: more details.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Well, by removing 20, we've pretty well killed all of the VBA links. v19.3 is a dead link, and the version prior is v17!
Also, the VBA-DLL links in the pinned topics are broken too.
Not exactly. It sometimes automatically turns itself off everytime I try to record a movie, and sometimes never turns itself off. o_O
EDIT: I hacked the v20 source just now, and what I succeeded in was just screwing up GBx emulations. Now Sir VG's Castlevania Legends TAS keeps out of sync. o_O
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya
I had a look at vba v20 source code and Dwedit's old post, then I noticed that nitsuja didn't apply some of fixes (bad switch statement in gbReadOpcode, for instance).
Is it intentional, otherwise do I have a wrong source code? I wonder...
I didn't make v20, although v20 was produced after I pointed out critical bugs in v19. v20 was instead based on unstable code from forgotten's series of unreleased alpha versions.
I think v20 maybe should be replaced with straight v19, but just with the echo ram patches.
Then there's also VBA-M, a "unite the forks" version of VBA which is in the works, and it's nowhere near stable.
I think v19 GBx core is better than v20 GBx core for movie recording despite of the bad timing. v20 GBx core is very buggy.
klmz wrote:
EDIT: I hacked the v20 source just now, and what I succeeded in was just screwing up GBx emulations. Now Sir VG's Castlevania Legends TAS keeps out of sync. o_O
It was caused by the codes in arm-new.h and thumb.h shown below:
When I built the Debug Version, the Macro FINAL_VERSION was not defined, and these codes were compiled, which caused one frame's delay in the intro. I am wondering whether it is correct, with or without these codes?
I can't download the source code of VBAM via SVN. Every time the request just times out. o_O
EDIT: I really don't like MFC, so I am looking for something to replace it with. Is wxWidgets a good idea? Or is this thought just to reinvent wheels?
EDIT2: Now I realized how crappy my ISP is.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
