Update on the Retro Freak situation

After getting into contact with Cyber Gadget and explaining to them the situation pertaining to the illegal usage of non-commercially licensed open source emulators, we are pleased to report the following –

“Dear Mr. Matteis,

Our sales of the Retro Freak are being suspended at the moment to
investigate the legitimacy of the open source software we use.
Our company has been trying to comply with any kind of law, however
our developer claims that the use of the software is not illegal, so, we are requesting them to prove and provide us the evidence.
If your claim is proven to be correct, we would be willing to take necessary

We now know of the contractor that was responsible for this and had been selling this software to companies like Cyber Gadget ( basically sublicensing code out to other companies to which he holds zero rights, operating from Hong Kong), and we will be sure to contact the other companies as well that he had been sublicensing this to.

All we want is for open source creators to be safe in the knowledge their rights are being respected and that they are not being taken advantage of. The venerable Snes9x emulator has since its very inception been licensed as non-commercial (see the copyright header at the top of each file – https://github.com/snes9xgit/snes9x/blob/master/snes9x.cpp). It cannot be sold, period. There are multiple copyright holders (including myself, Daniel De Matteis) and it will be impossible to obtain the consent and approval of all copyright holders. Speaking strictly for myself, I will never give them permission on my behalf merely on principle, and the software in question that had been sold to the likes of Cyber Gadget and Hyperkin was using our libretro forked repo, Snes9x 2010 (https://github.com/libretro/snes9x2010) as per the contractor’s admittance. By contractors like this exploiting open source projects like this against their will and against their licenses, they cause massive damages to the continued goodwill of volunteers who band together to make awesome projects like this.

To learn more about this story, check our previous articles here –

Appeal to game journalists – about Retro-Bit and about the new ‘retro emulation industry’ in general

CyberGadget’s RetroFreak proven to use Snes9x Next/2010 code, non-commercial code being sold

Daniel De Matteis

ChaiLove – Another Take on 2D Game Development

Whale from the Love2D logoWhen it comes to 2D game development frameworks, there are many options out there for indie game developers. Every framework has its own pros and cons, and its own use cases. Today, let’s talk about LÖVE, baby.

LÖVE is an awesome framework to make 2D games in Lua. With some modification, these games can be brought to libretro though Lutro. With the advent of C++14, are there tools and features we can bring in to improve the scripting experience behind developing 2D games?

Love2D ChaiScript ChaiLove

Meet ChaiLove, an experiment in porting LÖVE to ChaiScript. Some of the goals behind this endevour include:

  • ChaiScript: The Lua scripting language is amazing, and is widely adopted. Having ChaiScript natively implemented directly in C++ means it’s easily embeddable, and has out-of-the-box support for many of the standard libraries already available.
  • Cross-Platform: Currently available on Windows, Mac OS X, Linux, and ARM. More platforms to come.
  • Proudly Found Elsewhere: Adopt third-party libraries whenever possible to reduce development times and improve maintainability
  • LÖVE API-inspired framework: Much of what you already know from LÖVE will look familiar in the ChaiLove API.


It’s pretty easy to get started with ChaiLove, just check out these code snippets.

Drawing text

def draw() {
    love.graphics.print("Hello World!", 400, 300)

Drawing an image

global whale

def love.load() {
    whale = love.graphics.newImage("whale.png")

def draw() {
    love.graphics.draw(whale, 300, 200)

Playing a sound

global music

def load() {
    music = love.audio.newSource("music.wav")

For more information on ChaiScript, see the ChaiScript language reference.

Case Study: Floppy Bird

Floppy Bird ScreenshotFloppy Bird is an example of what a ChaiLove game could look like. The game is a re-imagining of Flappy Bird using ChaiLove. It features rotating sprite graphics, music, sounds, a high score, save state support, and more. It’s available to download from the project releases, or directly through RetroArch:

  1. Online Updater → Core Updater → ChaiLove
  2. Online Updater → Content Downloader → ChaiLove → Floppy Bird.chailove
  3. Load Content → Downloads → Floppy Bird.chailove

The following video shows not only how to download the ChaiLove core and Floppy Bird, but also some gameplay:

What’s Next?

ChaiLoveChaiLove has a few places where it could grow, and we’ll need your help for it to get there. Some ideas include:

  • Additional platform support. Since ChaiLove targets the libretro API, we could port it to platforms such as Android, iOS, Playstation 3, Wii, and more.
  • Examples Browser to have a large library of running examples of ChaiLove code.
  • Update to SDL2 through @r-type‘s work on sdl2-libretro
  • Improve the audio system. Adding OGG and FLAC would be great to have for music files.
  • Lua support. Just because it targets ChaiScript, doesn’t mean we can’t have Lua in there too. Having Lua support would allow running Love2D games in ChaiLove.
  • More games! Port and develop more games with ChaiLove as great examples of its use.


RetroArch 1.7.0 -Released!

RetroArch 1.7.0 has just been released! Grab it here.

This latest version has also been uploaded to the Google Play Store.

We here at RetroArch/Libretro wish you a Merry Christmas and a Happy New Year!

If you’d like to show your support, consider donating to us. Check here in order to learn more.

General changelog

– CHEEVOS: Add badges for achievements, shows thumbnail images of achievements.
– CHEEVOS: Leaderboard support.
– CHEEVOS: Only disable savestates on hardcore mode if achievements are not available.
– COMMANDLINE: Fix fullscreen toggle switch.
– COMMON: Add ‘Automatically Load Content To Playlist’ feature, enabled by default.
– COMMON: Fix slowmotion ratio always being reset back to 1.
– COMMON: Optimized NBIO implementations now for Apple, Windows, and Linux. Uses mmap for Linux/Windows/BSD if/when available. File I/O should now be much faster for loading images inside the menu.
– COMMON: Native Blissbox support now for latest firmware as of writing (2.0). Implementation through libusb and/or native Windows HID.
– COMMON: New lightgun API.
– COMMON: New VFS (Virtual File System) API.
– COMMON: Fixed some playlist bugs.
– COMMON: New snow shader.
– COMMON: Fix Quick Menu title, no longer shows ‘Select File’.
– COMMON: Fix loading cores that require no content one after another.
– COMMON: Map Delete key to Y button for non-unified menu keyboard controls.
– COMMON: Fix for relative paths being normalised and generating a duplicate history entry.
– EMSCRIPTEN: Fix references to browserfs.
– FREEBSD: Support libusb HID input driver.
– HAIKU: Buildfix.
– INPUT: Map clear button to DEL key.
– LINUX/X11: Add RetroArch logo to window title bar.
– LINUX/X11: Input driver now supports new lightgun code.
– LINUX/X11: Support window transparency (requires a compositing window manager).
– LOBBIES: Fix for crash on join netplay rooms via touch / glui.
– LOCALIZATION: Update Italian translation.
– LOCALIZATION: Update Japanese translation.
– LOCALIZATION: Update Portuguese-Brazilian translation.
– LOCALIZATION: Update Polish translation.
– LOCALIZATION: Update Russian translation.
– MENU: Snowflake menu shader effect.
– OSX/PPC: Fix the GL2 renderchain, had to use EXT versions of framebuffer/renderbuffer functions.
– PS3: HTTP requests / downloads should now work.
– PS3: Core Updater now works.
– PS3: Improved font rendering, enable STB Unicode font renderer.
– PSP: Make it work with Vita’s Adrenaline.
– PSP: Fix audio sync.
– PSP: Fix content loading, port should be functional again.
– PSP: Use 64MB when available.
– SCANNER: Fix crash from Windows-incompatible format string.
– VITA: Improve packaging, installation times.
– WIIU: Disabled the controller patcher for now since it was the source of many stability issues.
– VULKAN: Various stability fixes for WSI.
– WINDOWS: Add MSVC 2017 solution.
– WINDOWS: Get rid of the empty console window in MSVC 2010 builds.
– WINDOWS: Raw input driver now supports new lightgun code.
– WINDOWS: Use configured OSD/text message color on GDI driver.
– WINDOWS/XINPUT: Populate XInput VID/PID from DInput so autoconfig doesn’t rely solely on joypad names
– WINDOWS/XINPUT: Fix crash that occurs in some situations with Steam running and a Steam Controller plugged in.
– WINDOWS: Improve version reporting under System Information.
– WINDOWS: Support window transparency.
– WINDOWS: Correct usage of GetWindowPlacement per MS docs, fixes game window position on Win95/98.
– WINDOWS: Added Visual Studio 2017 support.


Integrated Bliss-box support

Grab the newest firmware for this device and you can enjoy out-of-the-box Blissbox support with RetroArch on the following platforms:

  • Linux
  • Windows

For more information, read this separate article here.

This is a legit game changer. This peripheral will allow you to use real physical gamepads from all sorts of different game consoles through one interface.

Right now, only one of these devices is supported.

Badges for achievements

Improved lightgun support

Lightgun and mouse support has been added to both Beetle PSX and Beetle/Mednafen Saturn.

In other input-related news, mouse support has also been added to Beetle/Mednafen PCFX.

Windows 95/Windows 98 (non-SE) support

In a time and era where big companies get lazy and just throw away 32bit support for anything from drivers to operating systems, we have gone to the complete opposite side of the spectrum and started adding even more ancient/obsolete systems instead.

We already had a Windows 98 Second Edition/Millennium Edition/Windows 2000 version of RetroArch. But now, we go back even further in time! The MSVC 2003 version is a version of RetroArch that works on Windows 95 and Windows 98 (the First Version, before Second Edition).

Some things you should know about this version:

  • Rough around the edges, has been mainly tested so far on VMs (Virtual Machines) instead of real hardware.
  • Uses GDI as the default video driver. Our Direct3D driver so far requires DirectX 9 and Cg. It will take some work to make it backwards compatible with DirectX8.
  • We omitted the Windows NT 3.51/4 versions for now. The main issue with these versions is that they do not support DirectInput, so we have no real input drivers available for them.

Right out of the gate, there are 21 cores available for the Windows 95/98 version. Not too shabby, eh?

For more information, read this separate article here.

Improved PlayStation3 port

So many important improvements that have been made to the PlayStation3 port as a result of our newfound friendly collaboration with an RPCS3 dev:

  • Downloads now work
  • Netplay now works. You can netplay between two PS3s, or with another system that is also of the big-endian architecture. For instance – netplay between RetroArch PS3 and RetroArch Wii U works. NOTE: There might still be some endian-specific code in certain cores that can cause bugs.
  • Content Downloader works. You can download many demos and freeware homebrew games from this.
  • Thumbnail Downloader works. You can download boxarts and titles/snaps for your games from here.
  • Core Updater works. Now you can directly download freshly updated cores directly through the built-in Core Updater. New cores will be added over time, and best of all, you don’t need to install a new RetroArch version in order to obtain these new cores either.
  • Improved font rendering inside the menu. Non-Western languages are now also supported by this improved font rendering, including Japanese, Korean, Chinese, Russian, etc.
  • New menu shader effects

    PSP port works again

    Wii U port works again

    Wii U port should work fine again after some issues in previous versions.

    Automatic scanning of content

    This new option, when enabled, will add any new content you load from the file browser (Load Content) to your playlists. If a playlist does not already exist for the specific core and/or game, one will be created on-the-fly. This option is disabled by default, so watch the video if you’d like to learn how to enable it.

    There’s more

    There’s a ton more that we have properly not covered in this blog article, but we leave it up to the user to discover that for themselves.

    What’s coming next for RetroArch

    We will have a separate blog post on this soon, as well as more separate blog articles detailing some of the other progress that has been made on the cores front.

Appeal to game journalists – about Retro-Bit and about the new ‘retro emulation industry’ in general

Dear game journalists and other members of the press,

We are beyond the point of desperation at this point, and we ask you dearly for your help in this ongoing problem. Independent entrepreneurs are playing loose and fast with the laws and licenses surrounding open source code, and we have found ourselves the victim of multiple copyright and license violations ever since Hyperkin started selling its Retron5 product back in 2014.

Since then, there has been an explosion of these products all opting for the same approach – take from opensource code, bundle it up in numerous incompatibly licensed ways, then to add insult to injury, strike up licensing deals with established players in the games industry and make it appear as if your product is ‘legitimate’.

Read up on our previous articles here for more information –

CyberGadget’s RetroFreak proven to use Snes9x Next/2010 code, non-commercial code being sold

RetroArch, Libretro core license violations by Hyperkin’s Retron5

To recap and to also add to it a new recent example of this (as in the case of Retro-Bit) –

2014 – Hyperkin Retron 5

Uses Snes9x (non-commercial emulator) and Genesis Plus GX (non-commercial emulator) together with various GPL-licensed emulators. The individual source code was a direct copy of our libretro repos. This is not the issue however – the issue is quite clearly that they are selling non commercially licensed emulators which obviously, as the license entails, cannot be sold.

Did they ever do anything about this, though? Nope. It is still being sold. They recently striked up a license with byuu to use his product Higan in the future, but this does not pertain to the Retron 5 as the hardware it is based on is obviously incapable of running Higan at fullspeed. That the same product is still being sold to this day is a clear-as-day license violation of Snes9x and multiple other parties involved. I hold copyright over portions of Snes9x these days too, and the forked emulator sourcecode that the ‘contractor’ has admitted to using (and which can be seen in the sourcecode archive they published, Snes9x 2010/Next) was all written by me. They have never bothered to rectify these issues.

2015 – Cybergadget Retro Freak

Cybergadget Retro Freak – uses an identical copy of Retron5’s sources. Cyber Gadget has admitted to us in e-mails that they did not write the software themselves but got it from a ‘contractor company’ (probably the same company that did the software for Hyperkin Retron5. As far as I am informed, this comes from a Hong Kong company whose identity is still unknown). So, the same problems apply here – uses Snes9x (non-commercial emulator) and Genesis Plus GX (non-commercial emulator) together with various GPL-licensed emulators.

After waiting for over two weeks on a reply back from them, I got an e-mail back (December 18, 2017) where their anonymous developer (not them) had this to say about our grievances

“We used two versions of Snes emulator. One was Snes9x 2010, which was in turn taken from Snes9x, which had some speed increases added. The second was Verbatim snes9x. From both of these we only use the emulators and not their core code. As far as the file msvc_compat.h Mr Matteis himself says that he took this file and pasted it into many other projects. No doubt this is how this file containing RetroArchtext appeared in the archive on Cyber’s web site. As Mr. Matteis’s name does not exist anywhere in this source code we assume Mr. Mattheis is inferring that because we have this one file containing the word RetroArch posted on the web site then we must have used other files which are authored by Mr. Matteius’s. This is not true. We do not in fact use any core files merely use the emulator code as a library.”

Therefore, we believe we are not infringing on your copyright.

Also, these software are “GPL”, and we believe there is no problem for us.

This reply is obviously nonsensical, and betrays a complete lack of understanding of Snes9x’s licensing terms.

Snes9x is not licensed as GPL. It is licensed under a non-commercial, proprietary license. The entire emulator is licensed as non-commercial. Whether you use ‘core files’ or whether you use the emulator code as a library has no bearing on it. You cannot use this in a commercial product. Their product is illegal right now as it is currently being sold, and they’d have to do a complete recall and remove the infringing SNES emulator parts in order for it to become legal.

I have given them a reasonable amount of time to rectify their obvious mistakes and missteps. Will they choose to do the right thing though? Probably not. bearoso from snes9x meanwhile has taken it upon himself to try to get the product removed from Amazon, however, Amazon has been pushing back –


2016 – NostalGames RetroPac (defunct)

Here we had two college students who took it upon themselves to set up a crowdfunding campaign with Kissbank in France to try to setup a business around their ‘Retropac’ product. This product turned out to be just a derivative of Lakka, our turnkey RetroArch based solution.

The problem with this was that Lakka is non-commercial and comes bundled with various non-commercially licensed emulators, hence it cannot be sold. They did not care about this, and decided to carry on anyway.

We managed to successfully shut down their crowdfunding campaign, and that appeared to have been the end of this venture.

Unfortunately, we did not dedicate an article to this, so you will have to make do with our Twitter posts instead –




2017 – TekSyndicate Notice Me Sen-Pi

A popular Youtuber who goes by the name of TekSyndicate wanted to start selling a product based on Lakka. He was quite audacious about this and made a blog post about it full of hubris as to why he should be able to do this.

You can read our statement on this here –



We contacted Amazon and we were able to get this product taken down. Tek Syndicate has agreed to no longer bundle Lakka with his hardware device, and now resorts to a Do It Yourself video which explains to people how to install it on the hardware.

2017 – Retro-Bit Super Retro Cade

The latest situation.

Just recently, we have been contacted by Retro-Bit. To be more precise, one of our team members Andres Suarez was contacted in the past.

This is the latest e-mail we have received back from Retro-Bit – just mere weeks before they started selling their latest product Super Retrocade

I hope all is well. A quick E-Introduction, I am the marketing manager for Innex and our house brand Retro-Bit. In the past you were in contact with Andres Quiros regarding the possibly usage of Retroarch for our plug and play consoles with the caveat that when using “open source” software we would need to give credit then share any updates done to t he original code back to the community in the event they want to build upon it.

Since then, Andres had left the company and we recently released the Super Retro-Cade which I believe operates off Retroarch. We would like to provide the rightful credit to Retroarch and disclose the emulator and request the source code. They can retrieve it through a customer service page on Retro-bit with proof of purchase and waiver of liability forms.

As I mentioned in my previous email, our former Product Development Manager (Andres Q.) left the company in the middle of development, leaving Ron (copied) and myself to finish the product with a very aggressive timeline to launch. We were not aware of this situation, but want to work with you to find a successful solution.

We are a small company that competes directly with Hyperkin and like you, we want to expand the retro gaming to its fullest potential and support the community.

So, all we know in this instance is that they are using RetroArch. As long as sourcecode is being provided and as long as the license is being followed (GPLv3, that means no TIVOization), that would be no issue. HOWEVER, and here is where it gets troubling – they do not know themselves what emulators it uses. So, again, which contractor company was responsible for this cobbled together software again? Why does this keep happening? How come none of the licensees (Capcom/Data East/etc) were aware of this?

Here is where this gets troubling – it is yet again a cheap ARM SoC (System on a Chip). They admit to us over e-mail it is using RetroArch. But they cannot tell us which cores are being used because they “do not know”. ALL of the emulator cores available through RetroArch which provide SNES, arcade and Genesis emulation and which could conceivably run on this hardware, are all distinctly non-commercial. We are talking about Snes9x here for SNES emulation, Final Burn Alpha or older versions of MAME (MAME 2000/2003/etc) for arcade, and Genesis Plus GX for Genesis. They cannot be sold, period. So, again, we have the very same issue here as we have had with Hyperkin and Cybergadget. But instead of waiting until they have determined with us that this is not an issue, they start selling it anyway.

We are beyond demoralized and pissed off at this point. Ever since the NES/SNES Mini, this kind of activity has been going on and has been accelerating. Entrepreneurs and certain publishers are having dollar signs in their eyes. Games are being played with us and other members of the emulation scene by various parties (in this blog post I have probably left out a fair few other companies as well), and we are simply getting sick and tired of this abuse. This is hugely demoralizing and demotivating and makes us almost unwilling anymore to continue with it.

Stuff like this is hugely damaging to the goodwill of the open source community. If open source authors continue to find their licenses and rights trampled upon by a couple of entrepreneurs with the sole intent just to make money and these same entrepreneurs and their business partners don’t care about doing due diligence and making sure they are in the clear, developers are going to stop contributing to open source projects altogether. The knowledge economy dies in doing so, leaving us all with yet more products cobbled together from various disparate sources with no greater aspirations beyond just making a buck.

External examples

Let us cite some other examples how open source emulator authors have been taken advantage of in recent months. I refer you to byuu’s tweets on the subject –

This same one-man game publisher tried buttering us up to do business with him too over e-mail, until we informed him that we did not like how byuu had been mistreated in the past previously. In response, he launched into an angry tirade against byuu. We also learned our e-mails were being forwarded to byuu without getting any disclosure of this prior. A few hours later, byuu sends me an e-mail message imploring me not to involve or associate myself with Piko Interactive in any shape or way.

To which the founder of Piko Interactive responded to byuu in this way –


Dude Nobody asked you to drain your 401k and max out credit card to spend on super famicom stuff or projects. Thats you own decision. If you are looking for sympathy and/or praise you are not going to get them from me. You did it for the love of the console? Then great, don’t complain. Im pretty sure you are old enough to make your own financial decisions.

As I told Daniel, why would I pay you for something that you offer no support and it is hard for a regular programmer to compile? The whole 6 months (which I think it was far less) shiru spent all his time and effort trying to understand the spagetti code that higan was. He just couldn’t get it to work the way you provide it, sorry, Im not going to pay for something I cannot use. That is like me going to buy a car for my communte but the salesman is giving me all the engine in parts that I have to assemble; I can look into assembling the engine, but if doesn’t work out, Im not going to buy it, And I am expecting the salesman to undersatnd that I am not going to buy something I cannot use.

If you are too concern about making money off your emulator (which is a good product) why do it GPL? Why not just sell a license and not offer it for free? Like flying tigers, digital eclipse, nintendo, and others?

We posted instructions online on how to get the source code, which was by request. I could even made it difficult and do it by mail only and charge a mailing fee and would be still ok. Also, Im pretty sure that there is credit to mednafen there somewhere on the steam page, at least on the listings we control. Bubsy I dont control, and we gave instructions on what to write in regards the mednafen licensing and instructions to post on how to get the source code. If Tommo didn’t posted them, that is not my problem.

Also, why would I give credit to byuu if we are using mednafen? If someone is curious what emulator is using, then they go to the page where it gives that information, and then they read up on mednafen, and see it uses bsnes core.

Call me what you want, (worst than hyperkin, yada yada) at least I don’t talk behind people’s back, specially the ones that make me money ;).

Take a couple of business classes, may come in handy. Or may I suggest to partner up with someone that understand basics in business.

Is this the way we as developers should be treated? As less than human? Byuu personally drained his 401K out of a passion to preserve the Super Nintendo forever. Everybody, including Nintendo themselves, is forever indebted to him for taking the time to document the Super Nintendo where nobody else cared, including its entire software library, to the point where people can now use this documentation to their own advantage even to make themselves some money with re-releases of new classic consoles. And what does he get back in return? Openly spit in his face like this? Needless to say, we refuse to associate with Piko Interactive after having read these very disrespectful comments.

Basically, we find it to be a grave injustice how all of us as a scene and as individual independent authors are being treated and manhandled by industry forces that only care about respecting licenses and copyrights when it suits their products, but don’t care a whit when it involves the little guy, the guys who can’t hire an army of lawyers to combat misuse of their software. This is a disgrace and we find it similarly interesting how this same games industry continues to keep up this pretense that emulators are this ‘grey area/non-legit’ subsector of videogames and how no attention should be paid to it, yet they have no problem doing these kind of licensing deals with companies that just crib from those same emulators and even disrespecting their licenses at the same time.

We are being treated abysmally, by people whom feel themselves to be in positions of power so that they are able to do this and get away with it.

We are also completely bogged down by this mess. Each and every month a new contender comes along, doing the very same thing, that we then need to either respond to or deal with. This is hugely demoralizing and demotivating to my team members, and there is not a surplus of developers around to keep working on these projects to begin with. There becomes a point when honestly the undying passion we have for our project to keep going is being outdrowned out by these cynical and deplorable attempts to make a quick buck off our hard work at our expense and violating the licenses in question. We don’t know where to go from here quite frankly, we just felt it was worth a final last-ditch attempt to bring this to your attention. Where we go from here, is not decided yet. We never even intended RetroArch or Libretro to be a purely emulator-focused experience, we intended it to be a great ecosystem where software could be made modular and run in various frontends. That it instead has amounted to a nostalgia cash grab by various companies who are at great pains to delegitimize our efforts yet have no qualms with doing business deals with companies whom don’t hold any of the rights for the software they are exploiting – for its various disparate emulator cores to be manhandled and abused and misappropriated like this, pains us greatly to see happening. This is end-stage capitalism, pure and simple, and we are the unwitting victims of it.

Bliss-Box 4-Play integration for RetroArch will soon be here!

RetroArch now has native support for the Bliss-Box 4-Play – a universal game pad adapter – in the latest nightly builds. This support will be included in the upcoming stable release (1.7.0). The new support includes a dependency on libusb, so anyone running the nightly builds should be sure to download an updated redist package to get the new lib.

(Editor’s note – RetroArch version 1.7.0 will be released later this week)


RetroArch has support for many adapters and the ability to add countless more, however, it does so by mapping per adapter. Similarly, the 4-Play also supports a large number of controllers but outputs them as one device.  Previously, RetroArch could not map each game pad because of this. Fortunately, the 4-Play was designed with this in mind and has a built in API any project could take advantage of without the need of drivers. In this update of RetroArch each pad seen by the 4-Play is read in to RetroArch appending the pad type to the cfg file found during controller detection.This is just the beginning and there is a road leading to amazing potential with the 4-Play adapter. Using the same API mechanism, we could expect to see but not limited to: native game pad communication with Gamecube and Dreamcast, direct memory card support and LCD screen writing, support for all 12 Playstation 2 pressure buttons, and more. The latest version of the 4-play firmware is required and you must configure your 4-play with the API tool available on the Bliss-Box page for download.

In addition the new firmware from Bliss-Box gives each player a unique USB ID. This allows players to be specific to the physical ports. Each USB name has a number indicating the player order.

You can read more about the Bliss-Box 4-Play here or follow the project on the FaceBook page.

Bounty updates

The following bounties have had their pledges raised –

RetroArch – [Direct3D] Create a Direct3D 11/12 backend for the D3D driver ($160)

This bounty has been increased from $125 to $160!

Description (by Twinaphex):

Right now, our current Direct3D driver has a couple of limitations:

1 – It is Direct3D 9 only, and requires the Cg toolkit in order to work.
2 – It only works with the RGUI menu driver. There does exist a menu_display_driver_d3d file, but it’s unfinished, and right now it only renders text in XMB.

For the purposes of this bounty, we are looking for somebody who can achieve the following:

1 – Write a Direct3D 11/12 driver. The exact implementation we leave up to you, but it would be best if there is still the possibility to use the old Direct3D 9 codepath for systems that don’t support Direct3D11.
2 – Finish up the Direct3D menu display driver so that it can properly render a menu driver like XMB and MaterialUI.


RetroArch – Add frontend to host VFS layer ($140)

This bounty has been increased from $70 to $140!

Description (by webgeek1234):

This is a feature request to add a virtual file system layer between Retroarch and the host. This would allow remote files systems such as WebDAV, sshfs, cifs, and NFS to be mounted and ROMs, saves, bios, and and thumbnails to be accessed through them.


Smartphone gamepad app for Remote RetroPad ($25)

This bounty has been increased from $10 to $25!

Description (by duduke):

I’m creating this Issue to serve as a bounty for someone to create an Android and iOS app that will use Remote RetroPad to enable using your smartphone as a remote gamepad for RetroArch.

This is especially useful for a mobile LAKKA install where you do not need to carry and gamepad with you.


RetroArch – Graceful switching between video drivers ($165)

This bounty has been increased from $115 to $165!

Description (by hizzlekizzle):

RetroArch currently behaves unpredictably and unstably when switching to cores that want a context other than what is currently active. This can happen because of video_driver settings being different in a core config override or because a core’s core options are telling it to use a different renderer than is active (e.g., GL vs Vulkan)


RetroArch – Vulkan video driver in fullscreen on GeForce Driver 387.92 causing black screen ($50)

Description (by WhiteZeroX) –

With the new nVidia GeForce 387.92 video driver, the RetroArch Vulkan video driver only displays a black screen when starting any emulator. This only occurs in fullscreen mode. If you run in Windowed mode or alt-tab out of RetroArch and back in, then you’ll get an image again (unless you change a resolution setting in the emulator causing the video driver to initialize).


RetroArch Roadmap for v1.7.0 and beyond

We don’t usually talk about all the behind the scenes development stuff that we do. We usually prefer to let the work speak for itself. Nevertheless, we feel compelled to share with you from now on a brief roadmap status update that basically shows what we are currently working on codebase-wise, where RA will go next, etc. We also hope this will be of use to existing upstream contributors.

Compatibility with OpenGL 1.x

From its inception, RetroArch’s OpenGL driver has targeted OpenGL 2.0 and/or later. There are a lot of people on ageing computers that don’t have a GL 2.x compliant driver. We have been putting a lot of work into modularizing the renderchain code, splitting it up from the main GL driver into their own files. This will pave the road towards a basic OpenGL 1.x renderchain which should at least work with OpenGL 1.3 and up. We might be able to target even lower versions later on, but time will tell.

Certain features this GL 1.x renderchain will not have:
* FBO support. FBOs wasn’t a thing with OpenGL until at least version 2.0 (not counting extensions). This also means no libretro GL support, so don’t expect hardware rendered cores with OpenGL 1.x.
* Shaders. Again, this is tied back to a couple of factors, one of them being the lack of FBO support which makes multi-pass shaders impossible to implement. But also, shaders are impossible in general for this 1.x mode. GL 1.x did not yet have shader support. Shaders didn’t become a thing until GL 2.x. GLSL/Cg/HLSL did not exist yet at this time and the entire rendering pipeline was fixed-function.
* There will be no fast framebuffer readback paths (in so far as that stuff is actually ‘fast’ with GL to begin with). No PBO support, which wasn’t a thing back in GL 1.x days. So expect slow screenshot taking and/or recording.
* VAOs (Vertex Array Object) and VBOs (Vertex Buffer Object) weren’t yet a thing until GL 3.x and GL 2.x respectively.

We have no idea yet when this will start working. The main issue is testing it on ancient GPUs that only have GL 1.x drivers.

Xbox OG/Xbox 360

For a long time, the Xbox OG and 360 versions of RetroArch and cores have been de-listed. This had several technical reasons, one of which being that it was a big maintenance burden and struggle to keep having to update all the separate Visual Studio solution files for these platforms. For all other platforms, we build cores using a universal Makefile, which typically contains one file (called Makefile.common) which conditionally defines which files are to be compiled in. By having to maintain some separate solution file, we need to update two files instead of one, and worse, having to start IDEs in order to edit them (or even worse), having to manually edit them with a text editor, which can tend to be error prone on top.

In order to do away with these issues, we have now reverse-engineered how we can still have a Makefile target for MSVC that uses MS’ compilers/linkers/assemblers from within the confines of a Makefile-based solution. Note that this solution does not depend on Microsoft’s nmake and uses plain make.

Now that we have accomplished being able to compile and link cores with MSVC without any MSVC solution file, we now feel the time is right to start reintroducing the Xbox OG and 360 ports.

The Xbox port work also feeds into several other things we have been working on concurrently, such as :

  • Better Direct3D support. Xbox OG will need Direct3D 8, whereas Xbox 360 needs Direct3D 9 + HLSL.
  • The latest compiler that can be used for Xbox OG is Visual Studio 2003, whereas for Xbox 360 this is Visual Studio 2010 (right now). To this end, we have updated a lot of core Makefiles to include targets for these platforms, and not just for the Xbox platforms, but PC as well.

Direct3D work – supporting more versions, etc.

In the past, we have had two separate Direct3D drivers – one for XDK (shorthand for Xbox platforms), and one for PC (Direct3D9-based). Because we intend on supporting the Xbox platforms again, we no longer want the maintenance burden of having two video drivers that essentially are similar in lots of ways. To this end, we have started modularizing the Direct3D driver so that multiple backends are possible to be implemented.

Not only is it possible to have a Direct 3D 8 / 9 codepath, but it is also possible to have separate renderchains. For instance, the Xbox 360 will be able to use the HLSL renderchain, whereas on PC the user has the option to choose between Cg (which would use the Cg renderchain), and/or HLSL (which would use the HLSL renderchain).

We also intend for there to be a fallback path to Direct 3D 8 in case your GPU and its drivers do not support Direct 3D 9 for whatever reason. Backwards compatibility is very important to us and it’s increasingly getting harder to keep supporting all of these various versions in one single codebase. These are unique challenges to which there is often not a clear-cut solution, so we have to improvise a little on the fly and do unconventional things in order to make this happen.

Windows 95

Brad Parker likes extending backwards compatibility of RetroArch to older versions of Windows, and this in turn makes our codebase more flexible so that we can keep the Xbox OG and 360 ports alive.

People might mistake this for taking up resources and time that could be better spent elsewhere, but the opposite is true – by setting up the foundation in our codebase just once, it will be automated and take care of itself from that point on. Also, there is lots of overlap between platforms. For instance,
the latest compiler that can still churn out binaries for Windows 95 is Visual Studio 2003. This incidentally happens to be the last compiler that can create binaries for Xbox OG. So already here we have overlap whenever we need to make a core compatible with MSVC 2003 and we have to create the necessary Makefile targets for it.

For Windows 95, we are thinking of defaulting to the GDI video driver instead of Direct3D since we assume that the kind of machines running Windows 95 typically would not have either a video driver with Direct 3D 9 support or a GPU that supports it to begin with. Windows 95 still supported DirectX so we should be able to default to ‘DirectInput’ as the input driver. Windows NT 3.5 will pose more of a problem here though – back then, NT did not have any DirectX support at all, so a DirectInput driver is not possible and we lack any other input driver that we could use. Windows Raw Input driver cannot work on this ancient NT version. We are not sure yet what approach we will take there.

Nevertheless, Windows 95 will be first out of the starting gates.

New hardware platforms we intend to support

We have obtained some new hardware over the past few months:

  1. NES/SNES Classic
  2. GCW Zero
  3. SteamLink

It is our intention to have this be part of our main release schedule in future releases. We understand that for a system like SNES Classic, a different approach will be required vs. just the usual ‘full fat’ version of RetroArch that people have grown accustomed to, and we will certainly be taking a long hard look at RetroArch Clover for inspiration on what we will do. Our first approach is likely going to be something similar to RetroArch Clover that ultimately piggybacks off Hakchi and which complements the main UI of the platform rather than trying to replace it.

RetroArch 1.6.9 -Released!

RetroArch 1.6.9 has just been released! Grab it here.

This latest version has also been uploaded to the Google Play Store.

General changelog

– Audio: Fix the Audio DSP picker
– CHEEVOS: Add support for Atari Lynx cheevos.
– CHEEVOS: Add support for RetroAchievements Leaderboards.
– GUI: (MaterialUI) Fix crash that happened on context reset with Vulkan.
– GUI: (MaterialUI) Skip querying and drawing items that are not visible; Cache content height and bbox calculation.
– GUI: (MaterialUI) Fix entry box highlight calculation.
– GUI: (XMB) Skip drawing the fading list when it is already transparent. Optimization.
– GUI: (XMB) Comment out visible item calculation in xmb_draw_items().
– GUI: (RGUI) Prevent crashes when using a non-English language reliant on UTF8.
– GUI: Add menu option for OSD background color.
– GUI: Add menu option for OSD text color.
– GUI: Add menu option to remove frame count from OSD.
– GUI: Allow wraparound of int/float settings when pressing the left key
– INPUT/LIBRETRO: Add support for more mouse buttons (buttons 4/5)
– INPUT/LIBRETRO: Add support for analog buttons
– INPUT: Always show the controls menu even if descriptors are not set
– INPUT: Fix input descriptors not being set on cores that don’t implement the controllers interface
– INPUT: Apply descriptors only for the amount of cores the core supports
– INPUT: Implement keyboard to gamepad input remapping (limited to one gamepad device for now)
– INPUT: Fix absolute mouse move handling on the winraw driver
– INPUT: Ignore keyboard input if window is not active on udev driver
– INPUT: Sanitize the filenames of autoconfig profiles before saving
– LOBBIES: Fix crash on navigating left / right from the lobby menu
– LOCALIZATION: Update Dutch translation
– LOCALIZATION: Update Italian translation.
– LOCALIZATION: Update Japanese translation.
– LOCALIZATION: Update Portuguese-Brazilian translation.
– LOCALIZATION: Update Russian translation.
– LINUX/ARMHF: Set buildbot updater URL to armhf location instead of blank string
– LINUX/PI: Broadcom VC4: Add Videocore config option
– LINUX/UDEV: Fix – RetroArch reads keyboard input when not focused with the udev input driver.
– NETPLAY: Fix disconnection not fully deinitializing Netplay.
– NETPLAY: Fix lan rooms when there is more than one room
– NETPLAY: Fix lan rooms on systems where all addresses are treated as IPv6
– COMMON: Fix clear/free loop conditionals in playlists.
– WINDOWS/GDI: Fix flickering of text.
– WINDOWS/GDI: Fix graphics corruption on Windows 98
– WINDOWS/GDI: Allow compiling without DirectInput8 for NT support
– WINDOWS/WGL: Try to use wglSwapLayerBuffers instead of SwapBuffers if possible (for more optimal performance).
– WINDOWS: Fix menubar text corruption on Japanese locale systems
– WINDOWS: Support Unicode file I/O (can now display CJK characters in file browser for example).
– WINDOWS: Support Windows 95, NT3.51, NT4
– WINDOWS: add Makefile.griffin targets for msvc6,2003,2005,2010,2012,2013
– WII: Use custom, embedded libogc SDK.
– WIIU: Initial touchscreen support for WiiU gamepad.
– WIIU: Add Cheevos support.
– SCANNER: Fix archive scanning.
– SCANNER: Support CHD files.
– SCANNER: Support Gamecube ISO scanning.
– SCANNER: Use primary data track of disc images for CRC lookups rather than cue files. This is slower but finds matches more reliably, and is necessary for CHD files to work at all. Update your databases!
– SCANNER: Fall back on looking inside archives when matching MAME/FBA content (most recent cores only). If you had difficulty with content being detected before, you may have better luck now. Update your databases and core info!


Scanner system supports more formats

CHD and Gamecube ISO files can now be scanned. A lot of libretro cores have gained the ability to use CHD image files, some of them being all the Mednafen-derived cores (also known as Beetle cores). There is also a new fallback used for scanning MAME/FBA content which looks inside an archive for matching files. If you had trouble having the scanner detect your content before, you might be more usccessful now.

Retro Achievements – Leaderboard support

Unicode support for Windows users

Unicode is now supported for file I/O (Input/Output). What this means, is that game content that uses CJK characters and/or other non-ASCII characters can now be read by RetroArch. These files will also show up from within the filebrowser. Useful for our Japanese users.

NOTE: MaterialUI (the default UI on Android) might still exhibit issues displaying Japanese on Android. This is due to a font renderer that will need to be improved in a future version in order to display these extra characters properly.

Kiosk Mode and more

You can now tailor RetroArch’s UI even more to your own personal preferences. You can choose which submenus to hide, and which to show.

There’s also a special mode called ‘Kiosk Mode’. When enabled, you won’t be able to access any settings, and/or install/upgrade any cores. The guy who implemented this feature likely intended it as a parental control feature to make sure that kids don’t get to mess with any of the internal settings by accident that could end up breaking something. There’s also a password lock you can enable so that any access to settings can still be curtailed.

See the PDF article here for a more detailed breakdown of Kiosk Mode –


Input enhancements

The libretro API has been enhanced by David Walters in the following ways:

  • Button input was previously all-digital, now button input can be analog as well. As a proof of concept, this has already been implemented for the Beetle Saturn core. Analog triggers now work as expected. This feature will be necessary for future systems like PlayStation2, where each face button on the gamepad was an analogue button.
  • Mouse buttons 4 and 5 were added. A proof of concept has already been implemented for Beetle Saturn. The mouse on the Sega Saturn had at least 5 buttons instead of the PlayStation mouse’s 2.

Mouse support and lightgun support has also been added to Beetle PSX, a much-requested feature. There are also some proposals on how to improve lightgun support in libretro so that it is more conducive to non-mouse based lightgun solutions. As ever, additions to the libretro API have to be backwards compatible and they should not break ABI, so that existing frontends will not be adversely affected but at the same time new frontends can reap the benefits of these new features all the same.

What’s coming next for RetroArch

We will have a separate blog post on this soon.

In the meantime, check out the addendum to this post –


This details all of the changes to the cores that have happened since the last release.

Core Updates Since Last Release (v1.6.7)

In anticipation of RetroArch 1.6.8, let’s detail all the work that has been performed on the libretro cores since the last frontend release (1.6.7).


Themaister came out of retirement to collaborate with byuu on an upstream-friendly libretro-ization of higan. Currently, only the SNES emulator is available, but we hope to extend this to include all of his suite of emulators. Only the mainline ‘accuracy’ profile is available from the Online Updater currently, but we hope to add hex_usr’s ‘balanced’ profile soon. In the meantime, you can get it pre-compiled for Windows from his nSide github repo.
Notably, the higan core includes Super Game Boy support, including all special features, such as borders and music. Instructions for setting it up are here.


raelgc has backported many commits from upstream, including a ton of accuracy and performance improvements.


j-selby has been keeping the libretro core up-to-date with upstream’s amazing progress. The version available in the online updater is lagging behind these updates a bit, since the buildbot is having trouble building it lately, but we hope to have this resolved soon. We also hope to get the recently announced network support hooked up to the libretro core, but no promises there.


notaz provided a massive update to bring the libretro core up to date with upstream. This update included many accuracy improvements, along with some nice features like 68k overclocking.


sergiobenrocha2 did the legwork to merge/update mgba-libretro to match the upstream 0.6.1 release, including a big pile of accuracy fixes from endrift.


hunterk backported qwertymodo’s MSU1 fixes, which should alleviate the crackling that some users reported, especially on Android devices, and he also added RTC support for the recently completed Tengai Makyo Zero (Far East of Eden: Zero) translation.

In addition to this, a hack got backported from Snes9x2010 which should prevent an annoying resolution flicker which occurs when switching from field mode to battle mode in the game Chrono Trigger.


Upstream Snes9x dev OV2 provided a patch to check for invalid VRAM access, which makes Hook work without massive artifacting.


Massive amount of work from mudlord, AIO, bparker and Twinaphex to get the threaded angrylion RDP integrated. It started as a port of the angrylion-plus-rdp plugin, but the libretro version is now quite different, including being a true software renderer (that is, compatible with all video driver backends, including d3d). This plugin is very fast in Windows, reaching full speed on relatively modest CPUs, while Linux is only slightly faster than non-threaded angrylion. We hope to identify what’s holding back performance on non-MSVC compilers in the near future.


hiddenasbestos brought the libretro port up to parity with upstream v0.9.47 v0.9.48, which gives a few ton of nice accuracy improvements and the much-awaited savestate support (savestates made with the v0.9.47 version are not compatible with the v0.9.48 update, so beware if you made a bunch of states in the short time between updates). Tatsuya79 and retro-wertz provided a number of improvements to the overscan and cropping behavior.


bkoropoff and simias did a lot of work on the CD reading code, including reduced stuttering during reading and a core option for increased CD loading speed. This *greatly* reduces the loading times on games, from the standard 15-30 seconds down to as low as 2-3 seconds. Do note that this is very much an experimental feature though, and it won’t work correctly for all games. r5 also added the ability to use unsupported BIOS files, which should make the core a little less picky about BIOSes. simias also backported new and improved triangle code from upstream, which unfortunately causes some issues with the PGXP features in some games. Zapeth also added support for CHD files.


retro-wertz aded support for cheevos/RetroAchievements.


r-type continued his fantastic stewardship of the up-to-date MAME core, keeping it in lockstep with upstream releases.


Oggom backported support for the awesome sidescrolling Cave shmup Akai Katana, support for which was just added to upstream mainline MAME.


gamez-fan has been backporting dozens of patches and drivers from later versions of MAME to make more games work (or work better) with this core. markwkidd also fixed up a lot of the core’s reporting to correctly distinguish between working and nonworking games.


gamez-fan added in some speedhacks and fixed Rampage World Tour for this low-power spinoff of mame2003.

Final Burn Alpha

barbudreadmon continued his stewardship of Final Burn Alpha, bringing in many fixes from upstream and fine-tuning controls for specific problematic games.


sergiobenrocha2 backported many fixes from the mainline FBA core for this low-power spinoff.


tschak909 added support for loading VIC-20 games. r-type improved screen resizing and handling for PAL/NTSC regions.


frranck greatly improved the AI in MrBoom, making it possibly the most advanced Bomberman AI in existence.


meepingsnesroms added disk swapping and, along with Tatsuya79, provided some nice quality of life improvements for this core, including machine auto-selection.


AZO234 added a number of improvements to this core, including support for more disk formats (floppy and SCSI HDD), sound fixes and new soundcards and better savestate support.

Genesis Plus GX

nukeykt added a fantastic, cycle-accurate sound core. The older, MAME-derived core is still available for low-power devices. bkoropoff also added support for overclocking and the ability to remove per-line sprite limits (i.e., the cause of sprite-flickering).


leiradel fixed some issues with high scores not updating properly and controller popups appearing behind game sprites.


retro-wertz continued his work on this core, providing many fixes and updates for the mapper code, as well as greatly improving the Zapper functionality.


radius worked with LIJI32 to get the libretro-ization upstreamed in this extremely accurate Game Boy emulator. radius also hooked up savestates and SRAM/in-game saves, along with a variety of options that weren’t previously exposed to the libretro port, such as audio and video tweaks and rumble, while leiradel added cheevos/RetroAchievements support.


radius worked to keep this core in lockstep with upstream. hunterk fixed an issue that was causing the red and blue color channels to be swapped and also closed a significant memory leak.


moose65468 fixed loading Dragon Quest 5.


meepingsnesroms added support for 2x overclocking, while rdanbrook added preliminary Famicom Mic support (get ready to yell at those Pols Voices) and Tatsuya79 provided some edge-case fixes for Zapper functionality.


nanoant fixed building on Android and made the core look for BIOS ROMs in the libretro ‘system’ directory, which puts this core more in-line with good libretro behavior. Meanwhile, r-type added support for more keys.


Twinaphex collaborated with hrydgard to get an updated PPSSPP core ported over and to upstream a few things that should make it easier for the libretro port to stay up-to-date.


meepingsnesroms fixed some polygon issues and radius fixed building this core for Windows. However, it’s still not something people should use on non-ARM hardware for general purposes.


Tatsuya79 fixed an annoying key-repeat bug.

Across many cores, bparker added support for Travis continuous integration, so we can better determine whether commits will break building on the many platforms we support, yoshisuga added support for arm64 builds on iOS targets and radius added support for mapping cores’ keyboard keys to the retropad, which is very useful for classic computing cores. Also, retro-wertz fixed a bug that prevented the beetle-* cores from cleaning up after themselves when loading zipped ROMs.

Parallel N64 Multithreaded Angrylion update

Here is a quick update on some new patches we have pushed to the Parallel N64 core –

1 – You can now get anywhere from a 6fps (conservative) to a 10fps or more performance boost with multithreaded Angrylion core by enabling a new option called ‘Send Audio Lists To RSP HLE’. Instead of sending audio lists to the low-level RSP plugin (cxd4), it will instead send these to the HLE (High-Level Emulated) RSP plugin instead. Note: If a game does not use the RSP for audio processing, you will not notice a speedup by enabling this. Nevertheless – many games benefit from this already.

NOTE: Indiana Jones and the Infernal Machine might have bad audio with this option enabled, my guess is that the MusyX HLE audio code is still not perfect or we need to have something backported still to make it so. Will look into that tomorrow.

2 – We followed the advice of ata8 (the original Angrylion RDP Plus plugin) and refactored some of the RDRAM code. As a result we are getting a very minor performance boost now on Linux. It’s still not anywhere near it should be compared to the Windows version but it is an improvement nonetheless –

Mario 64 – VI overlay on – 77fps (after) instead of 72fps (before)
Mario 64 – VI overlay off – 87fps (after) instead of 84fps (before)

Hope you enjoy these low-hanging fruit performance gains. Back to getting RetroArch 1.6.8 ready!