I haven't been following the VBA development much,
but it seems a GB rerecording system is emerging.
The target audience of this message are the developers of the VBA rerecording capability.
These requirements are what are needed for VBA movies to be acceptable at this site. See the FMV, FCM, SMV, GMV file format specs for examples of what is ok. (#)
I require the following aspects for the VBA movie file format. All of them must be reliably (*) testable by machine.
- There's a way to detect its format (against, say, audio files)
- The file format contains information about video playback rate (Hz) (if non-constant)
- There's a way to detect if the movie begins at console power-on
- The file format contains rerecord count
- There's a way to calculate movie length without iterating the whole file through (there must be a method that works for all movies that are accepted by the emulator, including files that have garbage beyond the end of the stream)
- The file must be one piece (no separate required savestate files)
For being able to make AVI files, I also require that there is a Linux version of the emulator with movie support (£), or alternately I require a version that runs under Wine reliably WITH each frame displayed exactly once and possible to log audio to a raw file whose filename is known in advance WITHOUT having to click-here-click-there-select-this-and-that (i.e. commandline support at least).
*) Reliable within a certain marginal. For the file format check, it's good enough if it contains an ascii string such as "VBAMovie" in the beginning followed by a non-textfile control character such as EOF (26 decimal).
#) Also, we need people to have ROMs of GB games, too.
£) I can probably make it myself if I receive the complete source code of the changes that have been done.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Since I'm rewriting the ZMV support in ZSNES at the moment, I guess I should make sure I'm adhearing to the guidelines here.
What do you need this for exactly?
- The file format contains information about playback rate (Hz) (if non-constant)
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
It means that a machine should be able to deduce the length of the movie in seconds when it knows the length of the movie in frames.
This is needed for the submission handler and the subtitle generator.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Okay Hz as in NTSC or PAL not the audio frequency.
What exactly is this subtitle generator? BTW, ZMV now handles subtitles natively.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Subtitle generator is this program. It is responsible for reading a movie file and generating the standard text blurb for inserting in the beginning of the AVI.
Umm yeah where can I post the source code??
I`m doin yr 12 at the moment and have little time :)
The code is very shit, quit a hack and slash job but hey it gets the job done.
Is there any probs still with the emulation??
I didn't read the post thouroughly but you said you need people with GB roms.
Well I havefull compelte rom packs of all GB and GBC and GBA roms..
- Volkov
So that's how the case is.
Just e-mail me the source code and I'll look into it. -> bisqwit '@' iki.fi
I can develop it further, but however I can't compile Windows versions of it (someone else has to do it).
(yr 12?)
Not to mention I've made a shit load...Just cus I don't post here, lol
Pokemon pinball was a fun one, but if I recall the old version didnt have an actual ending it just repeats itself after the elite four...dont know about the new version...
- Volkov
Hey, I don't know if Bisqwit recieved source code and working into it or didn't recieve it. But I would get my butt started working on Mega Man 4 or Mega Man 5 speedrun if VBA rerecorder met those requirement, I wonder how far from done for these requirement?
Yeah, I thought about trying 4 or 5, but I don't think I have the time for them now. 1 is probably simple enough that I can get it done well without having to waste ALL my time.
put yourself in my rocketpack if that poochie is one outrageous dude
ill back up "linux support", as this (open source) generally creates a good development discussion that in the end results in a better product.
(and lets us mac users have a bite of the snack :)
I just received the source code from shaneduddddy2.
Here is the diff between VBA 1.7.2 source and the source he sent.
http://bisqwit.iki.fi/src/vba-src-shaneduddy-diff.gz
After doing the following:
- cleaning CRs
- removing a mysterious APS file (probably a microsoft c++ cache)
- removing duplicate SDL files (SDL.cpp, debugger.cpp, debugger.h)
It shrank from 800 kB to 100 kB.
It still contains some excess stuff, but I think I can figure it out.
There seems to be three things:
- Lots of things to keep game in sync
- Lots of Windows stuff (autogenerated localization stuff in resource files)
- And actually the movie stuff is very well hidden. I can't easily figure out what happens, but it seems to write the movie file in VBA::~VBA(), and initialize the movie file data in win32/MainWndFile.cpp ... This demands investigation.
There are some weird ducks in the patch... can someone see what's wrong in this patch? :)
theApp.movieFile = fopen(theApp.MovieName,"wb");
int version = 1;
for(int y=0;y<theApp.actions;y++)
{
fwrite(&theApp.MovieBuffer[y],1,4,theApp.movieFile);
}
fclose(theApp.movieFile);
movieFile = NULL;
Notably, there is no header whatsoever :P
This code was from VBA::~VBA().
In MainWnd::OnToolsRecordStopmovierecording(), the same code is found again, with a tiny slight difference:
theApp.movieFile = fopen(theApp.MovieName,"wb");
int version = 1;
for(int y=0;y<theApp.actions;y++)
{
fwrite(&theApp.MovieBuffer[y],1,4,theApp.movieFile);
}
fclose(theApp.movieFile);
theApp.movieFile = NULL;
I'm not mocking shaneduddy2. I'm glad he started the work, but I'm somewhat amused of some findings at the code. :)
I promise to look more at this at better time (weekend at last).