TestRun, Video Edition: Recording Gameplay – Rollercoaster Tycoon 2 (Video Samples with Brief Tutorial Video)
This is a more informal TestRun, where I was merely testing out the perceived quality of some recording codecs while attempting to get gameplay recording of Rollercoaster Tycoon 2 going. As most of you know, recording this game is not just a point-and-shoot affair. Heck, most game recording applications won’t even detect the way it is buffering and utilizing video memory, resulting in a black screen, flashing or very laggy output. After trying years ago and abandoning it temporarily, I was recently searching websites with information on trying it again. With no luck finding a starting point of information, I decided to figure it out on my own – and of course share my findings should anything turn out fruitful…
First, simply trying to record RCT2 with FRAPS and then Bandicam, turned up nothing as a result. Either it would not detect the screen (it is not using 2D/3D rendering/buffering on the videocard in a standard manner) or it would capture blackness (when trying Bandicam’s ‘Record The Screen’, for instance). Since these are two well-made recording products, I assumed other products would result in the same …result. I also seem to remember trying applications like Camtasia, back in the day..
So next, I tried good’ol ‘Virtualbox’. A staple Virtual Machine emulator (think of a little computer-running-inside-a-computer), I installed an old version of WindowsXP that I had into the GuestVM. Installing my DRM-free purchase of RCT2 from Good Old Games, I tried recording the screen. No luck, since it wasn’t using Direct3D in a way that I could record (after I finally got Direct3D working in it). I tried playing it in a Windowed VM and recording that. It wouldn’t even run for some reason. It kept trying to ‘take over’ the VM and resizing it. I tried setting my Host Computer desktop resolution to 1280×720 and getting the game to detect that and run it at that resolution, ‘Full Screen’ and ‘Seamless’. Nope. For one thing, the game kept detecting and making available only the most basic of 4:3 aspect resolutions (CRT monitor type sizes), no matter what driver/settings I used for the virtual machine (I of course wanted the more modern widescreen 16:9 ratio, as YouTube uses).
Third, I tried VMware’s ‘VMware Player’. A free virtual machine app, where the business version (VMware Workstation) is the go-to prog for business virtualization. Installing my XP and then RCT2 into the VM, I got it going in 720p rez and prepared Bandicam to record a “Rectangle On A Screen”. It worked wonderfully. So, with the odd stutter (very few and far between), I can now record RCT2 gameplay and wanted to share my findings of the ability with everyone.
I was also messing around with different recording codecs, to see what they looked like at different settings with this game at 720p. I quickly threw together this little video showing some settings and results (Sample Video). A summary of what I have set up to record Rollercoaster Tycoon 2 gameplay is just below a short analysis of the video/recordings. Again. this isn’t a ‘full/technical’ TestRun, it is just me sharing some tests I did and showing that one can indeed record RCT2. Further down, there is a video that goes over the steps in summary, then in slightly more detail, showing the steps taken on the screen, a short ‘tutorial’ I suppose. For those who haven’t figured it out or got it working yet, perhaps this information will help you out, too. Enjoy!
Recorded with: Bandicam, various quality settings, various codecs @ 1280×720 (720p HD)
Recorded game: Rollercoaster Tycoon 2 (RCT2)
Some recording data (per codec) for this test:
MJPEG @ q80 = 45,000kbps data rate (~330MB per minute of gameplay recording)
MPEG-1 @ q80 = 11,000kbps data rate (~80MB per minute of gameplay recording)
MJPEG @ q60 = 34,000kbps data rate (~250MB per minute of gameplay recording)
MPEG-1 @ q60 = 3,000kbps data rate (~22MB per minute of gameplay recording)
*XviD and x264 are omitted as results for this test as editing/recompression resulted in corrupted video output (they will be included in a future TestRun with many codecs)
Brief analysis of sample video:
- All of the MPEG-1 settings are quite watchable, unless of course the temporal gibbs effects bothers you (the little ‘ghosty/glimmer’ effects that follow around the peeps). Perhaps if I didn’t mention it, you might not have noticed? As with all recording/editing, if it ‘looks fine to you’, then you can run with it if you want. Some people “need” the best quality possible, some can watch any quality and enjoy it. If the MPEG-1 setting at 80% Quality seemed fine to you, go ahead and use that (it is about 1/4 the size of the MJPEG recordings and I have found that editing MPEG-1 is bit slower but quite possible to do in editing applications such as Sony’s Vegas line of products).
- The MJPEG at a Quality of 50 percent is watchable but messy looking, as expected since a JPG (MJPEG is a series of JPG frames) at only 50% quality would have tons of compression artifacts. 60% is just as bad, with ‘rough blocks’ everywhere (macroblock artifacting). MJPEG at Quality80 isn’t bad and very watchable, but it is much larger in bitrate usage/file size than say, MPEG-1 at the same quality setting (it is about four times larger in file size). It is the easiest codec to edit, however.
- XviD, an MPEG-4 codec, can potientially looks a lot ‘cleaner’ as it can handle smaller macroblocks/divisions of the screen (inherent in the improvements in MPEG-4 over MPEG-1) – but the output seems to have strong corruption (it leaves ‘trails’ on the screen) when attempting to edit/recompress it into a final product (as seen in the video).
- x264, a more recent ‘Advanced Video Codec’ version of MPEG-4, it records in wonderful quality and low file sizes – but all of that is hidden behind, again, corruption (‘trails’ left behind on the screen*) and slow editing.
(The editing can be helped somewhat by specifying a smaller GroupOfPictures (frames inbetween keyframes/information frames, to help seeking through the video.)
Keep in mind that for the MPEG-4 codecs, the corruption surfaces only when editing/recompressing the source video. The ‘original’ gameplay recording in MPEG-4 is quite clean and watchable, completely fine if you are just going to ‘record-and-upload’ to a video sharing site or personal website.
*More on this issue and x264 recording in a future article
- A full Codec Comparison TestRun is coming, where I test out a bunch of different codecs and see how they fare for general game recording, MPEG-1, MPEG-4, AVC/h264 (MPEG-4 Part-10), MJPEG, XviD, RGB24 and more…
Some related articles:
Game recording comparison with various codecs and settings (Minecraft)
The ghosting/blurring effect when rendering in Sony Vegas products
- Install Windows into a VM Guest (for example, a VMware virtual machine within the VMware Player application)
- Install RCT2 into that Virtual Machine, running the VM in a window (for example, 1280×720)
- Set up Bandicam to record a ‘Rectangle On A Screen’ and set the Rectangle to be the same size as the Virtual Machine running in a window (in this case, 1280×720) and line them up.