In a new attempt to get a usable Burn:Cycle movie out of CD-i Emulator, I decided to add multiple PNG writing as a poor substitute for AVI writing. After all, if you have the images and audio, you can always postprocess them into a movie!
I hooked up the PNG writing code from MESS/MAME, which seemed simple enough. There was the small matter of adding 24 bits per pixel bitmap support (their code handles 16 and 32 but not 24 which is however the internal format of CD-i Emulator; I had already partially added such support for the AVI writing code).
However, the resulting PNG files would not display in Explorer or any other image tool, giving messages like 'Bad file format' and 'Cannot read'. In exploring the cause for this, I was looking at memory buffers being filled and suddenly noticed that they where being filled in little-endian byte order, which is definitely wrong as PNG is a big-endian byte order file format.
The source of the problem turned out the be a configuration error with the MESS/MAME code: it needs a macro LSB_FIRST so it knows that it's running on a little-endian machine, and I had forgotten to give it one. When I fixed this, the PNG files came out right. And even better, the AVI files suddenly also seemed correct (not surprisingly, as they use the same byte order flipping macros as the PNG writing code).
So now I have both PNG writing and AVI writing hooked up in CD-i Emulator. I proceeded to do some timing tests and in the process added a few new writing options. The -writesilent option writes AVI files without audio; the -writerate option sets the framerate for the AVI files.
Full framerate AVI files still play "jumpy" on my machine but that's caused by their uncompressedness (is that even a word?); if you convert them to MP4 for uploading they play perfectly.
I uploaded a first test to YouTube; you can see it here.
If you set the AVI framerate low enough, you can do real-time movie captures. On my slow home machine I can do real-time capturing with -writerate 2 or less (which gives very jumpy AVI files, but the audio is correct).
To do non-realtime movie rendering you need to use the input recording and playback options. I did that for one of my Burn:Cycle recordings (not a very good one, but it's hard to play on my machine as the framerate it really too low and as a result the mouse gets jerky, which makes you overshoot your targets, which results in easy death at the hands of the security people).
The rendering proceeded at about 15% real-time speed while I was typing the above and is now finished; it gave me an AVI file of 27 GB for a nearly 7 minute session. There's something wrong with that file; Media Player claims it's only 33 seconds but proceeds to play all 7 minutes of it. Huh?
I also have problems converting it to MP4, probably caused by the same problems. Currently testing conversion programs to find one that can handle it...
During all of the fast machine testing yesterday, I also noticed that after a few minutes the audio begins to lag behind when it shouldn't. This is probably caused by the audio not being decoded at exactly 44.1 kHz relative to the PC timers (or something like that). When audio is playing, it really needs to be taken as the master clock for emulation speed control but that is somewhat hard with the current speed control code. Not for this beta. To ameliorate the problem, I've added a "Flush Audio" option (keyboard shortcut Ctrl-F) that allows you to manually flush the lagging audio so that it regains emulation sync.
Yesterday I also started adding proper IFF reading code, as opposed to the basic version handling only a single large data chunk that is currently used by the input playback code. This is needed so I that can properly finish the recording and playback functionality.
The beta release seems to be coming nearer...
No comments:
Post a Comment