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.

Usage

MAME:
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:

rompath
|-----kinst.zip
|-----kinst (folder)
|---------kinst.chd


MESS:

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.

Considerations:
- 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:

rompath
|-----nes (folder)
|---------smb.zip
|-----famicom (folder)
|---------smb2.zip


- 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

UME:

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.

Rebasing

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:

https://github.com/libretro/libretro-mame

TO-DO

- 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.

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):

#!/bin/bash
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.

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.”);
return;
end

– 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(
games[math.random(#games)].gameid,
LAUNCH_INTERNAL,
game_callback
);

game_2 = launch_target(
games[math.random(#games)].gameid,
LAUNCH_INTERNAL,
game_callback
);

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

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);
end
end


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
return;
end

– 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);
end
end

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 – 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.

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 1.0.0.3 – 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 1.0.0.3

• 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 1.0.0.3 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 1.0.0.3 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-PSP running inside of libretro-PPSSPP via RetroArch

ToadKing unveiled what he’s been working on lately: a libretro port of PPSSPP! Meanwhile, aliaspider and Squarepusher have been working on porting RetroArch to Sony’s PSP. Put these two works-in-progress together and you have the first instance of RetroArch-ception.

Hopefully, one or both of these projects will be ready for the upcoming 1.1 release (formerly planned to be called 1.0.0.3, but there are enough major changes even without these to warrant a more significant version bump). Even if they don’t make it, though, savvy users can always checkout and build the code from their respective repositories on github.

Here’s a rundown on what you can expect from RetroArch v1.1, the next version of RetroArch to be released. Please bear with us that it has taken us so long since v1.0.0.2 to come up with a new official release. This v1.1 version has been long in the making to ensure that this new version will be a big major milestone for RetroArch in general.

So, here’s what the release will comprise of -

Going all PSP – PPSSPP core

We have ported the popular PlayStation Portable emulator, PPSSPP, over to the libretro API. This marks the second big libretro implementation to be using libretro GL after Mupen64 Plus.

It is shaping up to be a very stunning release.  Linux users will especially appreciate the changes we’ve made which makes it possible to run PPSSPP in DRM/KMS mode (something which wasn’t possible in standalone since glew has X11 dependencies).

We’re aiming for two modes of operation. One mode will be in which the PPSSPP core functions much like standalone – where it saves everything inside a main PPSSPP assets directory and you install games from PPSSPP’s GUI. The other mode is more like a headless mode – the way every libretro core has functioned up until now. Saves will be saved in .srm form and it will be possible to directly boot ISOs/PBPs/.BINs without having to install them first from a GUI. There’s something to be said for both modes of operation.

We of course take no credit for any of the real emulation work in PPSSPP – the only thing we take credit for is porting it to the libretro API. We take nothing away of the accomplishments made by this team and we hope that the libretro port can be pushed upstream once it’s done. Please pay them a visit at http://www.ppsspp.org/ and support their efforts to improve PSP emulation – they’ve already come a long way in the two years it has been public.

We’ve made some screenshots of the core in action which you can check out here and on Twitter. We’re striving to expose as many of PPSSPP’s features as possible through core options for headless mode operation.

Needless to be said, we think this will be one of the main standout features of RetroArch v1.1. Hopefully it will open up people’s minds about how RetroArch and libretro doesn’t necessarily mean retro-grade graphics – some of these games  like Tekken 6 and Soul Calibur Broken Destiny don’t look far removed from their PS3 versions when upscaled to 2x or 3x. And to see it running as fluidly as it does in RetroArch without any audio breakup whatsoever or any frames dropped is a sight to behold.

The PPSSPP core will be available for PC (we’re aiming for Linux/OSX and Windows), and mobile (iOS/Android/Blackberry). After version 1.1 is released, we will research an Xbox 360 port.

Going all PSP – RetroArch PSP

Just having a PSP core would be one thing, but RetroArch v1.1 is going to go one extra mile by also simultaneously appearing on the PSP itself.

Nearly all of the credit for this port should go towards aliaspider- I played only a minor but crucial part in the proceedings. He has really done a bang-up job porting over a great many new cores over that are useful for the PSP, as well as improving the performance of existing cores so that they run well on the PSP.

Right now we have greatly improved the performance of FCEUmm, NXEngine, Gambatte, Mednafen PC Engine (and others) so that they run fullspeed at PSP. Please keep in mind that a PSP for general purpose code is about two times as slow as a Raspberry Pi. So you’re dealing with a very weak CPU here, and so it necessitates specific PSP-specific code to really get the most out of its performance. And thankfully the libretro API allows for this – the libretro API doesn’t prevent you from taking advantage of PSP-specific hardware features in order to speed up performance inside a core.

Aliaspider also made a port of TempGBA over to the PSP. This is a Game Boy Advance emulator based on gpSP Kai (itself based on gpSP – a now defunct emulator by Exophase). There’s also a preliminary port of the popular CPS2/Neogeo emulator, but it isn’t yet done. No idea yet if this core will make it for the v1.1 release.

Like hunterk’s previous blog post indicated, the portability of RetroArch is really coming into its own now. With the PPSSPP core, it will be possible to run RetroArch PSP itself. So essentially what you have is that RetroArch PSP can be made to run inside a PSP emulator which itself is being run inside a native platform version of RetroArch. How much farther can we go from here? The future only knows.

New cores

Several new cores will be appearing. We made a port of fMSX and BlueMSX to the libretro API. This was a home computer released in the mid-1980s that was backed up by a consortium of companies (among them a little company called Microsoft and another small fish called Sony). Oddly enough, while it couldn’t really be considered a major worldwide success, it was relatively popular in Japan and (of all countries) The Netherlands. This home computer is also noteworthy for receiving some of the first games Hideo Kojima made in his career, such as Penguin Adventure (one of the first games I ever played BTW) and Metal Gear 1/2.

There will be RetroKeyboard support for these cores to sweeten the deal, but we will also try to have some sane default configs for the RetroPad per-game for some of the more popular games.

There will also be a Vectrex core, Vecx. This was another ’80s game console, and the main notability of this game console is that it wasn’t using sprite rasterization but rather vector-based. For all practical purposes it could be considered the first real home console capable of ’3D graphics’.

Lakka – a new GUI beginning

Lakka will appear inside RetroArch starting as of version 1.1. So far, users have been using a very low-fi menu called RGUI. It is perfectly scalable from low-resolution displays to high-definition TVs, but there’s no denying it looks very much like something you would expect from a DOS program.

Lakka will be a more full-featured eyecandy UI. It will require OpenGL support inside the RetroArch version, so expect this to be usable on RetroArch PC and Android/iOS/Blackberry (PS3 maybe if it makes it for v1.1).

In terms of features and appearance, Lakka looks a lot like the PSP’s XMB frontend.

In the future, more menu drivers can be added, each being tailored towards a specific enduser preference. We have made the menu code far more generic to allow for different implementations which doesn’t require the coder to rewrite all the settings logic again and again.

You can watch a video of a prototype in action here – keep in mind that this is still a prototype and that the final version will look a lot more refined. In case you wonder, the guy showcasing it here is one of the authors responsible for the Lakka GUI -  Jean-Andre Santoni (known also as kivutar).

Audio DSPs / Software Video Filters

We already touched upon this in the previous blog post about RetroArch v1.0.0.3 (which has now morphed into version 1.1). This feature has been implemented and it makes it possible to apply audio DSP filters and video software fitlters to RetroArch’s audio/video output.

Blackberry 10

We received a Blackberry Z10 phone from Blackberry sometime ago. In return, we will fully support Blackberry 10 starting as of v1.1. A new audio driver has been written, ALSA QNX, which should be far more optimal than the OpenAL driver we had before. We also intend on writing a nice Qt UI which wraps around RetroArch itself.

I know there has been a lot of discontent among Blackberry users that there have been so few releases, but rest be assured, we’re working on it.

Revamped iOS / OSX ports

I finally bought a Macbook Pro, and so I’ve been spending a lot of work on the OSX / iOS ports of RetroArch as of late. We’ve revamped nearly all of the settings so that it is possible for settings to be exposed to WIMP menus. This will be put to good use in the OSX / iOS ports of RetroArch.

The iOS version will be totally revamped as well. Cjori was working with me sometime ago on Controllers For All support. Hopefully I will be able to approach him a week before release time or so that we can do some final beta testing before we put the final polished version out.

X-Arcade Tankstick support

I received an X-Arcade Tankstick courtesy of Xgaming, and in return this device will be fully supported. Android support will be added, and I will also look into making it possible to bind it in RetroArch as two separate game controllers instead of it being recognized as a keyboard.

After v1.1, I will look into adding USB input drivers for the PlayStation3, Wii and Xbox 360 ports so that we will be able to use the X-Arcade Tankstick on thosee consoles as well without using their proprietary gamepad converter (which costs an additional $30).

Revamped Android port

Lots of work still remaining on the Android Port. The input code has been totally revamped and it should be possible to map a new gamepad directly from the menu. New input overlays have also been made (such as a a default RetroPad overlay) which works quite well.

Maybe if we make it in time we can revamp a lot of the UI code as well using our new generalized settings code which should prevent code duplication issues in the future.

Improvements to existing cores

Lots of improvements have been made to Mupen64Plus since the last new release, as well as a lot of other cores. We will also try to bring over the MAME/MESS 2014 cor e to Android – this might not appear on the Google Play Store since this will increase the APK size by about 150MB or so – instead a more fully featured version might be available on our new website.

New server

Starting with the release of v1.1, there will be another big change – a new server (Virtual Private Server), and with it will come a buildbot. We will finally have the ability to do continuous integration tests and have daily builds for the cores and the RetroArch platform versions. The existing website will soon be moved over to the new host – the transition will be as seamless as possible to the user, so hopefully you guys won’t notice when we finally make the switch.

So when will it come?

The rest of this month will be spent by me and others feverishly working to get all of this stuff in a presentable state. We also want to do a fair bit of Quality Assurance so that this next big version will be very solid. The estimated release is somewhere in early September. A new release is contingent on all these different factors all coming together. In case some parts might take longer than expected, we might just drop a version of v1.1 with some of these features being added later. In any case, you shouldn’t have to wait longer than early September.  Again, we’re sorry for some of the delays and announcements from before but we’re really trying to ensure here that this next RetroArch release will be a real big gamechanger and so the delays are justified from that perspective. Hopefully you’ll agree once it is dropped.

Also, I’m sure I neglected to mention a fair few new features as well in this writeup. In any case, there have been far too many changes since February of this year to sum up in one blog post. When v1.1 hits I will put up a more comprehensive overview of everything that has been added ,changed and improved.

I was meaning to make this announcement after RetroArch v1.1 was released and this idea has been a bit long in the works. However, due to some sudden unexpected Kickstarters that have taken similar concepts and tried to create some kind of questionable monetization scheme around it, I felt compelled to make a pre-announcement about what we’re going to do post-RetroArch v1.1

RetroBox and why it’s needed

So the concept of RetroBox is based on a couple of problems:

• There’s no real game console that is ‘open’ and which allows RetroArch to be on there without a jailbreak or a hack of some kind.
• The ‘consoles’ that are open have an OS (Android) that is absolutely unsuitable for real-time performance oriented apps, such as (I don’t know) games. I’ve talked about this incessantly since 2012, but finally even the commercial games press seems to be becoming aware that there are definite performance bottlenecks associated to Android that prevents games from running at a stable deterministic framerate (read about all the problems here for instance – hardware that should be more than powerful enough with any other OS that do the job properly – http://www.eurogamer.net/articles/digitalfoundry-2014-nvidia-shield-tablet-review)
• SteamBox/SteamOS seemed like the perfect vehicle at first for a true ‘open source’ gaming console that gives us a little bit more freedom than the typical Sony/Nintendo/Microsoft offerings. However, plenty of problems there as well. First of all, the fact that it’s limited to Intel. Second, the high prices these SteamBoxes are going for. Third, the unconventional gamepad which seems just totally ill-suited for the kind of ‘retro games’ that are commonly played in RetroArch. Fourth, the fact that it’s still by a commercial company like Valve, which operates its own DRM app store, and therefore at any time (no matter how well-intentioned) can change what is allowed and what isn’t on the platform to suit its business model. Fifth, SteamOS is a bit less ambitious than I initially thought it would. Still being dependent on X11 means we still don’t escape the X11 performance tax when ideally they should have just made their Steam launcher run on top of DRM/KMS inside a console for optimal latency. A bloated Debian distribution might make for a ‘safe’ OS but not sure if Debian is the right way to go for a gaming OS and it’s going to cause a lot of maintenance issues in the future.
• All of these ‘alternatives’ that exist so far, either fall into the Android camp and are therefore no good (Ouya and the usual suspects), and/or they are being run by entrepreneurs who put their bottom line first before any passion for the project in general. Trying to base your operations around such a thing is like trading one evil (the big silo’ed off console platform holders) for another one, and in the end I’m not sure if the newer evil is going to be all that better to begin with.

RetroBox

So what is the RetroBox project going to amount to?

• Figure out a way to turn ARM/x86 small form factor boxes (from Intel NUCs all the way into XBMC boxes) into plug-and-play game consoles powered by RetroArch.
• Have a free open source distribution that is very lightweight.
• Strive for the most optimal conditions possible – ie. DRM/KMS mode, no X11, minimal packages installed in this distro other than what libretro ports/RA actually needs.
• Make this a ‘Proof of Concept’ for what a game console centred around the libretro API can be.
• Plug-and-play – can be operated with a gamepad entirely, keyboard and mouse are entirely optional.

RetroBox will be an open-spec game console. It’s not owned by any particular company, and it will operate much like the 3DO/VCR model where any manufacturer could make his own box. Because RetroArch is so impressively multi-platform and portable, you don’t even have to limit yourself to a specific processor architecture like ARM – most libretro ports are available for most microarchitectures available, so you can pick and choose your own hardware.

The aim here is to create an ecosystem that is more open, more optimal and definitely more interesting than what is provided so far by the Androids, iOSes, and Steams of this world. And to have a POC game console platform of our own that illustrates this best.

Why is RetroArch a good fit for this?

• From its inception, RetroArch has featured a gamepad-controlled UI that has thrown many PC users for a loop that were used to traditional WIMP point-and-click UIs. We have sticked to our guns for a long time and maintained this was the right road to travel, because we always envisioned RetroArch as this ‘game console platform’ all unto itself. RetroBox will see that high-level concept come into reality and made even more convenient.
• Our API perfectly allows for the kind of plug-and-play portability we want and need through this game controller abstraction called the RetroPad.
• RetroArch is second to none when it comes to optimal audio/video. Despite the so-far pretty lacklustre eyecandy found in its UI, there is basically nothing out there it plays second fiddle to when it comes to this department. And it’s also one of the few projects that aims for certain best practices on Linux like ensuring that everything can be ran from DRM/KMS instead of just solely depending on X11.  Latency, audio/video performance, and the impeccable shader subsystem all make for a great platform for a game console.
• People are already doing this right now anyway. There’s an obvious demand for this and there’s an obvious need among all those ARM boxes to introduce some sanity to them and to make sure that things run right out of the box. It’s a lot of work having to fiddle around with these boxes and to even get semi decent/passable performance out of them. Might as well focus on this and make it part of the overall plan

So what is this project NOT going to be?

Every effort will be undertaken to ensure this will not be your typical sleaze-ridden entrepreneurial ‘scam’ where the main incentive is ‘get-rich-quick’. There will be NO Kickstarters, no Indiegogos, no crap like that going on. I would find it morally unconscionable raking in thousands of bucks for an undertaking like this off something that is typically going to be used by most people as a way to play emulated videogames run on copyrighted trademarked video game consoles made by commercial companies. If other people want to sell out and try to make themselves a buck off this ‘retro game stuff’, they can go ahead and do it. We will try to maintain a clean nose and keep ourselves out of this potential legal quagmire. The ramifications will be huge in the long run and we refuse to have any part in it.

So, crowdfunding is not an option. So far we are going to run the RetroBox project with our own personal finances and with the hardware we already have. Which is why it’s essential that we have your support in this endeavor. Hardware gifts will be of the utmost importance in ensuring this project will become better. However, hardware gifts will only be necessary for stuff we necessarily need – so that this doesn’t become another way of profiteering altogether.

Not just about emulation

Also, RetroBox will NOT be only about emulation. I keep stressing that RetroArch is NOT a multi-system emulator frontend, and I mean it. I want to ultimately see this evolve into its own game platform, with indie games, emulators, games, virtual reality applications and rich multimedia applications all competing for the user’s same attention. So you will be also seeing a lot of additional stuff not related to emulators at all, but which will be just as exciting.

Of course, because this is an open-spec console, emulators don’t get relegated to the sidelines like they would on a traditional videogame console. This is what will make RetroBox different – the freedom is in the hands of the user, and the platform holder doesn’t dictate to the user what he/she can’t do with this box.

What about features that people want to see?

We will try to make sure that this has as many of the bells and whistles that these sleaze-ridden KIckstarter-founded projects have such as Ignition and Gamertopia. The whole NES Remix-idea for a kind of retro game console is a good idea, as is netplay, leaderboards and that kind of thing. We think we can do all of this better anyway because of RetroArch’s impeccable cross-platform nature. I think we can do this netplay in a way that every RetroArch port out so far on any platform can play together with the RetroBoxes all the same.

What about standardization?

•  There will be a Retro Performance Level (going from 0 to 15 and beyond) introduced that will range from very low-tier hardware to top-tier hardware (such as, say, SteamBox specs). Libretro cores will be able to look at this level at runtime, compare it to the performance level of the box in question and thereby evaluate whether or not the machine it’s running on will be able to run the core at fullspeed. If it can’t, it will display a warning.
• This console will be about libretro ports using the libretro API. Therefore, we can gut any part of the Linux distribution that we don’t need.
• I strongly believe in zero dependencies and keeping everything as lightweight as possible. Cores are also designed with this ‘zero-dependency’ ideal in mind. Everything that a libretro core should need should already be baked into the core from the start, so that it isn’t necessary for us to ship a truckload of packages (all of which can be potential dependencies and maintenance hazards) into the main distribution. So that means that if a core requires libusb, libusb gets baked in. If a core requires SDL, either the SDL specific code gets entirely removed or SDL gets baked in. Zero dependencies and making sure as much as possible is contained within the same dynamic library as the core itself will make this game console model sustainable.
• By keeping this limited to the libretro API, it will basically be no different from any other RetroArch port to any platform we have done before in the past, like the PS3, 360, and whatnot. It is the same concept, except this time we’re going to make it happen for all this commodity hardware that is around.

So what will all this take?

• Time
• Community support. More hands on decks for this project, the better – since we will need to cover a lot of hardware
• Dedication and the will to see this through to completion. Not going the obvious sleaze-ridden entrepreneur route obviously puts us at a large commercial disadvantage to play on an even playing field but then having risks is all part of the fun and we think users can see behind the promises of most of these other projects anyway. We have had a consistent track record so far and we are not going to compromise on our core values now either.

So when will all this start?

So yeah, this announcement is a bit of a ‘jumping the gun’ type of affair, but I felt I had to say something. I felt compelled to make this post because I see a lot of Johny-came-latelys trying to make a buck for themselves by filling an obvious gap in the market, and I just want them to know about our plans and that there’s something coming up that will put all their ‘accomplishments’ to crap. Hopefully people have gotten wise at this point and they don’t buy into another Ouya. Then again, given the obvious sleaze associated to these Kickstarter-led ‘game consoles’ and the empty hollow platitudes and ‘dumbspeak’ (and most importantly the amount of money they can accrue), you never know.

This project will start being kicked into high gear after RetroArch v1.1 is released. If you are interested in helping out in any way possible, drop us a mail at libretro@gmail.com.  This project is being started because most importantly we feel like doing it and not out of any sleazy attempt to ‘get rich quick’ or whatever the incentive is by most of these entrepreneurs. Hopefully our attempt to keep this ‘real’ and not branch off into entrepreneurial la-la land will be appreciated by endusers, developers and platform holders alike.

We have an open-source project called RetroArch. It has a development interface called libretro that allows for the easy creation of emulators and games that can plug straight into this program called RetroArch. This development interface is open to others so that they can run these pluggable emulator and game cores also in their own programs or devices. You can find this project on Github. (github.com/libretro). We also have a website – http://www.libretro.com. We started this project in late 2010 and we have been steadily increasing in popularity. We are on over 15 different hardware platforms right now that you can run RetroArch on, including Android (which this Retron5 device is based on).

These open-source programs are covered under certain licenses. Several of the emulators are covered under non-commercial licenses, which means they cannot be sold or profited from.

We have discovered that Retron5 is in violation of the licenses of several projects:

Genesis Plus GX
1. It uses the open-source emulator ‘Genesis Plus GX’ by author Eke-Eke for its Sega Genesis/Mega Drive module (https://github.com/ekeeke/Genesis-Plus-GX). This core has been licensed under a non-commercial license. It can therefore not be sold as, or part of, a commercial product.

Proof is in the accompanied screenshots at the bottom of this post.  None of the authors were contacted about their code’s use in the Retron5 hardware.

More evidence: (1, 2, 3, 4, 5, 6)

SNES9x Next

2. It uses the open-source emulator ‘SNES9x Next’, which is itself a derivative of SNES9x (https://github.com/libretro/snes9x-next). I (Squarepusher) personally made this version of SNES9x. It has a few differences compared to normal SNES9x. It has SuperFX overclocking code and it has certain game speed hacks that make games run faster on slower hardware. This comes at the expense of some graphics inaccuracies though.

We could tell it was the SNES9x Next core because the exact same strings for variables to do with the speed hacks and the SuperFX overclock code popped up in their SNES core.

SNES9x is licensed under a non-commercial license. Like Genesis Plus GX, it can therefore not be a part of a commercial product.

What also bears pointing out is that SNES9x Next has never been released in any other version than the libretro version. Libretro is the development interface of RetroArch if you remember. We will return to this later on.

Proof is in the accompanied screenshots (see below). None of the authors were contacted.

More evidence (1, 2, 3, 4, 5, 6).

FCEUmm

3. It uses the open-source emulator ‘FCEUmm’ for its NES module, which is itself a derivative of FCE Ultra. FCEUmm is licensed under the GPLv2. Technically they would have been allowed to sell this IF they had made sure their frontend was compatible with GPLv2. Unfortunately, this turns out not to be the case as we’ll find later on – since they are using GPLv3 code inside their frontend as well which is technically incompatible with this license.

Proof of it being FCEUmm is in the accompanied screenshots (see below).

More evidence (1, 2, 3, 4, 5, 6)

VBA Next

4. It uses the open-source emulator ‘VBA Next’ for its GBA module. VBA Next is a derivative of another emulator called VBA-M. I (Squarepusher) made this version specifically and I could recognize it was this version because of the fact that I have built-in a game database into this emulator. The game ID strings that are used to identify the ROMs appeared in Retron’s GBA module as well. As for the rest of the code, it is undoubtedly VBA. The screenshots showing the code flow of operation will illustrate this clearest.

VBA Next is licensed under the GPLv2. None of the authors were contacted. Proof is in the accompanied screenshots (see below).

More evidence (1, 2, 3, 4, 5, 6)

RetroArch

5. We found obvious bits of RetroArch’s sourcecode inside their frontend. Now the reason we could identify these snippets is because it is inlined Assembly code that is hard to obfuscate. The relevant parts are the ARM NEON-optimized sinc resampler code and the audio integer to float conversion routines. If you want photographic evidence, I refer you to the second link I posted below.

All of the other C code of RetroArch seems to have been obfuscated so it will take us some more time to identify these parts. What is evidently clear though is that they are already in violation of the GPL license that we covered this RetroArch code under. GPL version 3 specifically forbids TIVO-ization. Let me explain later what TIVO-ization is. It basically means that you use opensource software to make a locked-down hardware device that doesn’t allow you the freedoms that the GPL generally provides to users and developers alike.

Since they have used our libretro cores evidently and since the only way to actually use these cores is through a libretro frontend implementation, and since actual RetroArch code has already been identified in their frontend, this raises serious questions as to how much of their frontend constitutes ‘original work’ and how much of it is just RetroArch. Either way, they are in the wrong for several reasons here:

- They should have also made these publicly available for every user to download since that is part of the rules and stipulations of using GPL code.
- They made a locked-down crippled hardware device based on open-source software. You void your warranty if you attempt to modify the copyleft-licensed software on this product and furthermore it doesn’t even allow you to do this.  It is not possible to run the original, non-crippled RetroArch frontend on this device, only the crippled one provided by HyperKin. It also uses encryption as a means to obfuscate and hide the originating source of this software. This is TIVO-ization and the GPL version 3 was specifically made to prevent this.

What is TIVO-ization?

http://en.wikipedia.org/wiki/Tivoization

Tivoization /ˈtiːvoʊɨˌzeɪʃən/ is the creation of a system that incorporates software under the terms of a copyleft software license (like the GPL), but uses hardware restrictions to prevent users from running modified versions of the software on that hardware. Richard Stallman coined the term in reference to TiVo’s use of GNU GPL licensed software on the TiVo brand digital video recorders (DVR), which actively blocks users from running modified software on its hardware by design.[1][2] Stallman believes this practice denies users some of the freedom that the GNU General Public License (GNU GPL) was designed to protect.[3]

The GPL version 3 was specifically made because GPL version 2 did not provide enough safeguards against abuse like in the case of the TIVo digital video recorders. They would take from open source, not credit anybody and not give anything back either – and even create a closed platform around it where they would set themselves up as owners of the software (and in effect the hardware).

GPLv3 forbids you from building a gated community around open-source software like this and giving nothing back in return. The fact that they have used RetroArch’s GPL version 3-licensed audio resampler code in a product that is running a locked-down, encryption-crippled version of Android is already bad enough. That they don’t even provide to users the ability to run content on this device without any restrictions is another serious concern.

Anyway, as it stands right now in its current state the product is using parts of our software illegally. There were also some other things found that were legally questionable like a Microsoft-licensed Verdana font which is covered by a End-User License Agreement, so there are multiple license violations here at play.

More evidence of RetroArch appropriation (1, 2, 3, 4, 5, 6, 7).

Multiple license violations, multiple conflicting licenses, bad faith

The problems with this are many-fold, but for us it comes down to mixing non-commercial cores on this device with more permissively licensed cores,  the infringement of the emulator authors’ rights, the lack of credit paid where credit is due, the lack of freedom in the hardware device (which restricts the user in what he/she can do and makes him/her reliant on Hyperkin to serve as the gateway keeper since he/she can’t uncripple this version of Android on their device without voiding their warranty and they can’t run the uncrippled RetroArch frontend on it either), and the multiple conflicting licenses. Also, the fact that changes / patches to the sourcecode have not been provided to customers of this device. These should have been made available on a public place free of charge.

Open-source is not a matter of doing with it as you please. The license is there for a reason and it needs to be followed, and it dictates how you should go about your business when deciding to make a commercial product out of such software. GPL is known as a ‘viral license’ which means that the community behind this uses the viral nature of the GPL as an effective strategy to ensure more and more software gets licensed under the GPL, since every bit of GPL code that gets incorporated into another project needs to be made GPL or GPL-compatible as well otherwise it’s a violation of the license. As it stands right now, the software for the Retron5 is very likely illegal to distribute.

Links:

1. http://imgur.com/a/T6W4e – This image gallery shows comparisons of the infringing derivative Retron code vs. the originals

2. https://www.anonimg.com/img/5d807718b069e5dae8a4e4320fdda1ab.png – This shows the RetroArch audio resampling and audio conversion routines in the Retron frontend

3. http://i.imgur.com/81bnckH.png – Another image of the audio resampling code. Originally from this tweet: https://twitter.com/FioraAeterna/status/512790355591196673

4. Regarding the MS Verdana font: http://www.microsoft.com/typography/fonts/font.aspx?FMID=1817 – “Verdana is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.”

(EDIT: A section here about the ARM Mali drivers was removed since it appears to not be related to these issues)

(EDIT2 [9/20/2014]: Updated with more pics of evidence)

Yesterday, Hyperkin responded to our earlier article by acknowledging that they indeed did do what we claimed them of having done. In response, they posted a raw source code dump of the video game emulator software in question, confirming they were indeed infringing copyright and violating licenses.

http://www.nintendolife.com/news/2014/09/hyperkin_responds_to_accusations_of_infringing_on_the_rights_of_emulator_creators

http://retron5.in/node/9

However, they did not open source the code taken from the RetroArch project that is used within Hyperkin’s own frontend software.

By using RetroArch’s GPLv3 code, they are not only violating the license but breaking clauses that prohibit “Tivoization”

Today, Hyperkin posted another statement regarding the allegations of RetroArch code, admitting that code is indeed used in their product shipped in all versions of their firmware below the most recent release.

https://www.retro5.net/viewtopic.php?f=11&t=57&sid=638613d1c1de4fc414c15cc2654597e1&start=10#p267

I’d like to clarify one point regarding the allegations over at libretro.com: we are not using any of RetroArch in our “frontend” (libretron.so). While it is true that a few ASM functions from RetroArch were previously found in our frontend library, these were merely remnants of old test code which we unfortunately forgot to remove. The offending code has been removed as of the v2.0 update. We’re sorry that this code was left in the binary up until recently; it was merely an oversight on our part. Furthermore as you will see from the source release of the emulator cores, we have our own interface between the frontend and the core plugins, totally different from that used by RetroArch itself.

As our frontend does not include any code from the RetroArch frontend then it does not fall under GPLv3 as they claim, and thus is not bound by any of the anti “TIVO-ization” stuff.

We believe that previously distributed copies of Hyperkin’s firmware now fall under GPLv3 licensing and anti-tivoization terms and must be open sourced in order to adhere to the license. Also, we do not know the legality of selling a product with a firmware containing GPLv3 code in a TIVOized state, and then removing that GPLv3 code later on in a successive firmware update to effectively TIVO-ize it. That is something for FSF lawyers to ponder.

Visual evidence of RetroArch’s code in use by Hyperkin’s frontend binaries can be found here:
- http://imgur.com/a/i56YF
- http://www.libretro.com/index.php/retroarch-license-violations/ (see middle section titled “RetroArch”)

There is another problem with what was stated here -

https://www.retro5.net/viewtopic.php?f=11&t=57&sid=638613d1c1de4fc414c15cc2654597e1&start=10#p267

They claim they no longer have any RetroArch code in their latest firmware and that  they have their own API that they use to dynamically link the core against their frontend (unreleased and closed-source). The problem with this is that their API appears to be not GPL-compatible.

http://retron5.in/node/9

This API would need to be under a GPL-compatible license to be compatible with FCEU and VBA. Furthermore, it’s unknown what license the ‘frontend’ is licensed under, and since it’s closed-source and kept concealed, there’s no way of knowing if it infringes on the GPL license or not.

A core being exposed to the frontend through an API like this constitutes a combined work, because it is not a ‘well-separated work’ as per the terms stated here -

http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

The core doesn’t do anything without the frontend, and the frontend links to this core dynamically through dynamic linking. The core is reliant on the frontend to do the audio/video/input processing, without which nothing would be displayed on the screen, no input would be received by the core, and no audio samples would get output.

Therefore, we believe that their latest acknowledgements raises even more questions as to the level of compliance they’ve demonstrated so far with the GPL license. It raises therefore even more questions than it solves, further adding to the already quite considerable list of problems with this device.

Non-commercial cores – SNES9x Next

And of course, the fact that the two non-commercial cores are still being shipped with the device is another problem altogether. The license for SNES9x states specifically:

https://github.com/snes9xgit/snes9x/blob/master/docs/snes9x-license.txt

“Commercial users should seek permission of the copyright holders first” – refer to Hyperkin’s Retron5 licensing software page here -

http://retron5.in/node/9

They used the SNES9x Next fork specifically. This is a fork that I created specifically to serve as a libretro core. My list of contributions extends to the following:

- Added game-specific speedhacks to make them fullspeed for low-power systems like the Nintendo Wii and PlayStation3. This includes games like Final Fantasy III/VI, Star Fox, Star Fox 2, Super Mario World 2: Yoshi’s Island, and numerous other cores which were previously too slow on such devices.

- Added SuperFX overclocking code to make it possible to run SuperFX games at faster rates.

- Converted the entire codebase from C++ to C89.

- Wrote the libretro API integration parts together with Themaister/Hans-Kristian Arntzen. (NOTE: Libretro is licensed under the MIT license)

As you can guess, they have never sought my permission to use this in their commercial product. And they will never get it either. They are expressly forbidden by me (one of the copyright holders) to use this version of SNES9x in their commercial product. I’m still awaiting a response from the rest of the upstream SNES9x devs but I can’t expect their reaction will be that much different.

I will be taking steps of my own accord to ensure that this situation will be rectified.

Non-commercial cores – Genesis Plus GX

The Genesis Plus GX developers have been made aware of the facts as well and they can make their own moves as to how to deal with this.

On SNES9x Next however, I have considerable copyright claims and therefore I am in an ideal position to clamp down on this misuse of its code.

Last parting message

This can be read from Hyperkins’ response to our earlier article on Nintendolife.com -

It has always been our intention to release the relevant source code for the open source emulators used within RetroN 5. We have not been as quick as we could have been, since we have been busy improving the RetroN 5 user experience. The relevant source code has now been released. From this point forward we will not only keep our copy of this code updated for those who wish to obtain the latest version, but also submit patches for any fixes that we implement back to the original projects so that the entire community may benefit. Hyperkin will continue to endeavor to fulfill the licenses of any project used within RetroN 5 and any other software we write.

If Hyperkin is indeed serious about this, they will save my time and the time of the Genesis Plus GX developers by pre-emptively (and immediately) stripping the non-commercially licensed SNES and Genesis cores from their product. We’d rather be busy doing actual development that users benefit from and that benefits the community instead of having to go to the trouble of sending a bunch of Cease & Desist notices.

Also, let it be known that as of this moment I have contacted the FSF regarding the GPL violation matters because there remains too many unanswered and unsolved problems for us to be thoroughly satisfied. Our beef is not with the product – if Hyperkins’ Retron5 was put out in a honest way and in a way that wouldn’t infringe upon the licenses of these emulators, they would be legally allowed to use it in this way. As it stands, they did not do their homework before putting this product out and their actions so far reek of negligence, irresponsibility and a calculated move to reap the rewards of copyleft code without having to honor the license’s terms.

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about one of the big new cores you can expect – gpSP.

gpSP

There has been some complaints in the past that the Game Boy Advance libretro cores are a bit too slow on some older systems. So people with lower-performance devices should probably be glad by the arrival of this core.

This is a Game Boy Advance emulator written by Exophase originally for the PSP.  It was a fast and reasonably compatible GBA emulator that later on made an appearance on platforms like iOS and Android by unofficial porters.

Exophase stopped working on this emulator around 2009 and ever since then the codebase has been gradually decaying. The interpreter CPU core was broken on 64-bit CPUs, the x86 dynarec was 32-bit only, and there is just no central repository that aimed at making this a reasonable first-class citizen that could compete against things like VBA-M and bgba.

So the libretro core is an attempt to do all that. It uses as a base notaz’ gpsp repo but strips out the Pandora/Raspberry Pi/GP2x-specific code and aims for a more general-purpose codebase. We managed to get the ARM dynarec working on Android with some code edits, and we also fixed a few bugs that was preventing the interpreter core from working on Intel 64bit architecture.

Performance-wise, the main substantial difference is when the dynarec is enabled obviously. This core should be substantially faster right now on ARM 32bit systems (Android/iOS/Blackberry, etc) than VBA-M and the VBA-Next cores ever did. It should be fast enough on Raspberry Pi and low-end Android devices like the Xperia Play. The 32-bit x86 dynarec should also be very beneficial for users that don’t mind putting up with 32bit code. Getting a 64-bit dynarec up and running is something that is on the installment plan (for me anyway).

Savestates should work but don’t expect to be able to use savestates from other gpSP-based emulators like Gameboid or whatever.  We had to change the savestate format/size during our 64bit compatibility patches, so this is unavoidable. Though really you shouldn’t expect savestates made with non-libretro based cores to be compatible with libretro cores necessarily anyway, so let’s not pretend like this is an issue.

As for how the performance is like with the interpreter? It varies from game to game. Games like Tekken Advance and Super Mario Advance are actually slower with the interpreter core than the same games on VBA Next, but then you have the odd exceptions like Metroid, Zelda, Wario Land, Donkey Kong Country games and Astro Boy where the performance with interpreter gpSP is at least twice as fast as VBA Next. Hopefully in the long run we can fix these remaining bottlenecks with interpreter core so that there is a nice counterweight to VBA-based emulators that is at least substantially faster even with just the interpreter core.

So what’s done?

- Runs on Android with the dynarec.

- Runs on 32-bit Intel with the dynarec.

- 64bit compatibility patches so that interpreter core runs on 64bit CPUs.

- Savestates work, SRAM works, most general features you’d expect from libretro, etc.

What still needs to be done in the future?

- Get the ARM dynarec working on iOS which requires some more patches. For now, the iOS port is using the interpreter so performance is not yet as great as it should be.

- Find some way to drop support in for Normatt’s open-source BIOS replacement so that users don’t necessarily have to use the ‘official’ GBA BIOS.

- Make the performance with the interpreter core a lot more even across games. Some games getting easily twice the performance as VBA Next while some games are actually 100fps lower than VBA Next seems to indicate that there is room for improvement here.

- Do the same as what I did with VBA Next/VBA-M cores and just ‘bake in’ the needed ‘assets’ that this emulator needs. Right now it needs a file called ‘game_config.txt’ present in the system directory which enables some idle loop optimization speedhacks among other things. This should all just be baked into the core later on.

- Make it big-endian compatible so it can run on consoles and PowerPC-based Macs.

- (If I have time to waste) write a PPC dynarec so we can really have a fast GBA core on PowerPC-based targets.

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about some other new cores you can expect.

4DO – 3DO core

We ported over an emulator that emulates the 3DO. The emulator in question is 4DO, itself a fork of 3DOh.

In case you don’t know, 3DO was a short-lived game console released in the early ’90s. It was one of the first ‘next-generation’ 32bit game consoles that were released, and it predated the Sega Saturn and Sony PlayStation by about a year. Studio 3DO had some lofty ambitions at the time where the 3DO would grow up to become a video game standard like VHS where every licensee would just make a 3DO-compatible player. Unfortunately, the hardware was a bit too weak and after PlayStation/Saturn launched, 3DO died a slow death.

The few standout games for this platform can probably be counted on one hand but there was some notable stuff. A great port of Super Street Fighter II Turbo with nice redbook CD audio, Electronic Arts at the time made some good games like Need For Speed and Road Rash (both probably still better than what these franchises have become in the current-day), and Gex by Crystal Dynamics first made its appearance here. It also has the dubious distinction of playing host to the first Naughty Dog game, a game called Way Of The Warrior. It’s a standard one-on-one beat ‘em up, a bit of a Mortal Kombat/Street Fighter II derivative of the day. Guess we all have to start somewhere.

Anyway, regarding the core implementation – things are up and running, you will need a pretty powerful device for this so the faster your CPU is, the more chance you have of actually running this at fullspeed. There is a core option that lets you play games at 640×480 instead of the original framebuffer resolution. Do keep in mind that this will raise performance requirements even more. Save states are implemented but they can cause issues with certain games right now. It’s something we still have to fix.

What’s done?

- Core works, save states work but still have bugs, etc.

What’s to be done in the future?

- Backport more stuff over from 3Doh-related forks.

- Make it big-endian compatible so that it can run on big-endian consoles and old PowerPC Macs.

- Look into the multithreading speedhacks done in an Xbox 360 port of 3Doh assuming this doesn’t come too much at the cost of accuracy and can remain a toggleable option.

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about some more about new cores and some fixes to existing cores

PCSX ReARMed

This is a Sony PlayStation emulator. A core for this has already existed for quite some time. You’ll notice though that with the release of Android 5.0, the current version on the Google Play Store is broken. The new version that we’re pushing out fixes this.

Beetle/Mednafen PSX

Apart from some updates, we also added an optional widescreen hack courtesy of PCSXR. In the long run I want to look at introducing more enhancement features like this.

CatSFC

Even though we already have a lot of Super Nintendo emulator cores (well, let’s make that ‘the most amount of SNES cores out of any project’), a lot of them still had too high performance requirements for some really low-power devices out there. CatSFC is a libretro fork of SNES9x based on SNES9x 1.43. It should be a lot faster than SNES9x Next (our current fastest SNES core if you exclude PocketSNES).

The nice thing about our fork of CatSFC is that we added some stuff to it in the progress. For instance, SNES9x’s sound pre-blargg APU has always been quite bad. So what we did with CatSFC was put it in optionally. Even with the blargg APU it’s still a lot faster than SNES9x Next.

Obviously this core might only be interesting for people that have devices where power is not at a premium, like the Raspberry Pi, Xperia Play and similar low-power systems like that. The more choice the merrier.

What will be done in the future?

- Should already be endian-safe but you never know. Will give this some test runs on some PowerPC-based Macs I currently have where even SNES9x Next can be too slow right now.

- The reason we (or well, aliaspider) originally started this CatSFC core is because we wanted a SNES emulator with a bit more performance than SNES9x Next running on the PSP.  Right now it still doesn’t run at fullspeed on PSP, so we haven’t yet succeeded at this. However, Raspberry Pi users and other devices like that should already be reaping the fruits of the labor being done right now.

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about something else than cores that’s going to be new in v1.1

RetroArch on PowerPC Mac

Some generous gifter called nogagplz has been sending me some PowerPC Mac-based laptops over the past year and that stuff hasn’t been gathering dust to say the very least.

So RetroArch now runs on Mac OS X PowerPC. The cores that are known to be endian-safe (basically all the cores out now for the big-endian PowerPC based game consoles like the Wii, PlayStation3, etc) will be making an appearance on RetroArch PPC OSX.

Not sure how big the Mac PowerPC community still is but my main motivations for getting RetroArch out on this (by now obsolete) platform is that it is a lot easier to debug code on something resembling a PC than it is to be mucking about with gimped consoles that don’t even support gdb out of the box. So it makes PowerPC development a lot easier and what’s more, I personally want to see libretro (and by extension RetroArch) running on everything. So going even further back in time in the past and making sure RA runs on that is all part of the plan.

What’s been done?

- RetroArch OSX PPC runs on OSX starting from 10.5. It might be possible to lessen the requirements even more. Only time will tell.

What’s to be done in the future?

- Get better performance out of it (could be better at least on my iBook G4). The OpenGL renderpath must be suboptimal given how ancient and suboptimal GL implementations must have been back in those days. Hopefully there’s something lower-level to tap into.

OS9 port after v1.1??!

If I’m REALLY crazy (no promises) I might attempt a port of RetroArch on even OS9. The only main motivation for this would be that the guy who supplied me the Powerbook G3 stocked that HDD with a truckload of old classic games, some of which are quite some nice ports that are actually better than their PC equivalents (Wolfenstein 3D, Doom, Hexen, Quake II is a solid port, Killing Time, Carmageddon, etc, etc) so it’s quite a nice game box right now. Having RetroArch on here would sweeten the deal even more and it would add yet another platform to RetroArch’s belt.

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk some more about new cores

Dungeon Crawler Stone Soup

Meancoot made this libretro port a year ago or so but it was never really in a shippable state until now. I’ve rebased the port and I’ve made sure changes from upstream can be easily pulled in.

So what is it? It’s an old-school dungeon crawler in the vein of Rogue and Nethack. The game is meant to be played in single-player mode and is originally played with the keyboard (you can even use vim bindings). Quite popular, and the libretro port supports the tile-based graphics that make the game somewhat more graphically appealing.

What’s been done right now?

- Should work on iOS, Android (not tested yet) and PC.

- Has rudimentary RetroPad joypad controls (not recommended though), and working touch controls. Also has RetroKeyboard and RetroMouse support.

- Save states in the libretro sense are not ‘implemented’ but it supports the game’s basic ‘saving’ routines so it should work the same as the standalone version in that respect.

What’s to be done in the future?

- Meancoot originally added a Libretro GL-based render path which could result in some even better performance on platforms where GL is supported. Right now the current version is using software rendering which is still fast enough for our needs.

- Problem with the upstream Dungeon Crawler codebase is that they have been ‘upgrading’ to C++11 and as a result it will no longer compile on older compilers/systems where C++11 support can not be taken for granted. I’m undecided as to whether I should add hacks to the current shallow fork so that it can also compile as C++98 or whether I should just keep maintaining the year-old previous port by meancoot which should still be C++98-compliant. We will see. I’d definitely like to see this core running on older systems since it’s such a graphically low-key game anyway.

TGB Dual

This is a Game Boy/Game Boy Color emulator made by a Japanese developer. It dates back to 2001. It has been around as a libretro core for some time but only recently have some very important things been added to it.

For instance, it now has split-screen multiplayer support. This means that you can play GB Link games on the same screen with Player 1 and Player 2 controlling either of the two virtual Game Boys.

Some games that used GB Link support to good effect include but are not limited to : Tetris, Dr. Mario, Super Mario Bros. Deluxe and (of course) the Pokemon games. So for people that’d like to play two-player Game Boy games on the same device, this will be quite a nice addition.

What’s to be done in the future?

- Make it endian-safe so it can run on big-endian targets like game consoles (PlayStation3/Wii/etc) and PowerPC Macs.

– Download here! –

http://buildbot.libretro.com/stable/1.2/

First things first – we are back. It has taken us a very long time to make a new release of RetroArch due to numerous complications, so apologies for missing numerous release dates before (first Christmas, then somewhere in April, etc.). It tells something about the development hell we’ve been through that I’ve just skipped an entire version number (1.1) and gone straight to 1.2.

Let me first get some important stuff out of the way before we continue. For our iOS and Blackberry 10 users: we were not ready today (July 4) to launch on these platforms, you’ll unfortunately have to hold out for one more week before we have something for you. Rest assured that there will be plenty to enjoy a week from now.

With that out of the way…

What is RetroArch being released on today and tomorrow?

• Android (DONE) (Uploading to Play Store right now)
  
• Windows (DONE)
  
• Linux (DONE) (Repo packagers, go ahead and update the respective packages)
• Mac (Maybe July 5 2015)
• Consoles (Wii / PS3 / PSP ) (July 5 2015)
• Consoles (Xbox 1 OG)        (Maybe July 5 2015)
• iOS (Next week)
• Blackberry 10 (Next week)

Other platforms will have to wait, but rest assured the wait is not much longer.  *
I could write an entire book about all of the new features in RetroArch, but instead I’m just going to summarize it up in a few bullet points so that you can get the gist of it. In the upcoming weeks you will see plenty of more big announcements coming from us, and we will also provide you with much-needed user documentation on everything you can do with RetroArch now.

– Brand new eye candy menus to choose from! –

RetroArch now lets you select between three menu display modes: RGUI (a very classic, low-resolution menu), GLUI (a more advanced GL-based menu that lends itself well to touch-based devices), and XMB (a horizontal crossbar menu that is the most eyecandy-rich of all three right now).

Thanks to improved touch support, you should now be easily able to control RetroArch’s menu by dragging up or down and clicking on items. And thanks to built-in DPI awareness support, menu elements should now be scaled according to the DPI (Dots Per Inch) reported by your system.*

* NOTE: The XMB menu driver’s touch support right now is kinda iffy. We recommend that you use GLUI on touchscreen-based devices, like mobile (Android/iOS/etc).

– Scan files/directories and add them to game system collections! –

You can now scan files and/or directories, and RetroArch will look for a match inside its database. If it finds a match with a known game on a given system, it will then add this game to a collection based on the system of that game. This way, you can have ordered collections of games without having to browse your filesystem all the time looking for a ROM/game to play.

To use this feature, go to ‘Add Content’ and select either ‘Scan Directory’ or ‘Scan File’. *

* NOTE: Some programs right now might not yet have a database system in place to allow you to scan said content. Some of the current ones that still need to be addressed are MAME and CD-based systems such as the PlayStation. You will see this rectified in an upcoming RetroArch update.

– View database information about each game once added to a collection! –

Once you have a few collections, you will be able to view detailed information about the game, provided by RetroArch’s new database features. You will be able to view the developer of the game, the year it was released at, any kind of special hardware it used on the ROM cart package, the publisher that released the game, etc. *

* NOTE: The amount of information provided per game can vary and is dependent on the database’s completion. We encourage contributors to help us out building up these databases.

– Download programs (‘cores’) online –
RetroArch no longer comes with programs preinstalled, instead you download these now from our buildbot from within the program. Go to Online Updater -> Core Updater and select any of the cores you’d like to have installed. It will then download that core from our buildbot. This way, you are in control of exactly which programs you have installed and RetroArch does not take up any additional space for things you don’t need.*

We add new cores onto our buildbot routinely, so as soon as they will be uploaded you will be able to download them and use them with your current copy of RetroArch without even having to update the main program. Stay posted for more exciting new stuff coming up ahead.

* NOTE: We make no guarantees about server availability or uptime.

– Update everything! –

It isn’t just program cores that you can install this way from our buildbot. You can also update all of the asset files that RetroArch depends on. You will always be able to download the latest shaders, onscreen gamepad overlays, cheat files and whatnot directly from our servers from within the app.

All of this content is updated on a daily basis, so you can be sure there will be plenty of new things to check out on a weekly basis.

– Download Game & Watch games and play them with our exclusive Game & Watch emulator ! –

People in their early to mid-30s might have seen these things in the wild back n their day and will probably be familiar with these old standalone handheld games that predated the Game Boy, but don’t let their age fool you: these games still are very useful time killers and their age if anything gives them even more charm appeal.

Go to ‘Add Content -> Download Content’ to download any of these Game & Watch games. From there, you can play them with our Game & Watch emulator which has been built from scratch by a valued libretro contributor. Some of the standout features include faithful reproduction of the handheld’s screen layout, high-resolution bezels, nice simulation of the sound effects, etc. Give these a try.*

* NOTE: We owe a certain amount of thanks to Madrigal’s simulators for being able to offer these games to you.

– Built-in input mapping –
It is now possible to bind your gamepad from within the program without having to go through the chores of previous versions. Go to Settings -> Input Settings and select ‘Bind All’ to bind each and every button one at a time, or bind the actions individually. If you are using a gamepad which is supported by us, it will be autodetected and autoconfigured to align with our gamepad abstraction, the RetroPad.

– Ability to remap controls –
An often-heard complaint before was the inability to change the controls. We have made this possible now. Once a game is loaded, go to the ‘Quick Menu’ and select ‘Core Input Remapping Options’. From there you can change the controls per core, and you can also save these changes to a config file.

– Ability to enter and load cheats –
It is now possible to input cheats and apply them to the currently running game. This was also an often-heard complaint and omission pointed out by users, so we have provided this as well this time around. *

* NOTE: Some programs might not yet have cheat support integrated. As soon as we include cheat support for these cores, you will be able to download the updated core from within the app (see ‘Download program cores online’).

– Multi-language support! –

This release comes with (preliminary) multi-language support. Go to Settings -> User Settings and choose a language. Right now we provide translations for Dutch, German, Portuguese, and French.*

* NOTE: Some of the language translations might be more incomplete than others. Others (like Japanese/Chinese/Russian) are not available right now, and we seek translators for those as well.

– Over 80+ programs now and counting –
RetroArch and the libretro ecosystem has expanded in scope dramatically since the last release over a year ago. There are now over 80+ programs to choose from among its collection, and you can be sure that number is bound to increase from here on out. *

* NOTE: The amount of program cores available might vary based on the system you are using.

– Built-in image viewer (and media player) ! –

We have thrown in an image viewer inside RetroArch now. It is possible to display JPEG, PNG, TGA and BMP images.*

As if that is not enough, for the Windows release we now have an integrated media player. It is possible to play music and movie files now from within RetroArch. This might seem like an unorthodox way to use RetroArch, but it has certain tricks up its sleeve that other media players do not, such as frame interpolation and a wide array of shaders and audio filters to choose from. ** ***

* NOTE: Expect this feature to be improved in the coming weeks, there are still some power management issues to sort out with high-resolution images.

** NOTE: Expect this feature to be heavily improved later on. We will want to start supporting remote controls and also to provide a fancy overlay for video playback purposes. Also, expect a very nice audio visualizer soon for the playback of music files.

*** NOTE: The integrated media player support is available for any version of RetroArch that comes with built-in ffmpeg support. RetroArch is dependent on ffmpeg for making it possible to playback these files.

– Tons more besides to discover and enjoy –

This quick writeup does not even scratch the surface of everything that has been added to RetroArch over the span of a year. We worked hard on making this release happen and as such did not have the time to write about every single new feature in detail before dropping this release. Over the next few weeks we will have a more increased Youtube channel presence where we will drop videos which will show you all you can do with RetroArch right now. Please look forward to these videos.

Also, don’t hesitate to contact us with your ideas on what could make RetroArch better and how to improve it. We definitely want you to provide us with a lot of feedback on this release so that we can improve the next release in response to user feedback.

From now on, you can expect continuous updates. It took us a long time to set the entire infrastructure up to make all this possible and we also had to rewrite RetroArch entirely at least 5 to 6 times over the past year, but rest assured that this huge media dropout was a one-off event.

If things are not perfect today (and nothing will ever be perfect), be rest assured that from here on out, updates will be quick to arrive. We are not going to have a repeat of this endless delay schedule that has plagued us since last year, and above all we now want continuous user feedback so that we can improve things as we go along. Most importantly, me and others have practically worked themselves to death on this release for over a year and we really want to push this release out now so that people have something in their hands and we can go from there.

Oh yeah, there will be another big blog post after this that will detail some other new projects we’re working on shortly, but for now I have to focus on actually pushing this release out. So let’s see if we can get that done today and we’ll drop all the other major announcements shortly after.

Some other notes (Xbox 360 missing, etc)

* The only exception to this release promise is the Xbox 360 port. I have been routinely screwed and scammed by the ‘underground’ console hacking scene and right now I’m sitting on this paperweight RGH Xbox 360 that is useless for development, so that port is on indefinite hold until somebody can get me either the XDK back that I gave somebody in good confidence that it would go to Ced2901 (but it never did apparently), and I presume the guy I gave it to just hoarded it. or we can get a replacement for it. I won’t mention names but the guy who took my XDK and never gave it to the person he said he was going to give it to knows who he is. Anyway, if you guys still consider this Xbox 360 version important, let me know but I’m not going to go and take money out of my own coffers again to make that happen. I’m done with the console scene shenanigans.

Some other notes (3DS / PSP version)

We could maybe push out a PSP version of RetroArch 1.2 in the upcoming weeks. I’m hoping to get back with the main contributor (aliaspider) who worked on these ports so that we can be assured that we can at least push out the PSP version in a more or less stable and decent state.

Regarding RetroArch 3DS: it’s still very much a work-in-progress and I don’t think either me or aliaspider would feel comfortable to ship anything right now in terms of official release at this stage, and we need a lot of work done on the cores before we can render some of them playable on the slow 3DS (it’s even slower than the PSP it seems).

So, the latest release of RetroArch, version 1.2.1, has just been released. Allow me to fill you in on everything that has changed.

Download your respective version here!

Rushed 1.2 release

First of all, we admit that the 1.2 release was rushed and we regret that we were in such a rush to get something out there that we might have lost the forest for thre trees at some point. Bear with us here, it has been over a year since we had started a very big initiative to rewrite the entire codebase from scratch so that it could be future proof from now on, and there is only so much that can be tested in a controlled environment. Once it gets out in the wild, a lot more potential usecases can be tested and therefore, issues can pop to the surface that you didn’t anticipate before.

Now, not to make apologies for anything, we have been working our ass off this past week dealing with the feedback and improving things. So, let’s start with that.

Android

Usability improvements

The Android release has seen several great improvements (and do note – most upcoming mobile versions like iOS and Blackberry 10 will benefit from these improvements) –

Some of these big improvements are in the UI. First of all, the fonts were a bit low-resolution in the 1.2 version for Android because we defaulted to a bitmap font renderer there. Now we have upgraded that to a Truetype-based font renderer which uses the internal Android system Holo fonts. It should therefore look a lot more visually appealing now than before. (courtesy of heuripedes, one of our developers)

In other usability improvements, touch dragging has now been improved (by one of our developers, kivutar). When you drag in the menu by pressing and holding your finger on the screen and then making swipes, inertia now gets applied. So you can do a forceful swipe and the scrolling should be done much quicker. Previously there was no inertia at all so trying to scroll before could feel pretty iffy and not comfortable at all like what you’d expect from native UIs on mobile devices.

Some other usability improvements are less pronounced but still welcome. We noticed that the ‘ticker speed’ was very slow in the default Android menu (GLUI), so we made that a bit faster. We also took some time out to fix some graphics glitches that could happen from time to time.

Control improvements

There were a LOT of control issues in 1.2. Users found that they could no longer use the back button with certain pads to return to the menu, or they found their previous menu toggle key no longer working.

I believe we ironed out most of those issues now. What’s more, we’ve given you some tools to fall back on – there are several ways to trigger a menu toggle now. Let’s discuss some:

1 – By using a button combo -

There are two predefined button combos you can choose from – pressing ‘Down + L1 + R1 + Y’ or “L3 + R3″ will trigger a menu toggle so that you can go back to the menu and/or by pressing it a second time, return to the game. Go to Input Settings to select one of the two.

2 – Map Back Button As Menu Toggle -

In case a gamepad or some other device has not been autconfigured automatically, by enabling this option you can ensure that by pressing the back button, you can go back to the menu and/or resume the game.

Gamepad support control improvements

We really dropped the ball on this one for v1.2 on Android, let’s just get that out of the way. Now, it should be possible to completely manually bind a controller by hand in case there is no matching autoconfiguration file for the pad.

Also, to make this even more convenient, it is now possible to save your configured gamepad to a file by selecting ‘User # Save Autoconfig’.

Touch

So we were boasting about our new touch-friendly UI, right? Well, we didn’t really think through what kind of perception it would have on people if we would just drop them headfirst into this UI with an onscreen gamepad overlay, when most of these people would probably not think first to disable the overlay when not playing games. And obviously we can and should do better.
So for 1.2.1, we created some new options and enabled them by default which should enhance the user experience. How it works now on mobile devices is that when you enter the default menu (GLUI), you use touch controls. However, when the game actually starts up, the gamepad overlay will appear onscreen. When you go back to the menu, this gamepad overlay will disappear again until you go back to the game again.

If you dislike this behavior there’s always the possibility to turn these settings on/off in Input Overlay Settings. But I’m guessing you will pretty much like the new defaults.

Default paths

There were a LOT of problems with the new default paths in this new RetroArch version. For 1.2.1, radius has been doing the thankless task of really going to town with improving this situation.

For instance, on Android, whenever you download content now (from – say – Add Content -> Download Core Content), it will download this stuff now to your Android device’s default Downloads directory. Similarly, every picture you take from RetroArch with ‘Take Screenshot’, gets saved now to Android’s default Pictures directory. So it is possible for you as a user to more easily have access to these files.

It should also now be possible again to use the directory of the game you’re running for savestates/saveram.

Dead Android UI

Consider this us not properly arranging a burial for the dead in time for v1.2. From now on, everything is controllable in an easy way from RetroArch’s built-in menu. We have removed all of the outdated upper-layer Android UI menu options and we hope this will provide for a consistent, seamless, one way to control RetroArch from every platform now. I think the menu system has been improved enough by now that it’s no longer necessary to rely on an upper-layer UI. We want RetroArch to be a consistent C-oriented codebase where any other upper-layer UI can instead be catered to through a companion UI – more on that later in the future. But we are no longer going to have duplicate settings inside one external Android UI and then a bunch of settings in the built-in RetroArch menu, no.

Game & Watch core troubles

We fixed numerous crashes with Game & Watch games by simply recompiling RetroArch with Google’s latest NDK toolchain. We’ll leave it up to voodoo I guess since none of these bugs make much sense anymore, the only thing I can surmise is that Google must have a habit of randomly breaking stuff inbetween toolchain revisions.

So now, with all of that out of the way, I’m sure you can agree that we really went to town trying to improve the Android user experience immeasurably. Let’s now move onto Gamecube/Wii…

Wii

Long time since the last release dropped. But we do have something to show for it, and no doubt we will have plenty of more to show for it in the upcoming weeks and months too.

It is now possible to connect a Sony DualShock 3 gamepad to your Wii through USB and use it for playing games with! This is made possible through the libsicksaxis API that was made by xerpi, and netux79 gave us some code that made this finally work with RetroArch.

I’ve tested it and while it can still be improved, it already plays great. I haven’t tested wireless operation though so you’re on your own still with that.

Also note: this will probably be improved upon a lot in the future. I’ve already asked ToadKing whether he would be interested in coming up with some USB HID driver for the Wii which, when finally implemented, would probably replace libsicksaxis entirely. With this, it will be possible to not only use DualShock 3 pads, but also DualShock 4 pads, maybe even more in the future. This USB HID driver already exists on certain RetroArch versions like the Linux and Mac versions, where it is possible to use a DualShock 3, Dual Shock 4 and/or a Wiimote Classic without the host OS even needing to supply any HID drivers for these pads to make it possible.

Anyway, stay tuned for more exciting news to follow us here. In future versions I’d also like to flesh out the WIi version’s netcode out some more so that we can actually provide the downloader feature options that are now available on Anroid and Windows.

So what’s not done yet? What’s still coming up?

All these platforms are obviously still waiting for a new RetroArch release:

• PlayStation3
• Mac OS X
• Blackberry 10
• iOS
• Xbox 1 (OG )

Bear with us here. I’m working round the clock to make sure we finally have the latest version of RetroArch on all platforms again. This past year has been a truckload of work and I will be pleased to see this chapter finally end so that I can move on to the next phase of development. Rest assured that the PlayStation3 version will have some awesome features and that the iOS and BB10 versions will not disappoint.

And after I have these platforms out of the way, I can finally start looking again at the Windows Phone/WinRT port in general…

Thanks for reading this post and stay tuned for more big news this coming month. Things will be moving fast from now on, with plenty of results.

Time for another update. Let’s get right to it.

Download it here!

OSX version

NOTE: If the OSX version doesn’t work for you, you might have to install the Cg framework first. To do that, download this and install it:

http://developer.download.nvidia.com/cg/Cg_3.1/Cg-3.1_April2012.dmg

The OSX version is back! We have two versions because we care about backwards compatibility, one for 32-bit Intel Macs (OSX 10.6 Snow Leopard and up), and one for 64-bit Intel Macs (OSX 10.7 and up). Later on we’ll go even an extra mile beyond this by releasing the PowerPC version too, which should be compatible from OSX 10.5 and up. It would be nice to push the OSX requirements down even further in time.

Some caveats right now: the guy who did our buildbot releases (IKarith – TJCarter) – I don’t know what fate befell him and whether or not he is still doing fine (I hope he is), but these builds seem to be no longer being pushed out to our buildbot, the last update was somewhere around the end of June. So we will have to be looking fast for a solution for this on our buildbot so that we can have 0-day updated cores again for iOS and OSX (the iOS version is not yet released but will be coming up next hopefully).

PSP version

The PSP version has been usable for a long time but I think we should finally just release it as part of the new stable releases. Of course things are not going to be perfect but I hope just us going the extra mile and releasing this for a pretty much dead platform will mean something in and of itself to the people who use this platform.

PSP is a pretty performance-hamstrung system so it requires plenty of edits and novel workarounds to make cores work fast enough on it. Right now we have cores like Gambatte working fullspeed and the PC Engine port also should be pretty impressive considering this is based on Mednafen PC Engine Fast, which should be far more compatible and accurate than something like Hugo.

A sincere call to arms here for more PSP developers who want to be part of the effort: we have every intention of making as many ports run well on the PSP but the crucial thing here is that all of this costs work. If you are a capable PSP dev and you’d like to help out please let us know.

Wii version

There were some problems with the last release. FBA CPS1 was missing and FBA CPS2 was not working. Both are rectified now and included again.

Android version

A major issue that popped up in version 1.2.1 should now be fixed. The new font renderer we introduced back in version 1.2.1 was causing some problems on phones / phablets / tablets with very high DPI (i.e. above 480dpi). This should now be fixed. So apologies if you saw indecipherable glyphs in the previous version, that should hopefully be a thing of the past by now.

Other changes

Here is a summary of most of the major things changed in this release:

– OSX version released!
– PSP version released!
– (OSX 10.6 32-bit version) All cores that the 32bit version supports are currently included into the ZIP itself because our buildbot does not yet serve up 32bit cores for OSX yet. Apologies for this, we’re trying to come up with a solution.
– (OSX/iOS in general) The guy who did our buildbot nightlies for OSX/iOS is currently MIA. We will have to come up with a new solution fast for this. Due to this you might experience some outdated cores right now for these platforms.
– (Android) Fixed XX/XXXHDPI font issues with GLUI (was leading to corrupted fonts)
– Initial Spanish translation.
– Add advanced help system.
– (Android) Add Nvidia Shield Portable hack – back button should bring up menu properly now.
– Fixed some issues with hotkeys.
– When ‘Hide In Menu’ is enabled, overlays should reappear now when we select ‘Resume Content’, ‘Load State’, or ‘Save State’
– (Wii) Fix FBA CPS1/CPS2 cores.
– (GLUI) Better ticker speed.
– (GLUI) Labels should use more screen estate when available.

So what’s next?

The next version after this will be RetroArch v1.2.3. We still have PlayStation3 to go now, iOS, Blackberry 10, and OG Xbox 1 (2001). Let’s see how fast we can get all this stuff out of the way. In the meantime, have fun with v1.2.2 on the platforms that have all been covered up to this point.

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.

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

The Android builds are signed with the same key as the nightlies so updating from those should be seamless.
Alternatively you may scan these to get the URL:

Have fun!

Note: We know it’s not working on iOS9