Upcoming RetroArch

Posted by on May 25, 2014 in Blog | 36 Comments

So I should do these more often. It has been quite some time since the last point release, and I’m glad to announce that things are heating up and we’re coming closer to another major release.

So let’s run through some of the things you can expect this time. Some things MIGHT still not make it for this release – but rest assured I’m working on all this and more!

New Soft Filter spec

For years we’ve basically tried to say ‘no’ to CPU-based filters, but in the end I think it was the right choice to do away with this dogma. Whether we like it or not, a programmable pipeline for GPUs is not available for every console out there, and some CPU filters can run at fullspeed with cores even on low-performance consoles/handhelds.

So we’ve revised the Soft Filter spec and upgraded it. It now features the following:

  • Multi-threading support (which allows the CPU to use more than one core to process the filter),
  • Allows for several different SIMD implementations (which theoretically allows us to create optimized SSE2/SSE3/NEON routines for filters),
  • An effort has been made to rewrite all the existing filters to C
  • More filters have been ported over.

Please be aware that a soft filter has to basically care about supporting two different color formats that a libretro core could use. One of these is RGB565 – 16-bit color – the other is XRGB8888. If you select a filter and you will find that the name shows ‘N/A’ – this tells you that the filter you just selected does not support the color format that your current core is using. Eventually we are going to strive to make every filter support both color formats.

Another important note – soft filters won’t work for Libretro GL cores like Mupen64. You’ll have to use shaders there instead.

New DSP Filter Spec

The DSP filter spec has been in RetroArch for a long time but not really much had been done with it. We’re now bringing it out more into the open and including support for it in our built-in menu system as well.

Some of the new features include:

  • Multi-threading (just like the new Soft Filter specification)
  • Options per DSP filter can be supplied through a config file
  • Possibility to stack DSP filters
  • Several different SIMD implementations of the filter function can be incorporated into the same filter. This allows for optimized versions of the code for SIMD vectorization technologies like SSE, SSE2, NEON, and Altivec (among possible others).

PSP port

So it’s been no secret that we have been working on a PSP port of RetroArch for quite some months now. Obviously, this right now is the least powerful RetroArch port so far (in terms of CPU power it is about half the speed of a Raspberry Pi), but we’re still striving to make RetroArch a really nice affair on the PSP.

We will need more time to really deliver though when it comes to the cores. Thanks to the great commits of Aliaspider, we have already managed to achieve fullspeed emulation with Gambatte (at the very least), and through some custom PSP code we have also managed to get FCEUmm to run more or les at fullspeed on the PSP as well. It’s up for debate whether we will want to whip out a version of RetroArch PSP in time for version – maybe we should wait until we have more cores behind our belt that are really appealing to PSP users, or maybe we should just get this into PSP users’ hands as quickly as possible and then supply them with lots of regular updates with each new version.

I have some plans at least to look at every great standalone PSP port and deliver a libretro port in some way. At least NJEMU (the CPS1/2/Neogeo emulator) is being strongly considered. Maybe Daedalusx64 at some point as well.

Android port

Lots of things are going to change here as well. We know that input right now is a big hot mess in the Android port. Which is why we’re going to start over from scratch with this. We will allow users to more easily map gamepads/buttons from the built-in menu AND to allow them to more easily just make their own custom configurations instead of us imposing a forced default layout on them.

We might also decide to split up the ‘auto-configured’ keymappings per pad to separate config files – that way, users could more easily edit them as well in case they are not to their own liking.

The Android port will get all existing Soft Filter and DSP filters.

There are also some Android 4.4 issues which we are intending to fix. Some of these are the new restrictions  on writing to external storage (and how this affects default gamesaves), and restoring RetroArch after sleeping.

iOS port

Similarly, input is going to be a big priority here. The developer that made Controllers For All tweak on iOS recently contacted us and helped us with the MFI controller integration in RetroArch iOS. It should now work properly with Controllers For All.

Meancoot has been kinda missing in action for months so the free MFi app has not seen any updates – so we will have to revise our strategy there and come up with a solution for RetroArch that doesn’t depend solely on it. Hopefully before we make this release we will also have all existing BTStack problems sorted which I can at least confirm exist right now.

PlayStation3/Xbox 360/Xbox 1/Wii port

So what are these ports all going to get? Well, they’re going to get for the first time all of the built-in Soft Filters and Audio DSP filters.  This is something that has been requested at least a couple of times by users of the console ports, so it’s good that we’re finally supplying that now.

Before release I’ll also hope to have single-pass shader support back into the Xbox 360 port. This coupled with the Soft Filters should be an adequate solution for people wanting more eye candy in their old games – since we can’t really go overboard with FBO scale sizes on the 360 like we can on the PS3 because of the 360′s paltry amount of RAM available for rendertargets.

Other things? The Wii port is now going to support overlays – so will the PS3 port.

Blackberry 10/Playbook

We recently got a Blackberry 10 from Blackberry (thanks for that), so we’re going to be able to supply you with an official BB10 port now. This is a big milestone for us since we were previously dependent on CatalystG for supplying us with updated versions – after he left there was a big void left to be fille. And on closer inspection now, it’s even more important that BB10 went in-house for the following reason – the Cascades frontend was severely lagging behind the rest of the RA codebase and the code integration could be done better IMHO.

I’ll probably start from scratch with the Cascades frontend. I want to make it a very nice, intuitive user interface for Blackberry users.

Contrary to what a lot of negative nancies have reported on Crackberry, I never intentionally abandoned the Blackberry Playbook – it’s just that other more important devices took up my development time and the lack of BB10 meant that it was hard to keep the common Blackberry base updated for both platforms.

Anyway, I’ll put in a solid effort to get all of the teething problems out of the way. Multi-touch support definitely needs to be improved a lot, the audio driver could perform a lot better (which is why I am working on the ALSA QSA driver again), and at least auto-rotation of the device should be available.

Other things we’ve been working on but won’t make it in time for

  • Shader parameters. This is what Themaister is working on right now. This will be really cool – it will allow parameters to be passed to shaders through a config file. Several shaders have certain variables that control certain aspects of what the shader does to the output image – changing these parameters will affect what you will be able to see on the screen. It will also be possible to change these parameters from our built-in ingame menu.
  • Menu drivers. Up until now, you’ve seen this really low-key, retro GUI. After version is out of the way, you will see at least two new menu drivers that will be really eye candy-pleasing – one will be Lakka, a GUI that models itself very closely to the XMB GUI seen on the PlayStation3 and PSP. Another menu driver that we will be introducing is a menu driver that will be based on one of mudlord’s tech demos – RetroArch Advertro. Basically this menu is going to function like the Secret of Mana ring menu. Both of these menu drivers will obviously use OpenGL for rasterization purposes.
  • I’m still going to be working on the Windows Modern UI/Surface/Phone ports. I still need a Windows 8 Phone – so gifts are still very much welcomed there since we are in lack of a device there. I do have development environments set up for Windows 8 and Windows RT so that is no problem. The Surface RT 1 is a bit long in the tooth by now but it’ll suffice for basic development.

I could have talked about some of our more exciting upcoming announcements, but maybe it’s best if I talk about that later after RetroArch is released. As for an ETA? I’m hoping to get it out at least within the next two weeks – the sooner obviously the better, but it will come down to how much work I can crank into these next two weeks.

Also – a lot more core work has been done as well. If you are using Windows and/or Android and you want an ‘in-development’ version to see how things are shaping up, you could always check out Lordashram’s 0-day builds that he posts on the forum.

RetroArch and ‘illegitimate’ crippled versions

Posted by on Apr 23, 2014 in Blog, Libretro, RetroArch | 72 Comments

RetroArch – being the reference frontend for libretro – is meant to be a no-strings attached project. That means there is no in-app advertising in it, there is no ‘donate here’ button – there is no crippled ‘Pro version’. That means there is only ‘one’ version – the full, official, real deal.

RetroArch is/was licensed under the GPL for pragmatic reasons. Had we known about the fact that app store ‘developers’ use the ‘GPL’ as a cloak for their illegitimate money racketeering ways by stating that the ‘GPL allows this’ – we probably would have thought twice about licensing it this way. But it is what it is – and RetroArch has been in existence in one form or another since early 2010 – well predating the point when emulators on tablets/phones became truly popular.

I have seen two examples now over the past weeks of ‘forks’ of RetroArch being published littered with advertising and/or other unscrupulous money-making means. Below are the two examples that have recently come to my attention:

* – Emu4iOS/AllEmu. This is a guy who also goes by the alias ‘PyroFilmsFX’. He apparently provides an ‘Over-The-Air’ service to non-jailbroken iPhones and iPads that lets them install emulators and other apps that wouldn’t be allowed to exist on the official Apple App Store. RetroArch has apparently been added to this ‘app collection’ at a certain point – and it would be an understatement to say this version of RetroArch has proven to be more popular in terms of download hits than the Cydia version for jailbroken devices ever was.

Unfortunately, there are some nasty elements to this version that makes me disapprove of this version entirely:

1 – It comes with in-game iAd advertising. Apparently, not only does it show long iAd Movies before the start of a ROM, but apparently ads also pop up while you are running a game. This ad revenue is obviously going to somebody’s account – and that somebody is certainly not us. The guy running Emu4iOS claims it is not him that is receiving the money but the ‘distributor’ of this ‘RetroArch version’ – a guy by the name of AllEmu who ‘purportedly ‘lives in Russia. I have severe doubts about whether or not that is true, but as this is the Internet there’s no way to truly know whether what somebody claims is the truth or not.

2 – Neither Emu4iOS/AllEmu offers any ‘support’ for this version. Instead, users of this ‘version’ send me e-mails and post on our forum badgering us with questions and inquiries about this version. On more than one occassion I have received e-mails questioning why I say on my site RetroArch will never have in-app advertising, yet this version does so. They don’t seem to understand that this version is not provided by us and moreover, it is making a mockery of our mission statement.

3 – These versions of ‘RetroArch’ can be installed on non-jailbroken iPhones/iPads by way of an enterprise account ‘hack’. Apple has already put a stop to this illegitimate way of ‘abusing’ enterprise accounts – but apparently you can still install these apps by setting the clock on your iDevice back by a year.

Because of ’3′, we can not in good conscience provide a ‘competing’ version with no ads in it. We are simply not going to tip toe in these hot waters  especially when we still want to maintain good relations with Apple so that we can eventually appear on the Apple App Store with legitimate versions of Dinothawr and a non-emulator focused RetroArch (and I  still maintain that RetroArch is NOT an ‘all-in-one’ emulator frontend).

** – RetroArch Blackberry 10 – There has existed a void for some time ever since CatalystG no longer provides updated versions of RetroArch on Blackberry 10. Several guys have popped up on the Crackberry forums and started to offer ‘fixed’ versions. We have not received any upstream patches for these even though GPL requires these people to provide them. Instead, they have started entertaining the thought of soliciting for donations or even – worse – in-app advertising.

We humbly asked that if people wanted to see further development of RetroArch for the Blackberry 10 that we were prepared to take on that additional development time if somebody were to provide a Blackberry 10 to us.  We don’t have a Blackberry 10 and we don’t have the monetary means to buy just about any device under the sun just for this project’s sake.

Instead, not only have we seen other people popping up and offering their own version, but even trying to start up ‘revenue chains’ around these fork versions.

When I saw this, I entered their forums to tell them that I disapproved of this and that I didn’t want them to start generating revenue off ads in RetroArch. What followed was a callous treatment by some of the Crackberry guys that I had no right to deny them this ‘revenue stream’ and that this is what the GPL ‘allowed for’.

The sad part about this is that the GPL indeed ‘allows’ for this. It is for that same reason that the GPL and the FLOSS community are frankly becoming ever-more toothless and undesirable by the way because the ‘mobile scene’ just sees it as an open letter to generating money off the work provided by others.

I find it incredibly insulting that we are in an age and an era where people no longer pay tribute and respect to authors who make it well known they DO NOT WANT RetroArch to be monetarily ‘used’ this way. You can say what you want about the GPL or whatever ‘license’ you think is a justifying excuse for your dishonest way of wanting to ‘make money off intellectual copyright infringement’ – but there is a stronger moral framework at play here that overrides all this – we DO NOT WANT YOU TO DO THIS. We are the engine behind this project – we are the ones who have invested countless amount of hours and time into this project to make it what it is now, and THIS is how we are ultimately treated by the community?

On one end we have people like the MAMEdevs blasting us and calling RA “dangerous” even though we have done everything possible to make RetroArch “free” in beer and “free” in libre. We also implemented all of the possible checks and balances to make it as undesirable as possible to ‘fork’ RA and use it in a money-racketeering way by simply offering a superior version for free with no ads or whatever. And on the other end we have this ‘mobile slime’ dev circle that just takes open source software and tries to create a revenue channel out of it. We are damned if we do, damned if we don’t.

I don’t know what the proper response to this is going to be but what is ultimately clear is that this is a continuing trend and that this is causing a massive amount of damage to the RetroArch project – to the point where I no longer enjoy working on it knowing that it’s just being used by people in this way. And what gets me even more is the lack of ‘respect’ this ultimately signals and the ‘dishonesty’ involved.

Maybe I should have expected this all along and this  is just us being the victim of our own ‘success’. Maybe we can still beat these people and not let them damage RetroArch’s reputation and crap all over it with their ‘ads’. But as more and more devices start springing up and more and more of these ‘app developers’ come up that all want to be ‘reimbursed for their owrk’, it will become ever harder to keep up with it all.

I felt like making this blog post because honestly things have gotten to a head over the past two days and it’s gotten to the point where it’s starting to negatively affect my passion for this project and the goals I’ve set for it. Make of it what you will.

Libretro Client Introduction, Arcan

Posted by on Apr 17, 2014 in Blog, Libretro | One Comment

A key quality aspect of any API such as libretro is that there are multiple, independent, actors on both sides of the imaginary fence that the API represents; Multiple applications using an API (what we typically mean with “client” or “frontend”), and multiple implementations (what we mean when we say “core”). In a perfect world, you can mix and match clients and cores to your hearts desire and adapt things to fit your own specific needs.

In the emulation world, this is one aspect that sets the libretro project apart from many others in that it is not, as some critics may cry “a bunch of emulators bundled together like some weird game of katamari damacy” but rather an attempt to retrofit emulators (and nostalgic game engines) with an API so that they may be used on more hardware and software platforms and for additional purposes (validation, automated test suites, …).

Those of you reading this already know about RetroArch, the reference client with the primary goal of being clean, fast and extremely portable. There are others, and this post is to tell you of one of those, namely Arcan (http://arcan-fe.com).

One of the primary goals for Arcan is balancing versatility (being used for fun, weird and odd things), security, speed and portability. In the software world, it sits there quietly in a corner somewhere (and rather alone) between being a windowing system (like X or Weston), a game and graphics programming framework (like Love2D, Cocos2D, VisualTK, …), a hacking and reverse engineering framework and, indeed, a libretro client. The rest of the post will be dedicated to the libretro- related parts.

The first thing to cover is that Arcan is entirely script driven. You select some scripts to run (‘theme’) and that defines what Arcan will actually do. There are two major such themes, Gridle (that tries to mix and match styles from arcade frontends like Hyperspin, Wah!Cade and AdvanceMenu) and AWB that behaves more like a desktop environment but with some unexpected features that can be used to rather extreme ends. The screenshot below, for instance, shows one instance of Arcan with AWB running two instances of Arcan, one of them also running a libretro core. The display is simultaneously mapped to a 3D model.

The sets of pictures here (Gridle Examples) and here (AWB Examples) try to show a little more in-depth of what these two themes are up to. For those that prefer videos, this slightly dated youtube playlist shows a bit more on how things work. To work properly, the initial configuration in Arcan is slightly more difficult in the sense that you don’t just pick a game and a core and off you go, there’s an additional step involved in order to prevent nasty written scripts to do bad things to your computer.

Arcan expects all file operations to happen inside two folders, “resources” and “themes”. Resources are for save-states, additional artwork, data files (roms) and cores. An additional tool (“arcan_romman.rb” on Linux/BSD and arcan launcher on Windows) performs the job of scanning through the resource folder and to download extra artwork, metadata (like title, genre) and so on. This is done by scanning two subfolders, resources\targets and resources\games. You stuff your cores (like snes9x.dll) in the targets folder, create a corresponding subfolder like (resources\games\snes9x) where you put your roms and tell the tool to start building a database. Enough with the boring stuff, look on the Arcan wiki for more details.

To round this brief introduction off, lets demo a short script that launches two random games side by side, forwarding some input to both of them. To use / run, create a folder in your themes subdirectory called retrodemo and a file named retrodemo.lua inside the new folder. Type in the codeblocks below (or use the pastebin link).

function retrodemo()
-- load a translation table to get decent names for keypresses
symtable = system_load("scripts/symtable.lua")();

– query the database and return a table of all entries for a target called ‘snes’
games = list_games({target = “snes”});

– give up if nothing was found
if (#games == 0) then
shutdown(“empty database, can’t proceed.”);

– launch two randomly selected games and save the handles for later
– game_callback is a function reference that will be called every time
– something happens in the core that we want to be alerted about
game_1 = launch_target(

game_2 = launch_target(

– place the two games side by side
move_image(game_2, VRESW * 0.5, 0);
show_image({game_1, game_2});

This function will be called when the engine is ready to run, all subsystems have been created and are up and running. We immediately launch two cores, but this still misses a callback and an function to handle input.

function game_callback(source, status)
if (status.kind == "resized") then
resize_image(source, VRESW * 0.5, VRESH);

This function will be called a lot, when the core has a frame ready, information about save state and other capabilities, if the emulation dies for any reason and so on. The first event is almost always “resize”, so we use that to force it to take up half the display.

Lastly, some input handling:

-- create a global input table that translates wasd,1 and ctrl/alt to special inputs
-- the libretro frameserver can handle.
keymap = {};
keymap["w"] = "PLAYER1_UP";
keymap["s"] = "PLAYER1_DOWN";
keymap["d"] = "PLAYER1_LEFT";
keymap["a"] = "PLAYER1_LEFT";
keymap["d"] = "PLAYER1_RIGHT";
keymap["1"] = "PLAYER1_START";
keymap["LCTRL"] = "PLAYER1_BUTTON1";
keymap["LALT"] = "PLAYER1_BUTTON2";

– this function will be called on any input received (including mouse, gamepads, etc.)
– for now, just check if its a translated device (aka keyboard)
function retrodemo_input(input)
if (not input.translated) then

– translate the input using the table above
local key = keymap[ symtable[input.keysym] ];

– if it was a valid key, forward it to the two running cores.
if (key ~= nil) then
input.label = key;
target_input(game_1, input);
target_input(game_2, input);

In closing, there is a ton of stuff to explore and play around with in Arcan (humorously called ‘the emacs of frontends’ by some, though it should of course be vim..) — both for power users and for those of you with an interest for the lighter sides of programming.

RetroArch and 240p

Posted by on Apr 1, 2014 in Blog, RetroArch | 4 Comments

I got my hands on an old CRT computer monitor (VGA, 31 kHz) this past weekend and wanted to play around with pushing out native-res, “240p” signals from RetroArch.

RetroArch doesn’t have any built-in resolution switching capabilities, but we can use the operating system’s built-in tools to handle the task. In Windows, that means using CRT_EmuDriver and a compatible GPU, while in Linux we can use xrandr from the desktop environment. You can also theoretically force resolutions via KMS, but I haven’t had any luck getting it going.

Since I’m running Ubuntu 14.04 (Trusty Tahr, LTS), I could add my custom resolution modelines to my xorg.conf and then choose between them before launching a game, but instead I am using launch scripts that add and set the desired mode at runtime. So, on my desktop, I have a little bash script that reads like this for SNES (EDIT: forgot a couple of things):

xrandr –newmode “snes” 5.979 320 332 368 380 240 242 246 263 +CSync
xrandr –addmode DVI-0 snes // replace DVI-0 with your active display; you can find it from ‘xrandr -q’
xrandr –output DVI-0 –mode snes
wait 5 // this will ensure that RetroArch doesn’t launch before the screen fully switches resolution
retroarch –menu –fullscreen -c ~/.config/retroarch/snes.cfg \  // points to my pre-configured SNES controls :)
&& xrandr –output DVI-0 –mode 1024×768 // this will take us back to a normal resolution upon exiting RA

Notice that the last line only goes off once RetroArch closes, since it’s hooked to the launch command with ‘&&’.

RGUI automatically scales to the resolution and looks great. Oddly enough, I had to set my in-game aspect ratio to 16:15 to get everything to map up properly. Regardless, the results speak for themselves (these pictures are huge; click to check out the glorious full-res shots):

Super Mario World, native resolution, unfiltered.


Super Metroid looking lovely.

The only problem I have right now is that RA is detecting a refresh rate of ~47 Hz instead of ~60, for some reason, so it’s playing a bit slowly/jumpy. I can get a normal game speed by turning on the ‘threaded video’ option, but that’s suboptimal and leads to jerky scrolling. Regardless, this is a good start and I’ll be working with Squarepusher to iron out the current issues. If anyone has any experience forcing resolutions in KMS, please leave a comment or drop by IRC at Freenode – #retroarch.

You can use the same process with arcade games, you just have to replace the script’s modeline with one that corresponds to the game’s native resolution.


Posted by on Mar 26, 2014 in Blog, RetroArch | 5 Comments

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.

Making Windows a first-class libretro citizen

Posted by on Mar 14, 2014 in Blog, Surface, Windows | 6 Comments

This will be a continously updated blog post detailing my progress on getting our Windows/Winbloze game up.

I’ve dusted off an old Core 2 Duo laptop, put Windows 7 and 8 on it, and intend on getting the Windows ports up to snuff as well as starting work on the Windows Phone/Surface ports (I can only do the Surface ports for now since I still don’t have Windows Phones to develop on, though).

A few things I will be looking at:

  • Windows Surface/Phone RetroArch port – ie. making RetroArch suitable as a Windows 8 app
  • Getting RetroArch on the Windows App Store
  • Native MSVC 2010 solutions for most libretro ports out there (should also work on MSVC 2012 and later)
  • A frontend GUI/menubar of some kind for the Windows versions.
  • Two RetroArch Win versions – one for Windows 8 Modern UI, the other Desktop one with a more conventional UI

Right now, most libretro ports depend on a Mingw build environment. I’ll try augmenting this with native MSVC solutions so that we are no longer dependent strictly on Mingw for development. Also, like the last bullet point already suggests, an effort will be made to start implementing a rational, conventional, thin ‘GUI/menubar’ around the Windows ports. While RetroArch/RGUI is still meant  to be controlled by a gamepad and this is fine, I don’t think it’s too much to ask that we are able to at least select ROMs with a native file dialog screen – and other niceties like that which a menubar would provide. The RetroArch OSX port also benefited from similar additions and I don’t think the ‘raw’ way the current Windows version is put out really does it justice.

For people who won’t like this menubar/GUI, it will be possible to disable it so that RetroArch Win32 will look and act the same as it does now.

Also, of course with the port to Surface/Windows Phone will come an additional Windows 8-centric Modern UI GUI as well. The way I see it, there will be several versions of RetroArch in the future – one that will be available on the Windows Store with a modern UI look (where we basically release several statically linked cores + RetroArch on the App Store), and there will be a RetroArch with a desktop UI look (probably looking mostly similar to SNES9x) which you will be able to download from our Libretro website.

The RetroArch for PC with the modern UI look would have severe disadvantages (dynarec code can’t work for Windows 8 Store apps, Win8 apps don’t allow dynamic libraries so we will have to release standalone emus, and lots of other shenanigans) but at least we will have a presence for enduser people that only look at the Windows Store for possible apps to download – that, and it will converge neatly with the Surface/Windows Phone port.

I hate Windows 8.x as much as the next guy and am rooting for it to fail. The only reason I am really doing this is because of the RetroArch project and my desire for it to be omnipresent. If it weren’t for this, I wouldn’t be bothering to do this right now.

I’ll update this post when more progress is made (or make a new post in case this one is taking too long).

RetroArch/Libretro Technical brochure

Posted by on Mar 12, 2014 in Blog | 6 Comments

Here is a PDF slideshow giving a nice overview of Libretro, RetroArch and the road ahead for the project -


Tomorrow updated versions of RetroArch for iOS, Android and Wii will follow- some hotfixes here and there (FBA core missing in Android, graphics glitches with Glide64 in Mupen64 iOS, resolution setting not saving in RetroArch GX, etc).

RetroArch Changelog

Posted by on Mar 10, 2014 in Android, Blog, Libretro, PlayStation3, Xbox 360 | 23 Comments

In this post I’ll try to summarize all the changes made to RetroArch since the last version ( It’s by no means complete but it gives a general overview of what has changed.

Note that the iOS version is still upcoming.


Mupen64 – W coordinate for vertices now properly set according to per-game depth bias. Should fix most of the texture wobbling issues in games.

Mupen64 – Fixed ‘No Controller connected’ issue in Banjo-Tooie.

Mupen64 – Uses refactored audio RSP plugin, includes numerous fixes such as improved MusyX support, etc.

Mupen64 – Glide64 refactoring  - Optimized dither noise code – is now done on the GPU entirely.

Mupen64 – Glide64 refactoring – codebase has been cleaned up significantly, code duplication cut down on.

Mupen64 – (Non-mobile versions) – Three-point filtering option instead of just bilinear filtering. The N64 used an inferior form of bilinear filtering called 3-sample (or 3-point) filtering. Textures were made with this in mind so many look a lot better with point filtering vs. bilinear.

Screenshot comparison here: http://imgur.com/a/M9nRP

Genesis Plus GX – Aspect ratio changes are now applied correctly.

Genesis Plus GX – Other changes.

Mednafen VB – Added Core Options for Virtual Boy – Anaglyph/Palette.

Mednafen (All) – Should correctly save SRAM to save directory now.

SNES9x – Memory leak fixes and some other improvements.

Nestopia – Core updates.

3DEngine – New core. A combination of all other 3D tech demos so far along with advanced libretro features like camera support, GPS/location services, etc. Can also be used to display still pictures (JPEG/PNG). JPEG support is buggy right now.

VBA-M – Adds Code Breaker/Game Shark support (by using cheat files).

FBA core – No more hardcoded 1024×1024 frame buffer – is now set dynamically. Should in most cases free up around 3MB of system RAM.

RetroArch PlayStation3

- Analog input works now – cores that support RETRO_ANALOG (such as TyrQuake) should now have working DualShock controls.

- Analog mapping to D-pad works now for all cores.

- Optimized slimmed down GL driver implementation some more, resulting in even lower video latency.

- All the changes made to RGUI since the last release (Core Information, reorganized Settings, possible to map frontend actions to gamepad buttons/analog axes, etc)

RetroArch Xbox 360

- Threaded Auto SRAM save should be available now.

- Reimplemented the menu – now uses the common menu code.

- XUI GUI no longer is bound to the game’s viewport – so it should no longer cut off when using certain aspect ratios.

- It’s now possible to go back a directory level in the file browser.

- It’s now possible to change path options.

- Analog input works now – cores that support RETRO_ANALOG (such as TyrQuake) should now have working DualShock controls.

- Analog mapping to D-pad works now for all cores.

- Ported MAME 2003 [0.78] to Xbox 360.

- Integer scaling works.

- All the changes made to RGUI since the last release (Core Information, reorganized Settings, possible to map frontend actions to gamepad buttons/analog axes, etc)

- Faster blitting – now uses XGCopySurface

RetroArch GX – Gamecube/Wii

- More screen resolutions.

- Overlay support.

- Faster blitting – inlined lots of GX functions.

RetroArch Xbox 1

- Threaded Auto SRAM save should be available now.

- Core Detection should work properly now.

- Aspect ratio options are fixed.

- Integer scaling should work correctly now.

- Soft filter/flicker filtering should work correctly now.

- Analog input works now – cores that support RETRO_ANALOG (such as TyrQuake) should now have working DualShock controls.

- Analog mapping to D-pad works now for all cores.

- All the changes made to RGUI since the last release (Core Information, reorganized Settings, possible to map frontend actions to gamepad buttons/analog axes, etc)

RetroArch OSX 

- Joypads should work now.

- Analog mapping to D-pad works now for all cores.

- All the changes made to RGUI since the last release (Core Information, reorganized Settings, possible to map frontend actions to gamepad buttons/analog axes, etc)

RetroArch Android

- Should fix App Not Responding issue that happened with overlays and threaded video.

- All the changes made to RGUI since the last release (Core Information, reorganized Settings, possible to map frontend actions to gamepad buttons/analog axes, etc)

RetroArch – Xbox 360 port returns

Posted by on Mar 9, 2014 in Blog, Xbox 360 | 2 Comments

So the Xbox 360 port is back again from the dead. I was unable to do anymore work on the 360 when my XDK 360 broke down. I got a Slim 360 from JPizzle and Matthie sometime ago which made it possible for me to resume work on this port.

Unified menu system

We have finally reached the stage where all the different versions of RetroArch use the same centralized menu system. This means that while they may look differently in terms of appearance, they are exactly the same functionality-wise and feature more or less the same options.

This is a big milestone, especially for the Xbox 360 port since it was always lagging massively behind the other versions when it came to features implemented. Having to duplicate work per port is really unsustainable and it’s fortunate that we finally have a more robust menu abstraction that allows us to not even think so much about the platform this is going to run on.

In similar fashion, the XUI presentation layer for the menu has been updated. It is basically a single XUI scene consisting of a listview that gets updated manually by the underlying RetroArch menu code. There may be some label updating issues still left in, but these issues will be sorted out in subsequent releases.

There are some other big advantages this time:
- The menu presentation uses a fullscreen viewport whereas the other image uses the user-defined viewport. In previous versions of RetroArch 360, the UI would only be visible on the user-defined viewport. This meant that at times the UI would be cut off and wouldn’t render fully. Thankfully this is behind us now.
- Previously, you could not ‘return’ one directory level up in the filebrowser. Since the code that the XUI layer is now using is the same as all other versions, this is now possible.
- It is now also possible (thanks to the unified menu system) to set path settings.

Please be aware that certain options in the menu may either not be available right now on Xbox 360 or serve no purpose anyway. If so desired, we may put in some ifdefs to hide some of these options for 360, but for now it tries to expose as many menu options as possible.

More features implemented

The video driver has been given a big makeover, and it now implements integer scaling options. Blitting has also been made faster, which should reduce video input latency some.

On the input side, it is now possible to map the left or right analog sticks to the D-pad. Full analog stick support has also been implemented – so cores that make use of RETRO_ANALOG functionality (such as TyrQuake) can be played now with analog controls. It is now also possible to map any button to any action. You can even bind the analog stick axes to certain frontend actions if you so desire.

Auto S-RAM Save has been carried over from the other ports. Core Detect functionality is in now.

MAME 2003 0.78

The MAME 0.78 libretro core has been out for a while now on PlayStation3, Android, iOS, Blackberry, and PC. Now it hits Xbox 360 as well. On 360 thankfully we have more than enough RAM for any game that MAME circa 2003 supported, which leaves performance as the only issue. 360 performs a little bit better than the PS3 for this core, although it’s by no means a huge difference. In any case, the Mortal Kombat/Midway DCS games should be fully playable at fullspeed with the DCS Speedhack enabled. Taito F2/F3 is borderline fullspeed, and Street Fighter The Movie and Konami GX (Sexy Parodius/Salamander 2) as well.

It should also be possible to bring up the MAME OSD menu by pressing the Right Shoulder button – and it is possible to remap the buttons from MAME’s OSD menu as well.

A work in progress

Let it be known – this release is a Work-In-Progress. There are many features that don’t work just yet, but also many new features which already work just fine.

Among the things known not to work right now is:

  • Threaded video. Don’t try to toggle it in the menu.
  • Shaders. More on this later, but for now just pretend like the shader submenu doesn’t exist (yet).
  • Onscreen keyboard. This will be added in future releases and it will allow you to input text for certain settings in the menu that require it.
  • Custom ratio. Well, this does work but it’s slightly finicky right now in terms of how to set it up. Fortunately, integer scaling will save the day for overscan correction purposes in case setting up the custom ratio proves too irksome.
  • Overlays. Not implemented yet. Just ignore the stub functions for now.
  • Netplay. Not even tested yet. It won’t be of much use anyway until the Onscreen Keyboard has been implemented.

Why no shaders yet?

This is a fair question. If you have used RetroArch PS3, then you know that one of its strong points is the shader system that allows you to configure up to eight passes at the same time, and also allows you to set Framebuffer Object sizes 2 to 5 times as big as that of the original game image. It’s fair to say that the PS3 out of all game consoles so far is in a league of its own here.

So why don’t we have this goodness on Xbox 360 yet? Well, it turns out that Microsoft just went about things in a very stupid way that basically prevents us from ever reaching this kind of visual fidelity on 360.

And it’s all due to the fault of this thing called EDRAM. The Xbox 360 came with 10MB of embedded RAM (called EDRAM) – this has long been touted as a chief selling point for 360 that made all sorts of framebuffer and anti-aliasing effects essentially “free”. However, here comes the big caveat – Microsoft expects you to put ALL your render targets (Direct3D’s equivalent term for ‘FBOs’) into 10MB of EDRAM.

And if you’re thinking that – hey – maybe I can just use a memory pool from that big unified 512MB main RAM block and put my render targets on there, bad news again – you can’t. So there is a pretty severe problem where you’re expected to put your entire framebuffer, your depth buffers and your color buffers all inside a paltry amount of RAM that is even 6MB less than the Dreamcast’s VRAM. No wonder so many Xbox 360 games had sub-720p resolutions and this spilled over into the PS3 ports as well.

Another big handicap of this EDRAM approach BTW? The shader units can’t fetch from it – so instead, the EDRAM image needs to be copied (otherwise called ‘resolved’) back to main RAM whereupon the shader unit can fetch colors from it.

Microsoft suggests using the built-in predicated tiling to ‘work around’ the EDRAM limitations but there is really nothing to work around really and it doesn’t magically ‘fix’ the structural problem either – overall it is simply inferior to what we are able to do on PS3. On PS3 I have a full 256MB segment of VRAM that I can put my render targets on, my LUT textures – whatever. This is perfect for RetroArch’s purposes since 256MB of main RAM seems to be more than enough for most cores out there (especially emulators), and that still leaves you with a big block of RAM which you can totally dedicate to graphics, shaders and LUT textures.

So – long story short? Pretty big compromises will have to be made when shaders make their return for the 360 port. Previously – before we took shaders out – we had several hacks in that already catered to this limited amount of EDRAM – for instance, game frame images could be 512×512 max in size. Obviously this will not be sustainable with upcoming cores like ScummVM running comfortably at 640×480 so a less hacky and generic solution will have to be thought of.

Maybe we will have to go with just one shader you can apply instead of allowing for several shader passes. I’ll be researching my options for In any case, this is definitely one area where PS3 has the lead and it turns out that the same situation is repeating itself now between Xbox One and PS4 – with the Xbone’s limited amount of ESRAM not capable of holding a full 1080p framebuffer, depth/color buffers etc.

Final notes

NOTE: DON’T USE OLDER CONFIG FILES WITH THIS NEW VERSION OF RETROARCH 360. Start out with the one that comes withe the release and go from there.

RetroArch going all PSP – PSP Version for Next Next release?

Posted by on Mar 9, 2014 in Blog, PSP | 5 Comments

RetroArch PSP

This one generated more interest than I had expected. The PSP code in the RetroArch codebase has been dormant for quite some time now, but I never felt like hooking it up until some weeks ago.

Aliaspider did most of the final touches on video/audio after the initial port was up and running. Implemented right now is video, audio, input, RGUI, and most of the features you’d expect from RetroArch. I’ve already been asked about whether or not RetroArch PSP will include shaders or filters, and the answer is ‘no’. PSP’s GPU is fixed function and it has no shader capabilities whatsoever. CPU filters on the other hand would be far too CPU intensive for what is already a pretty weak CPU.

So how is performance with cores? Right now, Gambatte, NXEngine, Doom and some others are running at fullspeed. Aliaspider wrote a custom resampler for Gambatte since even Themaister’s blipper turned out to be too slow for PSP. Nestopia turned out to be surprisingly slow on PSP (about half the framerate of the Raspberry Pi – around 30fps or so) and FBA is also ‘not there’ yet for performance (currently maxing out at 50fps or so for CPS2 games). The latest version of Picodrive seems to be around 50 to 55fps with Sonic 1 – so definitely still a bit slower than the last Picodrive PSP version that was released by notaz back in 2007. It deserves mentioning that most of these cores right now are pretty unoptimized – it is all just generic C code.

Anyway, given that we’re dealing with a very weak CPU here, the need for custom cores arises. My plan is to make libretro versions of NJEMU, gPSP and others so that we can have full-speed CPS1/CPS2/GBA emulation at least on PSP. Aliaspider and me are also looking at ways to improve the current core’s performance. Some of these ideas involve implementing the RETRO_RENDER_HW feature so that we can draw directly to the PSP’s framebuffer and use the raw GPU command buffer through the use of some inlined macros.

So when can you expect a first public release of RetroArch PSP? Not now at least – maybe somewhere in time for  We still believe that with a bit more work, we can release something special on PSP – which is why there will be no release right now. There will be little to no usage of the MediaEngine in cores, so if all goes well you can expect to run RetroArch PSP just fine on your Vita as well.

Remote Joy

Remember this? It was a PRX plugin for homebrew PSPs that allowed you to stream the PSP’s video/audio feed over WiFi to your computer. Well, about a year ago or so we made a very quick-and-dirty initial port to libretro.  The main advantages of this libretro core is that you will be able to use all the advanced functionality of RetroArch, that it is cross-platform and that it embeds libusb into the main core library (the original RemoteJoy was Win32-only).

Right now this core is not yet releasable and there is still some way to go before it can compete with the standalone RemoteJoy Win32 client. Maybe it will be more finished in time for

PPSSPP Libretro core

In case none of the aforementioned two things excited you, maybe this will. We will be looking at making a libretro port of PPSSPP soon. This will be the second non-tech demo libretro GL core after Mupen64. At first it will target Android, iOS, and PC. Xbox 360 support may be considered in the future if I can get my XDK box back – since developing and debugging on a Slim alone is quite painful.

PPSSPP’s GUI will probably be left in (similar to the MAME libretro cores), though it will also be possible to run games headless.