Platform: Retroarch

Retroarch is a godsend for Linux emulation. Linux always being the afterthought for emulator developers who much preferred windows, Retroarch revolutionized Linux emulation by abstracting and repackaging existing Windows emulators as "cores" using a standard API called "libretro", and a standard UI for the cores. Likewise for OSX, Android, iOS, and other operating systems. Retroarch provides a fairly quick path for moving a huge bulk of emulation compatibility to newer or emerging Operating Systems, and it is one of the priorities of the Retroarch dev team to spread compatibility as widely as possible.

One of the reasons having lots of emulators for a platform was good is that not all features were implemented by every emulator. Here's a not-comprehensive list of features that the libretro api provides:

• screenshots
• saves
• save states
• rewind
• netplay
• achievements
• cheats / hacking
• native cheats / hacking
• softpatching / dynamic patching
• standard joypad and keyboard mapping
• remapping
• mouse, multi-mouse
• rumble
• sensors
• camera
• location
• disk control

On top of that, Retroarch provides a general facilities for other emulation features that often had to be directly baked into emulators, but because Retroarch abstracts the emulation and display in separate stages:

• a standardized cli interface (very important for me)
• Video capture
• scanline / display postprocessors like CRT simulators
• a core updater for new versions

The one downside is that for emulator devs, it kind of steals their thunder, and reduces them to "core developers". Also, each core effectively hard forks the emulator from the original, so that separate maintainers and bug-fixing efforts are needed. Retroarch cores are usually a step behind their progenitor projects in accuracy and certain key feature supports, so it is generally a good idea to also try to get the original emulator's cutting edge version working.

Nevertheless, libretro forks have brought stunning degrees of accuracy and compatibility to Linux. I particularly think of Saturn, PCE, Amiga, 3DO, and others that emulator devs particularly neglected on Linux.

To run a game/rom/image via retroarch from the CLI, I typically do:

<command_to_start_retroarch> -L <path_to_core_so_file> <rom/image/dump file path>

For things like MAME (and probably for other cores with suboptions):

<command_to_start_retroarch> -L <path_to_core_so_file> '<mame_driver_name> <mame_driver_options>'

Lets look at these paths/variables:

command_to_start_retroarch

• if you did a deb or apt or non-flatpak linux app store install it will 9/10 times be:
  • retroarch
• most emulators and retroarch are moving to flatpak, which has a more complicated namespacey name, which may change. This specific namespacing should enable you to install several versions at once. Not as big a deal with retroarch, but can be quite a big deal with dedicated emulators, which sometimes break compatibility for specific software in newer releases. Most recently I had to do this with a Dosbox fork to get Windows95 emulation working.
  • flatpak run org.libretro.RetroArch/x86_64/stable
• if you are an enthusiastic lunatic that compiles from source, you can probably install it to a location of your own whim/desire

path_to_core_so_file

Retroarch on linux has its cores in .so (shared object) files. On my ubu-flavored non-flatpak, these are placed in $HOME/.config/retroarch/cores. I have both used Retroarch to download the cores using its UI "Core Downloader" (which frequently hangs while downloading/installing) or directly pulled the .so files from their build sites.

In Windows, core files are .dll files (dynamic linked library). You can invoke them in a similar way to .so files in windows BAT/CMD files with the -L option.

rom/image/dump file path

... the full path to the thing or things you want the retroarch emulator core to ... emulate. Multi-file emulations (multiple disc games for example) are usually specified with an m3u file. You can provide an absolute path to the m3u file, and then have relative paths to the disks/discs/roms inside the m3u file

Note that for "containerized" retroarch (and other emulators) often have hardcoded limited sets of directories that they can "see" rom/disk files. This is because of the security model of containerization schemes which have a lot of "enterprise" use cases. This can show up as mystifying "WHY ISN'T THIS EMULATOR WORKING" because there often is no good error message cranked out, just the emulator protesting it can't find the file that you CLEARLY have specified properly.

For flatpak, I use the Flatseal app to "break" or expand the directories the flatpak has rights to.