Locked



1 2
8 9 10 11
Former player
Joined: 6/26/2004
Posts: 139
Location: Kuopio, Finland
Yey! Now I just wait for someone to do a Castlevania II: Belmont's Revenge run... absolutely the BEST music in any Castlevania-game up to date ^^ Or perhaps I'll try to make one someday.
- mazzeneko
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
mazzeneko wrote:
Now I just wait for someone to do a Castlevania II: Belmont's Revenge run...
But before that, you wait until the movie code is en-saned (sanitalized? sanized?).
shaneduddy2 wrote:
I`ll look at Bisqwits patch and see if it's better than mine
Note that the only thing I did was that I put #ifdefs around your changes (instead of removing the code you removed completely), and copied movie.cpp and movie.h files from snes9x, waiting to be customized for VBA's needs.
Emulator Coder, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
They don't appear to be gzip'd at all. Rename them to end in .diff and you're golden.
Player (206)
Joined: 5/29/2004
Posts: 5712
I don't think they're archives... I managed to view the first one in FireFox and the second one in WordPad.
put yourself in my rocketpack if that poochie is one outrageous dude
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
DeHackEd wrote:
They don't appear to be gzip'd at all. Rename them to end in .diff and you're golden.
Ah, right. Fixed. No, they are not archives at all. gz signifies for gz-compression. In unix world, compression and archiving are two distinct operations - that's why you often see filenames like .tar.gz or .tar.bz2, where tar stands for archiving. When it's just .gz or .bz2, it's merely a compressed file. The browser can transparently decompress .gz -compressed things - that's why you can directly view them.
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
OK, I've been secretly working on this all day... I wasn't sure if anything would come of it, but I've made some major progress so I thought I should probably make a status report. 1- I finally found out what was causing the weird desyncs in GB games, it's because a variable called gbJoymask wasn't being saved in the save state, causing input that's already been recorded to the movie file to change (without being recorded) upon loading a save state 1 frame after it. 2- Frame advance was being done by holding an internal emulator timer variable at 0, which screwed up the behaviour of the game sometimes. I made the simple change to set theApp.paused true instead and frame advance no longer messes up. 3- I also found an easy way to improve the timing with the GB screen (simply don't break out of the main emulation loop during mid-scan) to avoid the partially-drawn transitions that used to be all over the place. Keep in mind that all of these were pre-existing problems with the GB emulator core, it's not shanedudddy's fault it was so screwed up. Anyway, a lot of the changes/disablements shanedudddy made now seem to be unnecessary. Oh, and here's the movie format I've decided on, so far at least, so let me know if you see anything wrong with or likely to cause trouble in it: Movie File Format: (currently going with .VBM (visual boy movie) extension to avoid confusion with existing .VBV/.VMV files) Header Info Start Data Controller Data Header (64 bytes): 000 4-byte signature: 56 42 4D 1A "VBM\x1A" 004 4-byte little-endian unsigned int: version number, must be 1 (for now) 008 4-byte little-endian integer: movie "uid" - identifies the movie-savestate relationship, also used as the recording time in Unix epoch format (obviously this stuff is based on the Snes9x movie format) 00C 4-byte little-endian unsigned int: number of frames 010 4-byte little-endian unsigned int: rerecord count 014 1-byte flags: - bit 0: if "1", movie starts from an embedded "quicksave" snapshot; if "0", it doesn't - bit 1: if "1", movie starts from reset with an embedded SRAM; if "0", it doesn't - (NOTE: If both bits 0 and 1 are "0", then movie begins from power on with no SRAM or save state. If both bits 0 and 1 are "1", the movie file is invalid.) - other: reserved, set to 0 015 1-byte flags: - bit 0: controller 1 in use - bit 1: controller 2 in use (SGB games can be 2-player multiplayer) - bit 2: controller 3 in use (SGB games can be 3- or 4-player multiplayer with multitap) - bit 3: controller 4 in use (SGB games can be 3- or 4-player multiplayer with multitap) - other: reserved, set to 0 016 1-byte flags: - bit 0: if "1", movie is of a GBA game; if "0", movie is of a GB or GBC or SGB game - other: reserved, set to 0 017 1-byte flags: values of some boolean emulator options0 - bit 0: synchronize - bit 1: theApp.useOldSync - bit 2: theApp.useBiosFile - bit 3: theApp.skipBiosFile - bit 4: theApp.removeIntros - bit 5: theApp.winRtcEnable - bit 6: left+right / up+down - other: reserved, set to 0 018 4-byte little-endian unsigned int: theApp.winSaveType (value of that emulator option) 01C 4-byte little-endian unsigned int: theApp.winFlashSize (value of that emulator option) 020 4-byte little-endian unsigned int: gbEmulatorType (value of that emulator option) 024 4-byte: reserved, set to 0 028 4-byte: reserved, set to 0 02C 4-byte: reserved, set to 0 030 1-byte: reserved, set to 0 031 1-byte unsigned char: the CRC of the ROM used while recording 032 2-byte little-endian unsigned short: the Checksum of the ROM used while recording, or 00 if GBA 034 4-byte little-endian unsigned int: the Game Code of the ROM used while recording, or "\0\0\0\0" if not GBA 038 4-byte little-endian unsigned int: offset to the savestate or SRAM inside file, set to 0 if unused 03C 4-byte little-endian unsigned int: offset to the controller data inside file Info (192 bytes): After the header is 192 bytes of text for the author to put some information in. The size is fixed to both to simplify code and to make it a lot easier to hex edit author info in after the fact. Start Data: Located somewhere after the Info, as determined by the 4-byte save offset value at 0x038 in the Header. It MUST be BEFORE the controller data, however, and obviously must not overlap the controller data. Can be either a save state snapshot or SRAM, as determined by the 1-byte flags at 0x014 in the header. Also has the possibility of not existing at all, which is the same as containing SRAM all cleared to 0. Controller Data: Located somewhere after the Info, as determined by the 4-byte controller offset value at 0x03C in the Header. A stream of 2-byte bitvectors which indicate which buttons are pressed at each point in time. (They will come in groups of however many controllers are active, in increasing order.) Each value is determined by OR-ing together values for whichever of the following are pressed: 0x0001 A 0x0002 B 0x0004 Select 0x0008 Start 0x0010 Right 0x0020 Left 0x0040 Up 0x0080 Down 0x0100 R 0x0200 L 0x0400 Reset 0x0800 (unused/reserved) 0x1000 Left motion sensor 0x2000 Right motion sensor 0x4000 Down motion sensor 0x8000 Up motion sensor Reset is recordable input because some games require reset to do certain things, such as loading up an unlocked feature. It is not used to make any of the recording modes work, for example, start from reset does not put "reset" as the first input. Also, note that in real life the motion sensors are analog, but VBA already uses digital input for them and simulates their analog-ness internally. (Anybody know of games that use the motion sensor that would be good for testing? I've already implemented recording of it, along with most of the above, but I'm guessing it won't work right with re-records until I test it out and find some more bugs.) I've uploaded the code to pilif's FTP (http://nvdata.pilif.ch/new-vba-rerecording-src.zip) if anyone wants to look, but there's still a lot to left to do, on the interface side of things especially (which is to say, I have to figure out how to prevent Visual Studio from having a cow and giving mysterious linker errors whenever I alter the resource file).
Player (206)
Joined: 5/29/2004
Posts: 5712
WHOA MONSTER POST But that's still awesome, though. You actually have a handle on how to hack emulators. I just have a few questions. Does 020 store whether the game is GB, SGB, GBC, or SGB2 (SGB + GBC)? I noticed that 016 only stores whether or not it's GBA, so I was a little confused. Do you think the options for left+right and up+down should be separated in case people want one and not the other, or does that seem unnecessary? So controller data is 2 bytes per frame instead of 4 bytes now, right? Does this mean I could potentially stuff the necessary information into the beginning of my Rockman World movie and set it to 2 controllers to make it work? Would I need to use one of your "use old sync" options? Or would 2 controllers not work anyway because it's not SGB? (Speaking of multiple controllers/players, is there any potential for linked games in VisualBoyAdvance, or is that a bit too far-fetched right now?) Being able to record resets in-game is cool, but I'm sure that purists will argue that you should only be able to reset games by the A+B+Select+Start code and nothing else. What do you think? I don't really know anything about motion sensors. Were they used for Kirby's Tilt 'n' Tumble? I haven't played the game, but supposedly you have to tilt the actual Game Boy Color to play it. That sounds like something you would need motion sensors for. And this is a bit unrelated, but have you given any thought to the clock in the second-generation Pokemon games that keeps track of the current time, even when you're not playing? How does that work? How is it generally handled in an emulator? Anyway, I might be able to test the new version for you once you finish coding. Good luck!
put yourself in my rocketpack if that poochie is one outrageous dude
ventuz
He/Him
Player (125)
Joined: 10/4/2004
Posts: 940
Bag of Magic Food wrote:
Does 020 store whether the game is GB, SGB, GBC, or SGB2 (SGB + GBC)? I noticed that 016 only stores whether or not it's GBA, so I was a little confused.
maybe 016 is something to do with playing movie either GBA or gb/sgb/gbc in sync.
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food wrote:
Does 020 store whether the game is GB, SGB, GBC, or SGB2 (SGB + GBC)? I noticed that 016 only stores whether or not it's GBA, so I was a little confused.
That flag is more intended so that when someone makes a submission it can be detected which system it was for. (Which mode you have set when you made the run is stored at 020.) I wasn't sure if making the further distinction between GB, SGB, etc. was necessary, but I guess I might as well put that in as well, that's why I reserved so much space in the header. By the way, the variables for this seem to be a little hidden, but I think all GBA games run at 60 FPS, and all GB games run at either 60 or 64 FPS (I can't tell which from the code, will have to test, unless someone here knows it offhand.)
Bag of Magic Food wrote:
Do you think the options for left+right and up+down should be separated in case people want one and not the other, or does that seem unnecessary?
Seems unnecessary to me, not sure if it'd ever be useful to turn on only one of the two.
Bag of Magic Food wrote:
So controller data is 2 bytes per frame instead of 4 bytes now, right?
Yeah, I'm not sure why shanedudddy thought that 4 bytes were needed, unless there are some extra controls I'm not aware of. GBX has less buttons than SNES and Snes9x also uses 2 bytes.
Bag of Magic Food wrote:
Does this mean I could potentially stuff the necessary information into the beginning of my Rockman World movie and set it to 2 controllers to make it work? Would I need to use one of your "use old sync" options? Or would 2 controllers not work anyway because it's not SGB? (Speaking of multiple controllers/players, is there any potential for linked games in VisualBoyAdvance, or is that a bit too far-fetched right now?)
I briefly tried to write a VBV-to-VBM converter, but gave up when I realized that VBV encompasses several formats, the earlier variants of which I don't understand. The "old sync" is actually an existing emulator option for sound which requires an emulator restart to change and I'm not sure what exactly it does. However, the scanline timing thing change I made changes the frame timing, for the better I think but I will be making it optional just in case. I believe all existing movies will be able to play in this version IF someone (maybe me sometime later) is willing to write a file format converter. VBA doesn't support GBA links, and I'm guessing it's not trivial to add that support or it would've been added already. It looks like it might support GB links though, I'm not sure how but I keep seeing active link-handling code in the GB emulator core.
Bag of Magic Food wrote:
Being able to record resets in-game is cool, but I'm sure that purists will argue that you should only be able to reset games by the A+B+Select+Start code and nothing else. What do you think?
I think there's no problem if a run hits reset partway through the run, after all you can reset a real GBX, and there is no possibility of cheating because the only save data you'll be able to load is the data you've created within the run up to that point (if it's a "from power-on" movie, it will actually erase (maybe rename would be better?) your SRAM file before starting the movie).
Bag of Magic Food wrote:
I don't really know anything about motion sensors. Were they used for Kirby's Tilt 'n' Tumble? I haven't played the game, but supposedly you have to tilt the actual Game Boy Color to play it. That sounds like something you would need motion sensors for.
Yep, OK, that's one game that uses it...
Bag of Magic Food wrote:
And this is a bit unrelated, but have you given any thought to the clock in the second-generation Pokemon games that keeps track of the current time, even when you're not playing? How does that work? How is it generally handled in an emulator?
As far as I can tell this is the only feature that uses the system clock. It appears to get the time you start with it system clock, and then use the system clock to add to that time as you play, and it saves the last time it was played in the SRAM. The time updating can be replaced with using the emulator clock when a movie is active, but I'm not sure what the start time should be. The easiest thing to do would probably be to use the time stored at 008, the downside is you might have to start your run at a certain time of day. I could instead make a configurable "start time" field in the GUI, but that's a lot of work considering how few games use it. Oh, I forgot to mention this in the above, but there was a section of code in the GB core that requests input outside of the main loop, causing frames to be recorded/played at a non-constant rate that depended on how often it decided to return to the GUI, and that input wasn't even used for anything after it was requested, so I just disabled that code. Despite the fact that I don't think it would have been put in without reason, it's caused literally nothing but trouble as far as I can tell. (I was suspicious of it for a while, but when I noticed the frame counter hit 500,000 once just from starting up Rockman World and exiting the title screen, I decided it had to go .)
Player (206)
Joined: 5/29/2004
Posts: 5712
nitsuja wrote:
I think there's no problem if a run hits reset partway through the run, after all you can reset a real GBX, and there is no possibility of cheating because the only save data you'll be able to load is the data you've created within the run up to that point (if it's a "from power-on" movie, it will actually erase (maybe rename would be better?) your SRAM file before starting the movie).
I was going to say renaming was a good idea... But wait a minute... If all the save data the movie needs will be saved in the movie file itself, couldn't you just have the emulator ignore the current SRAM file completely for making "no previous save" movies, and for savedata-based movies, have it read the SRAM file once to save it into the movie file, then ignore it completely from that point onward? That seems like a more natural way to protect people's save files, and then you probably won't have to put in nagging notices about losing or renaming files (like what VBA has now).
put yourself in my rocketpack if that poochie is one outrageous dude
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food wrote:
I was going to say renaming was a good idea... But wait a minute... If all the save data the movie needs will be saved in the movie file itself, couldn't you just have the emulator ignore the current SRAM file completely for making "no previous save" movies, and for savedata-based movies, have it read the SRAM file once to save it into the movie file, then ignore it completely from that point onward? That seems like a more natural way to protect people's save files, and then you probably won't have to put in nagging notices about losing or renaming files (like what VBA has now).
I think I'll just remove the nagging notice, or at least make it a text label inside a dialog instead of a pop-up. Personally, I think that anyone who knows enough to play back one of these movies won't be stupid enough to have unrecoverable data they want in the SRAM and not in any of their emulator save states. When you play a movie in Snes9x, from snapshot or from reset, that overwrites your SRAM too, and I haven't heard any complaints about it. (VBA is really aggressive about keeping SRAM btw, I actually had a pretty hard time figuring our how to not use it (even deleting the file is not enough, it keeps backups in RAM and writes it back out to file at every opportunity.) The problem with just ignoring the SRAM is that even if I could get it to, it would just overwrite it the next time the game resets or closes or does anything, or if not, it might accidentally load whatever SRAM you have if the run contains a reset later in it, causing a desync. Getting rid of or moving the SRAM and nuking the internal backup, and then allowing things to proceed as normal, is the only reliable way I've found so far.)
Player (206)
Joined: 5/29/2004
Posts: 5712
Oh, so they made it TOO good at saving to stop it now. Yikes.
put yourself in my rocketpack if that poochie is one outrageous dude
Player (206)
Joined: 5/29/2004
Posts: 5712
Have you tried fixing Read Only mode yet? Because right now, it doesn't do anything.
put yourself in my rocketpack if that poochie is one outrageous dude
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
I'm importing and adapting the recording code of Snes9x which handles Read Only correctly, so yes. I think all I have left to do is plug some things into the GUI. Well, VBA is highly win32 dependent and I haven't done much to fix that, but I'm pretty sure it should run to Bisqwit's requirements in Wine once I make some commandline argument flags.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
nitsuja wrote:
I'm pretty sure it should run to Bisqwit's requirements in Wine once I make some commandline argument flags.
This sounds good. For clarity, I list the hopes I have for strictly-playback usage in Wine. Highly desired: - Possibility to specify the ROM filename at command line Desired: - Possibility to specify the movie filename at command line Required - either one of these two: - Possibility to specify a command that will be executed by the emulator at the moment when movie playback starts, and which the raw audio data will be written to (writeonly pipe) - exactly 44100 or 48000 audio samples per the amount of frames equivalent to a second. - Alternatively, possibility to specify a filename where the raw audio will be written to. The file must be opened with "wb" fopen mode, and the emulator must not attempt to delete it before writing. The emulator should also not care of the file size. Specifying might happen via commandline or a configuration file. Required - either one of these two: - Possibility to specify a command that will be executed by the emulator at the moment when movie playback starts, and which the raw video data will be written to (writeonly pipe) - exactly one image per frame. - Alternatively, possibility to specify a filename where the raw video data will be written to. The file must be opened with "wb" fopen mode, and the emulator must not attempt to delete it before writing. The emulator should also not care of the file size. Specifying might happen via commandline or a configuration file. Additional requirements: - The video/audio recording must not start before the movie starts playing. - The video/audio recording must not stop when the movie finishes - it must stop when the emulator is closed. - The emulator must not attempt adjusting for machine speed. It should simply output each video frame exactly once and output the equivalent amount of audio (measured in samples), without stretching or skipping. - The video data must contain all of the emulated console screen, but it should not contain menues and status lines. It may contain status messages, if they are overlaid with the emulation. - The format of the video data must be defined: width, height, depth (colour format), fps. - The format of the audio data must be defined: sampling rate, channels, depth (bitness). And of course, it must actually _run_ under Wine.
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
Well, all the "desired" ones are done already. What exactly do you mean by raw audio and video data? Currently there is the option to export to an uncompressed WAV audio file and to an AVI with no compression codec (or with a codec and sound for that matter), but I'm not sure if these count. If not, it shouldn't be too hard to add some code that outputs the raw video/audio data... do you want the formatting information (width, height, depth) to be part of the file in some format I define, or outputted elsewhere? Also, about Wine, are there any features of Windows that don't emulate properly in Wine that I should avoid? (And I don't know what OS you'll be using but it should be compatible with Win98 and up.)
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
nitsuja wrote:
Also, about Wine, are there any features of Windows that don't emulate properly in Wine that I should avoid?
Well, I need the dynamic libs that are used by the emulator. If it uses MFC or .NET, I need those libs.
nitsuja wrote:
What exactly do you mean by raw audio and video data?
For example, assume that there's a 100-second movie: - If the audio is configured as 44100 kHz stereo and sample bitness is 16-bit, it should output exactly 44100*2*2*100 bytes of audio data. - If the video is 256x224 and colour depth is 16-bit and frame rate is 60 fps, it should output exactly 256*224*2*60*100 bytes of video data.
nitsuja wrote:
do you want the formatting information (width, height, depth) to be part of the file in some format I define, or outputted elsewhere?
If you can link this module into the code, it'd be nice: http://bisqwit.iki.fi/kala/nesvideos-piece.cc (C++ code) The functions and variables defined by this module are (all are extern "C"):
/* Is video logging enabled? 0=no, 1=yes, 2=active. Default value: 0 */
int LoggingEnabled;

/* Assumed video frame rate. Default value: 60 */
unsigned FPS;

/* Get and set the video recording command (shell command) */
const char* NESVideoGetVideoCmd();
void NESVideoSetVideoCmd(const char *cmd)

/* Get and set the audio recording command (shell command) */
const char* NESVideoGetAudioCmd();
void NESVideoSetAudioCmd(const char *cmd);

/* Save 1 frame of video. (Assumed to be 16-bit RGB) */
/* Does not do anything if LoggingEnabled<2. */
void NESVideoLoggingVideo(const void*data, unsigned width,unsigned height);

/* Save N bytes of audio. bytes_per_second is required on the first call. */
/* Does not do anything if LoggingEnabled<2. */
/* The interval of calling this function is not important, as long as all the audio data is eventually written without too big delay (5 seconds is too big) */
/* This function may be called multiple times per video frame, or once per a few video frames, or anything in between. Just that all audio data must be written exactly once, and in order. */
void NESVideoLoggingAudio(const void*data, unsigned bytes, unsigned bytes_per_second)
The thing I'm concerned with is the popen() call. I don't know if it works with Wine. If it doesn't work, it has to be replaced with fopen() and "w" replaced with "wb".
xou
Joined: 4/26/2004
Posts: 118
Location: france
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
OK, I added -audiolog and -videolog flags that use the nesvideos-piece code. http://nvdata.pilif.ch/VBA-rerecording-new3.zip Here's a sample command that outputs raw video data from a run: VBA-rerecording -rom "Roms\Mega Man 5 (U) [S][!].sgb" -play "Mega Man 5 (U) [S][!].vbm" 1 -frameskip 0 -hideborder 0 -synchronize 0 -throttle 1000 -videolog "mm5.video" -frameskip 0 is to make sure all frames get in the video. (It can/should be set higher when not outputting video.) -synchronize 0 tells it to NOT limit the playing speed to the normal sound-playing speed. (For normal viewing, use synchronize 1 instead.) -throttle 1000 tells it to run at 1000% speed, or as fast as the computer can handle, whichever is lower (probably the latter). Must also have -synchronize 0 or this won't work right... (For normal viewing, use throttle 100 instead.) -hideborder 0 tells it to include the SGB border. You can set to 1 if you don't want the border in the movie, or if only outputting audio. Ignored for non-SGB games. More info: You can do -audiolog and -videolog at the same time (into separate files), but at least for me this is very slow compared to doing them at different times. You can use -quitAfter to make the application automatically quit when the frame counter hits a certain number, so you don't have to be there to shut it down if you know how many frames you want to output. (It still works if it's higher than the number of frames in the movie.) The frame counter can be viewed by hitting ".", by default. It (and any other messages) will not go into the video output. If this was a GBA game that was played with a BIOS, you could use -bios to specify your GBA BIOS location. I'm not sure if you want to require the 5-second GBA "Nintendo" logo be at the start of all GBA runs. I'm guessing not (it's part of the BIOS, not the game itself) but it's still an option when making runs just in case. I think the application still needs MFC71.dll and msvcr71.dll to run. (These are both publicly available files, if you don't have them already.)
Player (206)
Joined: 5/29/2004
Posts: 5712
Hmm, so GBA submissions will need to specify a BIOS as well as the game ROM?
put yourself in my rocketpack if that poochie is one outrageous dude
Former player
Joined: 3/9/2004
Posts: 484
Location: ­­
Don't forget there's two BIOS files that seem to be incompatible with one another. (Well, they were for me at least.)
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
I didn't realize there were multiple versions of the GBA BIOS file, are they both good ones? Usually saying it uses a BIOS file is enough, and VBA will display a checksum mismatch if it isn't. And there's always the possibility of using the emulator's built-in one, which people seem to prefer doing anyway. In previous versions of VBA some games had weird graphics/sound glitches when not using the BIOS, but I think its accuracy has improved a lot.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
nitsuja wrote:
OK, I added -audiolog and -videolog flags that use the nesvideos-piece code. http://nvdata.pilif.ch/VBA-rerecording-new3.zip
Thank you! I'll test this tomorrow evening, because I don't have time before that.
nitsuja wrote:
I think the application still needs MFC71.dll and msvcr71.dll to run. (These are both publicly available files, if you don't have them already.)
Ok. I guess I'll have them from http://www.dll-files.com/ .
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Can you please link a version that doesn't require opengl? Because it seems I have problem with opengl libs in Wine... Edit: In the source code, it seems you haven't touched the FPS variable, and that have hardcoded "LoggingEnabled" to value 2 (I'd rather hope you keep it 0 and set to "2" only when the movie is started). Are you sure the FPS (60.000) is correct for all games? Is it actually correct for _any_ game? Also, I have another question. See http://tasvideos.org/VBM.html .
Nitsuja wrote:
-frameskip 0 is to make sure all frames get in the video. (It can/should be set higher when not outputting video.) -synchronize 0 tells it to NOT limit the playing speed to the normal sound-playing speed. (For normal viewing, use synchronize 1 instead.) -throttle 1000 tells it to run at 1000% speed, or as fast as the computer can handle, whichever is lower (probably the latter). Must also have -synchronize 0 or this won't work right... (For normal viewing, use throttle 100 instead.)
These options are excellent. Thank you!
Player (206)
Joined: 5/29/2004
Posts: 5712
Well, according to a bunch of pages I found on Google, Game Boy, Game Boy Color, and Game Boy Advance have a refresh rate of 59.73 Hz, while Super Game Boy has a refresh rate of 61.17 Hz. I don't know if you want to actually record games at those exact speeds when 60 Hz will probably do, but now we have some numbers.
put yourself in my rocketpack if that poochie is one outrageous dude
1 2
8 9 10 11

Locked