Since the new release of VBA-rr is scheduled to get in Dream Team Contest 3, the
experimental WIP (now Beta, to some degree) versions have to be tested more widely.
And here is the most important change to be tested - the movie recording:
What's new with VBM so far:
1) A byte in header used as the minor/revision number of VBM format.
2) The formerly unused bit of input data now becomes the new timing'ed reset. The old timing'ed reset bit now is left there for compatibility.
3) The first frame, a.k.a. Frame 0, was formerly skipped and left blank by older VBAs when recording. Now it's used to record input as other frames are. As a result, the movie length now takes it into account, but the frame count value stored in the header remains the same as before to get around with some old buggy movie tools.
See also
the VBM wiki page.
What's changed with input timing:
1) There used to be one frame of extra delay before button input was read by the game. For example, with VBA v22, if you input A at Frame 300, the game wouldn't respond to it until Frame 302. Now the delay has been removed, which means that movie input would be offset by one frame. However, with recovering the use of Frame 0, the input stream has got offset back to the original place.
2) Movies recorded from savestates with older VBAs might be affected with the timing change, because if their replaying rely on their initial button input states, i.e. their starting savestates were taken right at frames with button input made, those input states now will be overrided with their blank Frames 0. These can usually be fixed by readding their initial button input back to their Frames 0.
3) The reset signal had no extra delay at first. Neither has it at present. Therefore, they would be offset under the new timing. To work around this, the new reset has been introduced, which is typically to be emitted right one frame earlier than the old counterpart. For even better compatibilites, the old reset is still emitted at the original place in new movies. Note that new movies with the new reset at the end won't automatically get the old reset appended to it as it is truncated before that can happen. That can be done by manually prolonging the movie for the old reset to get in, though.
4) An embeded conversion tool is provided to help solve the problems described in 2) and 3).
Note: it was possible to hex-edit Frame 0 to contain the old reset in old VBMs. In that case, there's no way to precisely convert such movies to new ones.
What's the matter with the input glitch in GBx games:
1) The old implementation of GBx input clears all button states when a frame ends, due to some timer problem according to the comment in the code. With that hack, some games that don't have "typical" input reading would behave differently from the user might expect. The warp glitch in The Smurfs is a good example.
2) The timer problem described in the comment in the code should be investigated, though.
Other high priorities: Application stability, Lua support, video recording.
EDIT: Added signature.
