Capturing Footage in Real-Time Without Additional Hardware from RetroPie’sLibretro Core Emulators
The following guide demonstrates how to enable the capture of real-time gameplay footage from various console systems available in the RetroPie emulator suite, a number of which can utilise the RetroArch framework to provide an integrated audio-video recording facility.
Implemented natively on a standard Raspberry Pi, this approach runs without the need for any external hardware (such as an Elgato capture-card).
My motivation to undertake what has become a sizeable research, development, and experimentation, project grew from a simple desire to obtain recordings of emulators running under RetroPie. I’d previously managed to enable the audio-video feature provided by the Atari ST emulator, Hatari, and was hopeful that a software-only solution was feasible for other systems.
RetroPie Versions Tested
At time of writing this guide has been tested on RetroPie 3.7, 3.8.1, and 4 (rc-1) setups, all running on installations of Raspbian Jessie 2016-05-27, and RetroPie 4.0.3 installed on Raspbian Jessie with Pixel 2016-09-23
Searching for other emulators offering recording, I found only the non-Libretro variant of Fuse to have in-built facilities; whilst serviceable for capturing ZX Spectrum games, the audio-video files generated by the emulator are of a decidedly non-standard format.
Fundamentally it was my experiments when attempting to transcode footage of Technician Ted captured from Fuse, first with avconv, and later with FFmpeg, and a subsequent enquiry on the RetroPie forum, which spawned the series of articles which form this how-to guide.
How-to Guide: Automatically Mount an External USB Storage Device at Boot Time, and Within Emulation Station
This how-to guide shows a method to automatically mount an external USB drive on the Raspberry Pi. The general technique which I have adopted and is common, and whilst there are similar guides available, I have adapted the approach specifically for use on a Pi running RaspbianLxde Desktop, Kodi Media Center, and Emulation Station with RetroPie.
In this article I aim both to demonstrate and expand upon the steps involved, whilst highlighting some issues which I have encountered when using this approach, and providing their resolutions.
My Raspberry Pi 3 is setup to serve triple duty as a lightweight PC replacement, running the Raspbian desktop, as a media center using Kodi, and as a retro video game emulator suite, via RetroPie. I have my machine set to boot to a custom menu at the command prompt, rather than directly to the desktop, to facilitate easy switching between these options. Please see the Related Posts section for setup guides detailing how this was achieved.
The Raspbian kernel does not automatically mount external USB drives by default; this isn’t an issue when launching the Kodi media center, or the desktop, as both have the capability to detect and mount a USB hard disk or flash storage device once it is connected.
How-to Guide: Manually Installing RetroPie: Navigating the RetroPie Setup Script Menu Structure
Following the June 8th 2016 update to the RetroPie Setup Script the functionality and menu structure have changed noticeably from the streamlined earlier incarnation.
Whilst the new (at time of writing) version 4.0 DEV allows far more control over the setup and maintenance of RetroPie, it necessarily appears a little more complex than before; in this guide I illustrate the revised layout.
How-to Guide: Compiling and Installing the FFmpeg Suite and Audio Video Codecs from Source on the Raspberry Pi
The goals of the following guide are two-fold: Firstly, to install a software package called FFmpeg, which contains numerous tools to facilitate the recording and manipulation of audio-video materials, along with several optional packages known as codecs.
Secondly, I aim not only to present a series of steps and commands, but also to provide a little illumination into the process, providing an overview of some of the key tools and concepts behind obtaining, building, and installing software on a Linux platform.
Please see the my earlier post: What is RetroPie? for a little background on both RetroPie and RetroArch.
My primary motivation for installing FFmpeg was to be able to capture real-time footage of gameplay from various console systems available in the RetroPie emulator suite, a number of which utilise the RetroArch framework that provides a facility to make live audio-video recordings.
The extremely inexpensive Raspberry Pi allows faithful emulation of Atari ST and STe machines, splendidly affirming Atari’s mid-1980’s slogan Power Without the Price; in this guide I cover the configuration and utilisation of RetroPie‘s Hatari emulator.
I have a great fondness for Atari‘s computers, having owned a 130XE before moving on to the 16-bit ST range; it was many years later that I discovered that the latter machines were largely the product of Commodore engineers, the true technological successor to the Atari 8-bit range being, through quirks of business and fate, the Amiga.
My stalwart 520STfm machine dutifully provided years of service in a broad array of roles, including: code development, primarily using Action! and GFA Basic; word-processing in 1st Word Plus; running inspiring demoscene productions; driving MIDI keyboards; and of course the inevitable core function as a gaming platform.
This guide has been written primarily for the Raspberry Pi implementation of Hatari, which for RetroPie 3.6 is the latest version, 1.9.0, released in September 2015. As the emulator has been compiled from the original source code virtually all of the following information will be equally applicable to the Windows, OSX, and other Linux platforms besides Raspbian.
Whilst the solution overall is relatively straightforward, I’ve gone into some depth in order that this post can serve as a general how-to guide, providing some insights into Bash shell scripts, including: installing scripts using the desktop GUI or command line tools; how the code file is made executable; automatically running a script after login, and after programs are exited by the user; and other related concepts.
Adding Code to Launch the Menu
– updating the .bashrc script to automatically run the menu when the Raspberry Pi first logs in
– preventing the menu from loading when Bash terminal windows are opened in the desktop, or when a remote SSH session is launched
As noted in the post detailing the installation of the Multipurpose Pi system, the RetroPie emulator system cannot be launched from the X-WindowsRaspbian desktop GUI. This restriction forced the requirement that the Pi boot to the text-mode Bash terminal, which in turn required launching of a chosen application suite via typed commands:
startx for the Raspbian desktop, kodi for the Kodi Media Center, and emulationstation for RetroPie.
Whilst this wasn’t a major issue, I wanted a method to launch a given suite without having to type commands at the Bash terminal – ideally via a menu-driven selection system. Whilst this necessarily must be text-based, it is friendlier than facing a blank command prompt upon booting.
Furthermore, I wanted the menu to automatically run when the Pi boots to the terminal, and also to be re-displayed whenever the user closes one of the selected application suites (using Kodi‘s power button, Emulation Station‘s Quit submenu, or Raspbian desktop’s main menu Shutdown option):
In this post I’ll be documenting how I set up a Raspberry Pi 3 (you can also use a Pi 2) as a lightweight PC replacement, combining a fully-fledged desktop GUI (Raspbian), Media Center (Kodi), and video games console and computer emulation suite (RetroPie).
The Pi 3 actually makes for a very capable PC replacement; this, and recent, posts, including graphics work, have been undertaken solely on the machine.
I have a couple of older Raspberry Pi machines, each of which is limited to a single task. The Model 1 Pi has been doing duty for a couple of years as a media center, and is dedicated to running XBMC (named for XBox Media Center, showing the roots of the project which is now known as Kodi).
The Pi 2 is currently used for retro video gaming, running an installation of RetroPie 2; I ill-advisedly used the retropie_setup.sh script option to delete Raspbian files that were not directly needed by RetroPie, thereby removing the option of using the machine as a desktop replacement.
Having taken delivery of a shiny new Raspberry Pi 3 I was keen to take advantage of the increased power of the machine, along with a sizable 64GB SD Card, using it to perform multiple duties: a media center, a retro-gaming system, and PC workstation. I also wanted to avoid the need for swapping SD Cards, which is both a hassle and introduces needless wear and tear on the card port.
Overclocking the Raspberry Pi 3 – Free Speed and Trade-offs
The Raspberry Pi 3, in common with the the older Pi 1 and Pi 2 models, can be overclocked – that is, the main processor, graphics chip, and memory, can be run faster than the default factory settings. Whilst more speed equals more processing power, there’s a trade-off to be considered with the new hardware that generally wasn’t an issue on the earlier systems.
Please Note: at time of writing overclocking the Pi 3 does not appear to be officially sanctioned. This is noted in a post on Gordons Projects, and can be seen in the overclocking entry in the Raspbian O/S’s raspi-config tool, which states ‘This Pi cannot be overclocked’. I do not know whether implementing any overclock options on the Pi 3 will set any internal flags and affect your warranty (early generation Pi’s do so if the Governor is bypassed). If in doubt, wait until the Raspberry Pi foundation makes a statement on the subject.
Nevertheless, the new Pi can certainly be overclocked. Whilst the process by which this is achieved remains the fundamentally the same, editing the config.txt file, overclocking is not quite as straightforward as it previously has been. The issue is one of thermodynamics, as the new model runs somewhat hotter than the those of the previous generations, at least in the case of the Pi which I took delivery of the day after the new model was released*
* The presence of high CPU temperatures on the new machine could be limited to a certain batch, or an example of the variations in CPU tolerances such as those resulting from lithographic techniques used to create the processors.
Retropie’s PCSX-ReARMed PlayStation emulator supports analogue controls, however enabling support is a little unintuitive, although not difficult. There are a few small limitations and quirks, most of which are easily circumvented, as discussed below.
For the most authentic experience, a genuine PlayStation DualShock analogue controller is recommended, or a functionally equivalent device (for instance I also use a wireless Xbox 360 controller). I am also assuming the use of a USB controller adaptor, such as a Mayflash or Wise unit (see my earlier post entitled What is RetroPie? System overview, software and hardware).
For analogue (and digital) controls a suitable joystick configuration file is required. Unfortunately controller setup can be nontrivial, and is beyond the scope of the current post; I am, however, planning to cover this topic in the near future.
Enabling Analogue Input via the RetroArch/Libretro Menu
With appropriate hardware in place, along with controller mappings, enabling analogue input requires access to the RetroArch/Libretro menu. For a little background, and further details, please see the following related posts:
Many of the entries on the RetroArch/Libretro main menu screen lead to sub menus, most of which contain numerous entries, and further sub menus. Discussed here are a couple of entries within the Core Options sub menu of especial interest to PlayStation emulation.
Core Options – Enhancing the Graphics Resolution
It is possible to force RetroPie’sPCSX-ReARMed PlayStation emulator to render graphics in a resolution considerably higher than the native modes available on the genuine console’s hardware. I should note that whilst this can make stunning visual improvements to many games on the system, unfortunately the Raspberry Pi 2 lacks enough CPU power to reliably run all games at full speed.
Rendering the output in enhanced resolution incurs significant processing overhead. The emulator in its current form is only able to utilise one of the four CPU cores present on the Pi; perhaps a future (radical) enhancement to PCSX-ReARMed will unlock the full potential of the system.