(sorry if you've seen this already. I tried posting this earlier but the forum went down or something.)
OK, I've tested out the alpha 3 and (while it's still a big improvement) I got lots of desyncs. But I'd really like to see them fixed, so I tracked them down as much as possible and will now describe them (2 separate desync issues) in as much detail as I can so they can hopefully be fixed faster:
The first desync problem is due to a general oversight in the way the rerecording is done in VBA. Here are the steps to reproduce the problem:
- Open any ROM in VBA alpha 3 (Mario Land.gb is the easiest for this example.)
- Start recording a movie (from restart or not, doesn't matter).
- Get past the title screen to the actual game, then save the state to slot 1.
- Play the game normally for a while, like 10 seconds or so, then save to slot 2.
- Load slot 1 and do something stupid and recognizable such as hitting the Start button to pause the game in-game.
- Now load slot 2 and (for the sake of example) finish the level.
- Choose to Stop recording the movie.
Now when you play back the movie, it'll get past the title screen then pause the game or whatever other stupid thing you did after loading from slot 1. This is NOT the correct result; what should be in the movie is you playing and finishing the level, with no in-game pause at all. (By the way, you can try these same steps out in Snes9x and you'll see it actually does the right thing.) It might not seem that major but it will cause loads of desyncs and headaches as it is, because (for example) every time I accidentally load an old save slot the whole movie after that point gets screwed, and frequently it's useful to load old save slots on purpose then go back to a future save and continue from there. (Presumably, to implement the correct functionality, you need to store the entire movie-in-progress along with or as part of every save state that's made while a movie is being played or recorded, which isn't very hard to do and is probably worth it unless you can think of a better way. Also, you should probably disallow the loading of non-movie save states while recording a movie.)
The second desync problem is a more specific bug with frame advance that actually has nothing to do with the movie recording itself, but it still causes desyncs in movies of many games due to incorrect emulation. Basically, it seems like a timer variable (which is often used for pseudo-randomness) is being updated differently over frames when frame advance is used as opposed to when it isn't used.
So it can be easily tested, I found an example where frame advance changes the game's behaviour in an obvious way even in the absence of any other input. Here are the instructions to reproduce the problem:
- Start up the VBA rerecording version alpha 2 or 3.
- Open up the ROM called "Pocket Bomberman (U) [C][!].gbc".
- Here is a zipped save state:
http://www.filespace.org/nitsuja/PocketBombermanTest1.zip
- Download it, unzip it, place the file inside where the ROM is, and load it by hitting F9 in the emulator.
- Watch at the top-right of the screen where a pink squid/birdo thing will pop out of a jar.
- Load state 9 again and count how many times Bomberman bumps his head on the block in the middle of the screen before the pink thing pops out. For me, it's 6 times.
- Now, Pause the emulator, load save state 9 one more time, choose "Next Frame" once from the Tools menu, then Unpause the game. This time, Bomberman only bumps his head 2 times before the pink enemy pops out.
You should be able to see the not-so-subtle difference; one frame advance just altered the timing of that enemy by about 2 full seconds! Obviously this sort of thing will cause nearly any recording of the game that uses frame advance to go out of sync when it's played back without frame advance, so this needs to be fixed. (Another game that's similarly affected: in mario land, the positions of the prizes at the end of the stage if you reach the high door are randomized differently if you use frame advance before they're chosen.)
Note that throttle changes work fine; they don't have this problem even at ultra-slow speeds. (Using the cheat finder and comparing after 1 frame of frame-advance to after 1 frame of 5% throttle, I found that the only variable being initially affected by frame advance (in Pocket Bomberman) was the one at address 00:c248 in the game's memory, if that means anything.) I think this problem does not affect GBA games, but I'm not totally sure about that either.
Finally, I also have a few feature requests:
- FRAME COUNTER! (Either toggleable or always-overlay-when-paused would be fine)
- Don't disable "Start playing movie..." when a movie is playing.
- Save the number of frames and the number of save-state loads in the header.
- Save a checksum of the ROM in the header and bring up a warning if trying to play a movie when the checksum of the ROM that's open doesn't match the one in the movie. (can be a useful sanity check)
- Don't create or use a .VM0 file. What the heck is it anyway?
- When loading a state while the emulator is paused, is it possible to draw the frame the game was saved at instead of the unhelpful total blackness?
- Get rid of the annoying "Playing a movie will load load a save state which may erase your previous battery saves" warning, or at the very least, spell "lose" correctly in the message and put a line break in the middle. (Also, this message is incorrect for movies recorded from restart, because such movies should NOT load any save states or that defeats the purpose of the movie being recorded from restart.)
