Video Nasties

During production of Castle Raider I had wanted to record videos showing progress on the game. I had previously made simple animations of Acorn Electron games by modifying the ElectrEm emulator to write out frames and compiling these into GIF files. However, I was now using Elkulator to develop Castle Raider, and I hadn't really looked into the code to see if something similar was possible. In the end I recorded video of the game playing on a television – it showed that the tricks I was using actually worked on real hardware.

Recently, I thought about the lack of recording features in Elkulator, and also about the lack of YouTube videos for some Electron games. YouTube user SteveBenway has a playlist of Electron games played on a television and recorded using a video camera. Similarly, user euforiagaming has a playlist of Electron games recorded from an emulator, perhaps using a desktop recording tool. An extraordinary number of games were covered by Acorn Electron World in the Five Games Five Minutes series. A lot of games are covered by these channels but, if I wanted to add more videos to the growing pile, I would want to record directly from the emulator both for convenience and to get the best quality output possible.

Record and Play

I had previously added code to dump frames from Elkulator, and had also added menu options to start and stop recording. I seem to remember thinking that my experiment hadn't worked since the images I created using a Python script to create PNG files were blank. It turned out that I had neglected to set a palette – with that in place, things started to move forward again.

Initially, I wrote out each uncompressed frame, one after the other, to a single file. Noting that mencoder can create AVI files that include embedded PNG files for the frames, I created another script to convert each recording to an AVI file. Both mplayer and ffplay could play them, with varying success, so I was encouraged to continue. However, writing the uncompressed frames to an intermediate file led to some very large recordings, so I started experimenting with writing AVI files directly from Elkulator.

In parallel with this, I started creating video files that could be embedded in Web pages using the <video> element popularised by HTML 5. This usually requires that you choose either a WebM or MP4 container with particular audio and video codecs. It turned out that ffmpeg could create WebM files successfully, if very slowly. I noticed that creating MP4 files with mencoder, ffmpeg or x264 directly was faster, so I wanted to see if I could transcode my recordings to this format instead.

By now I had started to include sound in the recordings, dumping samples into a buffer for each frame of video and interleaving it with the frame data. Knowing when to mute the sound turned out to be important in order to get accurate output, but the AVI files I created sounded fine. The trouble started when I tried to create MP4 files from them. In theory, the above tools should be able to resample the audio, but there always seemed to be a lag in the audio in the final output. After much messing around, and trying to do sampling in the conversion script, I realised that it was just easier to split the video and audio, resample the audio, and put the streams together again.

Writing AVI files directly from Elkulator wasn't successful. I tried writing BMP files into streams and using libpng to write PNGs, but I couldn't figure out the exact parameters needed to describe the video to the satisfaction of either mplayer or ffplay. In the end, I went back to dumping raw video data, only this time using zlib to compress individual frames. This approach was inspired by the use of bzip2 and gzip to compress the large recordings mentioned earlier. If regular compression tools can bring down the size to less than that for WebM or MP4 files then why not use something similar on the data directly? Screens on the Electron are rarely so complex that the Deflate algorithm would have trouble compressing them. Perhaps there is a codec that uses zlib for video data in situations like these.

With a process in place for creating videos, I started to churn out a few for my YouTube channel. Since I started with the idea of hosting my own videos, I also created a few like the one on the right. I pushed my changes to Elkulator to a repository on Bitbucket and am thinking of applying similar changes to other emulators. It should be simple to do something like this for B-em and Atomulator, but Arculator might need more consideration, though for recording old MODE 13 games the current solution might be sufficient given that we use a 640 × 256 buffer with 8 bits colour depth for the video data in Elkulator and that's what the 32-bit games would need. The only issue might be with decoding the palette used for the 256 colour modes on the Archimedes.

This document is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license.