A RetroArch retrospective and what to look forward to

I have been following the events on a few libretro related threads in reddit and I find it quite disappointing to see the amount of hatred directed to a project that has done nothing but do what end-users wanted for more than three years now. I also find it terrible (but interesting none the less) that the social media post is more active than the actual highlight.

Disclaimer: this represents my own experiences and my points of view with regard of the situations that surround our project.


A bit of my personal history with the project:

Let’s look back all the way to 2013. RetroArch was still called SSNES, a fairly small commandline program with just a few cores, a launcher that could be used to adjust options and that’s it. No bells or whistles, just a few nice cores implemented under one frontend with a common feature set. I hadn’t really been using emulators since the zSnes days other than a few tries with mobile emulators on my WinCE device.

I just had built a game-room / tv-room. So I setup XBMC and loved it. Soon I started looking for emulators that would work nicely with my setup. I installed Nestopia and some XBMC plugin that acted as a launcher with worked mostly fine. I liked the emulation but I also like the fact that I could set hotkeys to save, load, and it presented nice OSD messages on non-game actions and I could drive the whole thing with my gamepad only. I hoped other emulators would have the same features but I was let down almost instantly. Regardless I pursued my objective with a miriad of tools (Pinnacle Game Profiler, Xpadder, Joy2Key, batch files, Daemon Tools to name a few).

Continue reading “A RetroArch retrospective and what to look forward to”

F-Droid changes

We changed the signature used to sign our nightly builds to match the signature used on the Google Play version so you may need to uninstall and reinstall in order to get updated.
In most cases it should be possible to backup the configuration, it should be located in /storage/emulated/0/Android/data/com.retroarch/files/retroarch.cfg, reinstall, run RetroArch once and copy it over to the same location.

It’s an inconvenience but it had to be done at some point.

Getting Started with RetroArch

In the past month I have seen a few guides about configuring RetroArch, while good some fail to explain some concepts, so I thought why not, I’ll make a series of blog posts about configuring RetroArch, starting from the basics.


  • Core — a core is a program that runs in RetroArch (or another libretro frontend)
  • Frontend — a frontend in this context is a program that can run libretro cores (RetroArch, Minir, Kodi’s Retroplayer are examples of this)
  • Content — content is a game/program that is run by a core, some cores also require no content
  • Retropad — retropad is RetroArch’s input abstraction controller, it’s the interface between the physical controller and the core inputs
  • Save Files — save files are saves that are made from within a game, usually cross platform and should work across emulators in most cases
  • Save States — save states are snapshots of the content menory at a particular moment, these are not always cross platform and most certainly won’t work on a different emulator that the one used to create them
  • System Files — additional files that might or not be part of the romset that might be needed to get some content to work (usually referred to by the BIOS term)
  • Autoconf Profile — a configuration file that has button definitions for a particular gamepad

Continue reading “Getting Started with RetroArch”

New nightlies

We’ve been trying to get out nightlies for as many platforms.
Recently we added OSX (64 bit) and iOS nightlies, as well as 3DS and PS Vita.

This week we’ve added cydia and f-droid repositories to out buildbot. These builds are on the bleeding edge, usually a few minutes behind the latest commit.
The URL for the cydia repository is: http://buildbot.libretro.com/repo/cydia
And the URL for the f-droid repository is: http://buildbot.libretro.com/repo/fdroid/repo

Continue reading “New nightlies”

About donations

RetroArch is and will always be free software. Unfortunately sometimes we need to pay for hosting providers or developer hardware.

A few months back, the company that was providing our (then free) hosting service was bought by another company which in turn meant we could no longer have the VPS we were using to build the nightlies nor the VPS that was used to host the actual downloads, so we had to scramble yet again, to get back on our feet.

At the moment we are still building on donated hardware but we have moved our web sites to DigitalOcean (which is not free), so after a lot of debate we’ve decided to start accepting donations.
Donations will be handled by Paypal and will help us with:

– Hosting fees
– Developer hardware

We will review donations on a monthly basis, if all of sudden we have more than we need, we may close donations temporarily until we need them again.

Just to be clear, we expect donations to be with no strings attached, donating doesn’t mean we’ll scramble to implement features on request or port RetroArch to a specific platform or port any particular piece of software to RetroArch. We’ll be providing the same software on the same manner as we are now.

We plan to add the donation buttons next week.


In the last few weeks some of us have been working on the MAME/MESS cores.

Path mapping

The MAME core used to save it’s data in the current working directory, this wasn’t consistent with other cores and it was somewhat confusing.
Some additions were made to libretro.h and RetroArch. It’s now possible to query the save directory from a core using RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY.

Paths are now mapped like this:

User generated content:
– cfg_directory retro_save_directory\[mame|mess|ume]\cfg
– nvram_directory retro_save_directory\[mame|mess|ume]\nvram
– memcard_directory retro_save_directory\[mame|mess|ume]\memcard
– input_directory retro_save_directory\[mame|mess|ume]\input
– state_directory retro_save_directory\[mame|mess|ume]\states
– snapshot_directory retro_save_directory\[mame|mess|ume]\snaps
– diff_directory retro_save_directory\[mame|mess|ume]\diff

Additional core content:
– samplepath retro_system_directory\[mame|mess|ume]\samples
– artpath retro_system_directory\[mame|mess|ume]\artwork
– cheatpath retro_system_directory\[mame|mess|ume]\cheat
– hashpath retro_system_directory\[mame|mess|ume]\hash
– inipath retro_system_directory\[mame|mess|ume]\ini

This means now it’s possible to create a global (or per-driver) ini file and it will be used. By default these cores launch with the following arguments: -joystick -noautoframeskip -samplerate 48000 -sound -cheat. There might be a core option to override these in the future but there isn’t now.

MESS/UME support

MESS and UME have been options for a while now, but they weren’t really easy to use. First of all some clarifications.

First of all, these cores work by passing arguments like you would pass on a CLI for their standalone counterparts. Loading from RGUI imposes some limitations on that regard so some assumptions are being made for you.

Second, since the 0.138 release there support for an XML format that documents the software released for the many supported systems. These are stored in the hash directory and you can obtain them from the standalone releases.

Besides being a documentation resouce, softlists allow to load software by just specifying the system and the rom name. For example on standalone mess you could do:

mess -rompath roms nes smb

With full path loading you would do:

mess -rompath roms nes roms\nes\smb.zip

The benefits are considerable when you consider that games might have more than one file, for instance multi floppy X68000 games, those would be impossible to load from RGUI without using softlists.

The downsinde, softlist roms are not the same as the ones you might already have so full path loading still works but only with simple one file based images.


We have introduced a few core options with their default values:

mame_current_mouse_enable = "disabled"
mame_current_nagscreenpatch_enable = "disabled"
mame_current_videoapproach1_enable = "disabled"
mame_boot_osd = "disabled"

The only relevant option here is mame_boot_osd, it allows you to boot to the full MAME OSD and load the games from there. You will still need to select a game and it will set MAME’s rompath to the path of the selected game.

The important parameters in this case are as follows:
-rompath D:\Games\Multi\MAME 2014

If we were to load game without mame_boot_osd
-rompath D:\Games\Multi\MAME 2014 kinst

Loading MAME games is straightforward, select your ROM and go.

In hard drive based games you should put your CHD images in the rompath like this:

|-----kinst (folder)


MESS core options are as follows:

mess_current_mouse_enable = "disabled"
mess_current_nagscreenpatch_enable = "disabled"
mess_current_videoapproach1_enable = "disabled"
mess_softlist_enable = "enabled"
mess_softlist_auto = "enabled"
mess_media_type = "cart"
mess_boot_bios = "disabled"
mess_boot_osd = "disabled"
mess_commandline = "disabled"

As you can see softlists are enabled by default and for a reason. It’s the easiest way of loading games.

– Softlists only work with softlist romsets (for instance NES contra.zip doesn’t contain contra.nes, it contains nes-ct-0 prg)
– Softlists require you to have the XML definitions in your HASH folder
– Softlists are not foolproof, two games on the same system could have the same name and different media types, for instance NES/FAMICOM/FDS Super Mario Brothers 2. smb2.zip might represent US cart version or JAP floppy disk version.
By default with mess_softlist_auto enabled it would load the cart version. If you want the floppy version you need to change mess_softlist_auto to disabled and mess_media_type to flop
– MESS requires the SYSTEM name as one of the parameters, this is gonna be taken from the rompath, that means games must be organized like this:

|-----nes (folder)
|-----famicom (folder)

– Full path loading always requires the correct mess_media_type to be specified
– Full path loading only works with single file games

Loading nestest.zip with the default options would produce the following arguments:
-rompath D:\Games\Multi\MESS 2014\nes nes nestest

Loading nestest.zip without mess_softlist_auto would produce:
-rompath D:\Games\Multi\MESS 2014\nes nes -cart nestest
This would require to set media type to cart by the way

Loading Famicom Disk System icehocky.zip would need us to disable mess_softlist_auto and set media type to flop
-rompath D:\Games\Multi\MESS 2014\famicom famicom -flop icehocky

Loading Megaman 3 (USA).zip from a No-Intro set with soflists wouldn’t work so we need to disable mess_softlist_enable and set mess_media_type to cart
-rompath D:\Games\Multi\MESS 2014\nes nes -cart D:\Games\Multi\MESS 2014\nes\Mega Man 3 (USA).zip

Booting to OSD produces a different rompath than MAME, it includes the parent path by default so it can show all systems you have roms for.
-rompath D:\Games\Multi\MESS 2014\famicom;D:\Games\Multi\MESS 2014


All the considerations of the other two cores apply.

Loading Super Gem Fighter Minimix with the default options does:
-rompath D:\Games\Multi\MAME 2014 sgemf

Loading SNES TMNT4 with the default options does:
-rompath D:\Games\Multi\MESS 2014\snes snes tmnt4j

So yeah, if you have the correct romset it should just work now.


Squarepusher has been busy rebasing the repository with the mainline MAME repository, it should now be possible to adapt to their changes really quickly. The new repository is here:



– sample rate or refresh rate on the fly
– rework global inputs
– rework per driver inputs
– core option to disable per driver inputs and default to a standard retropad assgnment
– core option to select additional content location (artwork/samples/etc) between CONTE
– commandline support is in place but not working yet

If something is not working, please feel-free to report it here or open an issue in the repo if it has been confirmed.