RetroArch 1.6.4 – Released!

RetroArch 1.6.4 has just been released! Grab it here.

This latest version has also been uploaded to the Google Play Store. You might see it appear on the Amazon App Store soon too!

General changelog

ANDROID: Fire Stick & Fire TV remote overrides gamepad port 0 on button press and viceversa like SHIELD devices
ANDROID: Provide default save / system / state / screenshot locations
AUDIO: Audio mixer supports MOD/S3M/XM file types now!
INPUT: input swap override flag (for remotes) is cleared correctly
INPUT: allow specifying libretro device in remap files
INPUT: allow specifying analog dpad mode in remap files
INPUT: allow saving libretro device to remap files
INPUT: allow saving analog dpad mode to remap files
INPUT: allow removing core and game remap files from the menu
COMMON: Cores can now request to set a ‘shared context’. You no longer need to explicitly enable ‘Shared Hardware Context’ for Citra/OpenLara/Dolphin.
COMMON: Add ‘Delete Core’ option to Core Information menu.
COMMON: Allow Max Timing Skew to be set to 0.
COMMON: Change the “content dir” behavior so it works on either a flag or an empty directory setting, now platform drivers can provide defaults for save / system / state / screenshot dirs and still allow the content dir functionality, these settings are under settings / saving and flagged as advanced
GUI: You can turn on/off ‘Horizontal Animation’ now for the XMB menu. Turning animations off can result in a performance boost.
GUI: Fix sublabel word-wrapping in XMB where multi-byte languages were cut off too soon
LOCALIZATION: Update Dutch translation
LOCALIZATION: Update Traditional Chinese translation
LOCALIZATION: Update Italian translation
LOCALIZATION: Update Russian translation
WINDOWS: Provide default save / system / state / screenshot locations
LOBBIES: Show what country the host is in
MENU: Enable OSD text rendering for gdi and libcaca drivers
WINDOWS 98/ME/2K: Set default directory for MSVC 2005 RetroArch version.
WII: Better V-Sync handling, backported from SuperrSonic.
WIIU: Exception handler rewritten.

Bounty system gathering steam!

Several bounties have either been completed over the past few days or are nearing completion. Let’s cover a few of them.

In case you’re interested, here is a list of bounties we are currently funding which still have yet to be completed and where you could come in. Check out this list here.

Play MOD / S3M / XM files music files now in-game!

Remember that audio mixer we added a few releases back? This allows you to have external music files playing while any core/game is running. So far, you could only play Wave (WAV) and Ogg Vorbis files with this feature, but now you can playback Mod files too!

Developer Romain Tisserand did the leg work on this bounty, and the nice thing about it being added to libretro-common is that the improvements and additions made to the audio mixer can be used now by either the libretro cores and/or the frontend, RetroArch in this case!

How to use this feature – simply go to ‘Load Content’, and select any MOD/S3M/XM/WAV/OGG file on your file system. Select ‘Add To Audio Mixer’. If you are using the XMB menu driver, it will now be added to the horizontal menu’s ‘Music’ tab.

Start up any core/game now. At any point in time while playing, go back to the music, go to the main menu, go to the Music tab, select any of the music files and choose ‘Add to audio mixer’. Toggle the menu again to go back to the game and you can hear the music being mixed in with the game’s sound.

TIP: You can mix several music files at the same time! You can run up to 8 music files together at the same time. As ever, RetroArch allows you power features beyond what is commonly offered.

MAME CHD support for Beetle Saturn / PC Engine Fast!

This bounty came about when several users saw the value in more emulators being able to read MAME CHD images and chipped in the funds for a bounty.

Developers Romain Tisserand and inolen (Redream) have written a new C-based library called libchdr. This should interface with CHD images. After the library was written, Romain decided to put the work in to backport CHD support to the Mednafen-based cores, Beetle Saturn and PC Engine Fast.

This means that both the Mednafen Saturn and PC Engine Fast cores can now read MAME CHD images! MAME CHD is a compressed image file which can save a ton of storage for disc/CD-ROM based images. The implementation also supports FLAC support for redbook audio.

New bounties have been created for more cores to have this compatibility, such as Genesis Plus GX (and Eke seems interested in having this in his upstream repository as well). This is just one of the ways in which we think bounties can trickle down beneficially to downstream projects as well.

The upshot in all this is that pretty soon it could be possible to use the same MAME CHD image sets for both MAME and these various cores. More interoperability between cores is definitely a good thing to see.

MAME 2003 – DCS sound issues fixed! Proper sound now in Mortal Kombat/NBA Jam/WWF Wrestlemania!

For a long time, the MAME 2003 core has suffered from an issue where the sound could deteroriate after a couple of minutes for about 30 seconds before restoring itself. This would happen in Midway DCS-based games such as Mortal Kombat 1/2/3/Ultimate, NBA Jam, etc.

A bounty had been submitted by dankcushions some time ago and finally this bounty is on the verge of being completed! It should finally be possible to play these games at fullspeed on something as low-fi as a Raspberry Pi without being put out of the game by sound bugs and being reminded you are running an inaccurate emulated version of the game.

New big bounty for Beetle PSX upcoming in next few days – dynarec!

For quite some months now, a bounty has existed for Beetle PSX which has steadily increased in value. Up to $250 now, the pledgers are asking a developer to create a dynamic recompiler for the Wii U system in hopes of being able to run PlayStation games at fullspeed.

Unfortunately, we think that in order for this bounty to first get traction, some groundwork needs to be laid out first. Right now, Beetle PSX has no dynarec system in place at all, only a CPU interpreter. Therefore, it would be very hard for a developer to start right out of the gates with a PowerPC-based dynarec since no framework is in place yet that would allow him/her to slot in a dynarec backend like this.

So, what we are going to do is we want to sweeten the pot a bit and create a new bounty dedicated solely to building a dynarec. We believe that once the groundwork is laid out, this WiiU dynarec bounty has more chance of being successfully completed.

The conditions will be:
* A dynarec system for Beetle PSX, preferably written in C or else C++98.
* A working backend for x86 32bit and x64 (64-bit).
* Should be engineered in such a way that new backend implementations for other architectures (like ARM and PowerPC) can be easily implemented.
* Should be signifcantly faster than the interpreter CPU core, and should lower Mednafen/Beetle PSX’s CPU system requirements considerably.

We will start out this new bounty at $100. Other users can feel free to chip in on this endeavor. You will see this bounty being announced over the next few days.

Release highlights

Windows 98 SE/2000/Millennium Edition version – now with 29 cores!

So we announced a Visual Studio 2005 version of RetroArch this past week which runs on Windows 98 SE / Millennium / 2000. Upon release however, there were no cores.

We now have 29 cores available on our buildbot! You can get them by starting your copy of RetroArch 1.6.4 and going to Online Updater -> Update Cores. Note that because it’s Visual Studio 2005/MSVC2005 we are relying on as our compiler, certain cores might never become available for this. For instance, cores that rely on C11 (like SameBoy) or C++11/C++14 (like Dinothawr/Dolphin/Citra) will not make the cut. Fortunately, most of our cores can happily compile as either C89 and/or C++98, so backporting is not as big an issue for it as it would be for other projects which are not as careful when it comes to code maintenance.

Here are some general hints and advice in case you want to run RetroArch on your retro battle station:
* Keep in mind that Windows 98 SE GPU drivers in most cases won’t support OpenGL 2.0. There is one exception apparently, which is the nVidia Geforce 6 series. This GPU series should support OpenGL 2.0 and there should still be drivers somewhere available for Windows 98. In case you have such a GPU, you could opt to use the OpenGL driver which should be more full-featured than our GDI and/or Direct3D9 drivers.
* In most cases, your GPU driver will probably support Direct3D 9. If you want to use Direct 3D 9, you should only use the menu driver RGUI with it. Neither MaterialUI and/or XMB will render properly as of yet with Direct3D.
* For lower-end GPU hardware where neither Direct3D 9 or OpenGL is desirable or possible (because you don’t have hardware accelerated 3D video drivers), a GDI video driver is also available. For this release, we added OSD font rendering to it. There are still issues remaining with this GDI driver though on certain OS configurations. Bparker might be able to use some help with getting some of those niggles sorted out. Reminder that if you want to use a menu driver with GDI, it’s best to use the RGUI menu driver.

RetroArch PlayStation3 version is getting nightlies!

Long overdue, but we are finally getting ready to start providing nightly support for RetroArch on PS3. This way, PS3 users can download the latest nightly version at all times and enjoy the latest improvements! This is not yet ready since we are going through some last-minute buildbot issues, but we expect this to be sorted out within the next few days.

Beetle Neo Geo Pocket Color (if the big endian patches are any indication) should have its controls fixed now!

We are also going to provide CEX/DEX builds from this point on instead of just the usual DEX builds like before.

Citra/OpenLara/Dolphin cores can now be easily used!

You no longer need to enable ‘Shared Hardware Context’ anymore in order to use these cores. RetroArch’s underlying API, the libretro API, has gained a new environment callback. The Citra/OpenLara/Dolphin cores make use of this to signify to the frontend that they need a shared hardware context.

A frontend can feel free to implement this or not, however, it goes without saying that cores which make use of this feature might simply not work correctly if left unimplemented.

Deleting cores

Installed a core, but you feel like you no longer need it? It’s now possible to delete it from within RetroArch.

How to do this –
1. Load the core.
2. Go to the main menu, and go to Information.
3. Select ‘Core Information’.
4. Select ‘Delete Core’ at the bottom of the list.

Configuration changes

Saving Stuff on Content Dir

The new behavior is to always provide a sane default directory for Saves, Savestates, System Files, and Screenshots. Windows and Android have been historically problematic in this regard since the content directory may not be writable at all times.
The old behavior relied on the setting strings being empty, now we provide a default value for these dirs on both Android and Windows which means the string will never be empty. Other platforms should follow this convention shortly.

So if you want to use content dir after 1.6.3 do the following:

  1. Navigate to Settings / User Interface
  2. Enable Show Advanced Settings
  3. Navigate to Settings / Saving
  4. Enabled the respective settings among the last four settings for the stuff you want to reside with your content

We apologize for any inconvenience this may cause to existing users but we need to make some changes to make progress.

Core Input Remapping Improvements

You can now delete core and game remaps from the Quick Menu.

Core Input Remapping has also been improved. The following will now be saved:
* The libretro device
* Analog Dpad mode

You can also save these in overrides but remaps is a far more convenient place for these.

Updates on cores

Read here what updates have been pushed to the cores since the last release –

As always, you can always install the latest version of every core from RetroArch’s builtin ‘Core Updater’ (accessible from the menu by going to ‘Online Updater’ -> ‘Update Cores’.

Retroarch on Amazon App Store coming soon!

We have often been begged by Amazon for years now to please publish RetroArch on the App Store. So far, we always felt the time was not right.

With this release, though, we have finally fixed a fundamental issue where using the Remote would make it no longer possible to use a gamepad as Player 1. This has now been rectified.

We will inform you when the Amazon App Store build has been published. For now, users can sideload it by just downloading the APK from our website.

What’s up next?

Priority number one absolutely right now is PPPSSPP and Supermodel. We are going to get that into your hands ASAP as promised.

After that,

* An AppImage version of RetroArch for Linux will be available soon.
* Lots of core work like we always do each week.
* More yet unannounced stuff? Stay tuned!

View this page if you’d like to explore donating to us. By popular demand, there is now the ability to send one-off donations through Bitcoin, and we have put up links so that you can directly send funds to the Bountysource bucket. You can also pledge to our Patreon.

NOTE: the OSX PowerPC version will be uploaded tomorrow. Thanks for your patience.

RetroArch for Windows 98 SE/ME/2000 pre-release!

RetroArch for Windows 98 SE / Windows ME / Windows 2000 has just been released! Note that this will require cores specially made for it, and as of now there are none, so just consider this a pre-release for now!

Get it here!

Users should note: this is taking no time or resources away from the other stuff we are doing. Supermodel and PPSSPP cores are still being worked on, all our other work is still ongoing, so to repeat – this is not coming at the cost of other development!

Note that for these old operating systems, you might want to consider using the GDI video driver for optimal performance instead. Menu support is still premature though; XMB renders but with no textures and with dithered graphics, so for all practical purposes, the Direct3D driver is still the way to go here (with RGUI).

RetroArch 1.6.3 – Released!

RetroArch 1.6.3 has just been released! Grab it here.

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

General changelog

IOS: Fix GL regression – 32bit color format cores were no longer rendering
CHEEVOS: Add support for N64 cheevos and other small fixes.
CHEEVOS: Add ‘Achievements -> Achievements Verbose Mode’. Ability to display cheevos related messages in OSD, useful for RetroAchievements users.
AUDIO: Audio mixer’s volume can now be independently increased/decreased, and muted.
AUDIO: Mute now no longer disables/enables audio but instead properly mutes the audio volume. Mute is also independent from the audio mixer volume.
INPUT: Add mouse index selection; ability now to select between different mice
INPUT: Fix ‘All Users Control Menu’ setting
LINUX: Add a tinyalsa audio driver. Doesn’t require asoundlib, should be self-contained and lower-level.
LOBBIES: Announce the RetroArch version too
LOCALIZATION: Add Traditional Chinese translation
LOCALIZATION: Update French translation
LOCALIZATION: Update Italian translation
LOCALIZATION: Update Japanese translation
LOCALIZATION: Update Russian translation
MENU: Add ‘User Interface -> Views’. Ability to display/hide online updater and core updater options.
NETPLAY: Disconnecting one client shouldn’t cause everyone to disconnect anymore
NETWORK: SSL/TLS support, disabled by default
SCANNER: Fix PS1 game scanning
SCANNER: Move content list builder into scanner task with progress, fixes menu freeze with large playlists
SDL2: Fix ‘SDL2 driver does not see the hat on wired Xbox 360 controller”
SETTINGS: Fix regression ‘Custom Viewport is no longer overridable per-core or per-game’
VITA: Add cheevos support
VITA: Add support for external USB if mounted
WAYLAND: Fix menu mouse input
WII: Add support for single-port ‘PS1/PS2 to USB controller adapter’

Platform highlights


There are now installers available for the Windows version! We offer installers for both the Windows Vista and up version, and the Windows XP version.

RetroArch will be installed by default to your user roaming profile, however, you can change this to any particular directory you’d prefer instead. The reason why we do not try to install to “Program Files” by default is because RetroArch needs read/write permissions in order to write downloaded core files directly to its folders.

Our installer installs RetroArch in ‘portable’ fashion. What this means is that you can take the directory that RetroArch was installed in, deploy it to another drive, and it will still run, and the default paths will automatically change their paths.

Windows XP

So MinGW has broken backwards compatibility with Windows XP sometime ago. This was a problem for us, since Libretro/RetroArch treats backwards compatibility very seriously.

So, what we have done is make a separate version of RetroArch for Windows primarily targeted at people running Windows XP. Instead of MinGW, we are using Microsoft Visual Studio 2010 / MSVC 2010 as the compiler for this. We have also already ported at least 30+ cores over to MSVC 2010 so that they will run on this new Windows XP version.

We will not simply just stop at a Windows XP version – sometime later on next week, a Visual Studio 2005 version of RetroArch will be launched which will run on Windows 98 / ME / 2000! Where other projects are dropping older OSes and even entire architectures in order to cut down on maintenance and development time, we instead are adding even more platforms, and primarily because we both care about this and see the value in a platform/program that truly extends everywhere, and also because our infrastructure is set up in such a way that we can easily deal with any ‘maintenance’ burden this would otherwise entail for other projects.

Linux – Flatpak

RetroArch/Libretro has from Day One always treated Linux not only as a first-class citizen, but also pretty much as a reference platform. Unlike so many other projects that treat Linux simply as a quick and dirty port where they choose the path of least resistance and just use some middleware like SDL/WINE, RetroArch has custom audio, video and input drivers all written from scratch. It was one of the first programs outside of demo programs to support newfangled technologies like DRM/KMS, was very quick in adopting new rendering servers like Wayland, and unlike other software that simply uses middleware like SDL and/or PortAudio to provide sound, we have custom audio drivers written from scratch for ALSA/PulseAudio/JACK/OSS basically since Day One.

The problem with Linux though is that all of these features are highly distro-dependent, and each and every Linux distribution has enough differences that a traditional binary that runs on every Linux distribution is close to impossible. So, for now, we have simply left the responsibility of maintaining and packaging up RetroArch to individual distributions. Distributions like Arch Linux, Debian, and others have RetroArch and the various cores inside their package management repos, and they maintain it separately from us. Similarly, committers like sergio-br2 maintain Ubuntu repositories for RetroArch and its various cores.

But now, there are finally options for those who would like to try out RetroArch on Linux in a distro-agnostic fashion! Read all about it in our Flatpak article that we launched a few days ago. Within a few days, we will also be offering AppImage support.


A serious regression in the iOS version which made 32bit color format cores no longer render has been fixed. Also, a user has been helping us prepare for iOS 11 support.

If you’d like to learn how to compile RetroArch for yourself on iOS for your non-jailbroken device, read this article here.

macOS / MacOS X

RetroArch has been updated for both macOS/OSX Intel (for 64bit) and for OSX PowerPC (for PowerMacs/Powerbooks that have OSX 10.5 installed). The version for PowerPC comes bundled with the cores since we don’t host these on our buildbot (yet?).

PS Vita

Not only has Cheevos support been added, but it’s also possible now to use external USB devices if they are mounted! In order to use RetroArch on Vita, you need a jailbroken PS Vita and/or PSTV. Instructions on how to do that can be found elsewhere and falls beyond the scope of this article.


RetroArch has been updated for all other platforms that we actively support.


We have posted a DEX version. We hope that separate community members can convert this to CEX and then offer it to us so we can host it.

Updates on cores

A separate article will be posted later that will detail all the work that has gone into the various cores. Stay tuned for this! As always, you can always install the latest version of every core from RetroArch’s builtin ‘Core Updater’ (accessible from the menu by going to ‘Online Updater’ -> ‘Update Cores’.

What’s up next?

* We are working hard right now on getting the PPSSPP / Supermodel cores that we have promised ready.
* An AppImage version of RetroArch for Linux will be available soon.
* A Visual Studio 2005 version of RetroArch for Windows will be available soon, which will run on Windows 98/ME/2K.
* Lots of core work like we always do each week.
* More yet unannounced stuff? Stay tuned!

View this page if you’d like to explore donating to us. By popular demand, there is now the ability to send one-off donations through Bitcoin, and we have put up links so that you can directly send funds to the Bountysource bucket. You can also pledge to our Patreon.

RetroArch with Flatpak – Distro-independent Linux version!

Flatpak LogoInstalling RetroArch on Linux has just become a whole lot easier with the use of Flatpak. Flatpak provides a common standard in which to install sandboxed applications across many different Linux operating systems and desktop environments. Along with the Flathub repository, installing RetroArch with Flatpak becomes a breeze.

Install Flatpak

The first thing to do when getting up and running with Flatpak is to install it. There are many different ways to install Flatpak, so I’ll let you decide the best for your distribution. Once installed, you should be able to run the following command to see how to use it:

flatpak --help

Welcome to Flathub

Add Flathub

Much like your favourite package manager, Flatpak uses repositories to manage available applications. Flathub is a quickly-growing Flatpak repository, which is where RetroArch is available from. To let Flatpak know about Flathub, you’ll have to add the repository to your remotes:

flatpak remote-add --user --if-not-exists flathub

Install RetroArch

Now that the flathub remote is available, you can now install RetroArch on Flathub:

flatpak install --user flathub org.libretro.RetroArch

Run RetroArch with Flatpak

When RetroArch is installed through Flatpak, it will automatically become available through the system menu and you can run it as normal. Alternatively, you can also run it through the terminal:

flatpak run org.libretro.RetroArch
Screenshot of RetroArch running through Flatpak
RetroArch running through Flatpak

With Flatpak, you can install applications on Linux very easily, no matter what distribution or desktop environment you use. Flatpak repositories like Flathub provide a central hub in which to keep applications up to date. This revolutionises the way applications can be installed on Linux, and provides just one more easy way to install RetroArch.


New core: Dolphin (Windows/Linux) (Alpha release!)

Dolphin is now available as a libretro core! Dolphin is a popular Gamecube/Wii emulator. Keep in mind that the current version of this libretro core is considered an alpha release. Lots of work still remains but we intend to get it done, and hopefully receive some help along the way as well.

If you’d like to know more about the project, please visit its site here. We would like to ask you to not bother them with issues yet that happen in this libretro core, as things are not quite finished yet and it might take up their time unnecessarily.

Available for

The Dolphin core is currently available for:

  • Windows (64bit)
  • Linux (64bit)

Further requirements: This core requires that you turn on ‘Enable Shared Hardware Context’, otherwise you will only see a single texture being displayed onscreen instead of the game screen.

Note for macOS users: There is currently no ‘working’ macOS version available because of the aforementioned reason. Please be patient and keep the faith, we have not forgotten about macOS users and we have not relegated them to second-class citizen either. Just going to take a little bit of time before we sort this out.

How to get it

  1. Start RetroArch.
  2. Go to Online Updater -> Update Cores.
  3. Download ‘Gamecube/Wii (Dolphin)’ from the list.

Important! How to turn on shared hardware context (required)

This core also requires that you turn on ‘Enable Shared Hardware Context’. If you don’t do this, you will only see a black screen.

First, you need to ensure that ‘Show Advanced Settings’ is turned on. Go to Settings -> User Interface and turn ‘Show Advanced Settings’ on.

Now, go back, and go to Settings -> Core.

Once inside the ‘Core’ settings, set ‘Enable Shared Hardware Context’ to ON.

The upcoming version of RetroArch (version 1.6.1) might make it unnecessary to toggle this, saving you the hassle of having to do this.

How to use the demo

We assume you have already followed the steps in ‘How to get it’, and that the core is already installed.

  • Go to Online Updater -> Content Downloader.

  • Go to ‘Dolphin’, and select the file ‘’.

  • You should now have the required game INI settings placed in the proper directory. Dolphin will look inside this directory for game-specific recommended settings.


NOTE: You can also place the system files inside your System directory, or even the game’s save directory. It looks for a directory called either ‘Dolphin’ or ‘dolphin-emu’ inside those directories.


Right now, the main input device implemented is a GameCube controller. We have laid this out on the RetroPad as follows –

B button – B button

Y button – Y button

Start button – Start button

D-pad – D-pad

A button – A button

X button – X button

L1 – L button/trigger

R1 – R button/trigger

R2 – Z trigger

Left analog stick – Control Stick Left

Right analog Stick – C-Stick

You can reconfigure these controls at your discretion by going to Quick Menu -> Controls while in-game.

Extra features

To access these settings, while the game is running, go to the RetroArch menu, and select 'Quick Menu -> Options'.
To access these settings, while the game is running, go to the RetroArch menu, and select ‘Quick Menu -> Options’.
  • Renderer: Hardware or Software. If you start this core in RetroArch with “Renderer” set to Hardware, it will default to OpenGL or Vulkan depending on which video driver you have selected inside RetroArch. If you choose “Software”, it will use the software renderer instead. It will be dogslow though..
  • Fastmem: Fastmem configures a 4GB range of memory to match the Wii’s address space, and PPC memory accesses are translated directly to x86 memory accesses into this region. Might be faster.
  • PAL60: Turn on PAL60 mode. This was a TV output mode used by Gamecube/Wii games so the game could run at 60Hz instead of 50Hz. Certain games like Metroid Prime 2 would even require this.
  • DSP mode: Can be set to either HLE (High-Level Emulation) or LLE (Low-Level Emulation). HLE is much faster while LLE is much more accurate but tends to be slower. Certain games will require LLE audio, but not the majority.
  • Internal resolution (restart): You can change the internal resolution here. In order for the changes to take effect, you need to restart the core.
  • Skip EFB Access From CPU: This can kill the speed of Dolphin (for those without a top CPU), but it’s necessary for some features.
  • Store EFB Copies To Texture Only: This is a hack. By unchecking it, you’re allowing the emulator to go the more accurate path of storing EFB Copies to RAM (and allowing the emulator to more or less fully emulate what the Wii can do with EFB Copies) which is required for Pokemon Snap to work.
  • Scaled EFB Copy: Prevent overpixeled textures by upscaling them (some games need this option).

More core options will be added soon!


Some of the features that are currently implemented:

  • Working OpenGL renderer. Requires core GL 3.3 context and requires ‘shared hardware context’ to be enabled (see above instructions).
  • Working Vulkan renderer. Might still have some ghosting/frame pacing issues.
  • Working software renderer.
  • Working dynamic recompiler for x86-x64.
  • Working Nintendo Gamecube/Wii Classic pad support.
  • Disabled analytics.
  • Savestates are working.
  • Internal resolution can be changed by going to Quick Menu -> Options and changing ‘Internal Resolution’. This currently requires a restart of the core.


We are not calling this an alpha release for nothing. Although it took a lot of work to get to the state we are in right now, do consider this:

  • We have not implemented pass-through Gamecube/Wiimote support at all yet.
  • Right now we are not using the audio mixer, so games with streaming audio (like Super Monkey Ball/Ikaruga) might be missing their ingame music. We intend to implement this of course. The games affected can be found on this list here.
  • We are a few revisions behind upstream right now. The intent is there to update to the latest sources. Some changes were made by the initial porter of this core to support PIC inside the dynarec, and upstream has since done their own take on it. The initial porter disagreed with the implementation of this, but we will make a suitable enough decision later on as to whether to go with the initial porter’s take on it or upstream’s. Do consider that there are valid reasons sometimes for diverging from upstream for the sake of improving the quality of the port.
  • There are some games that currently display some issues which aren’t there in standalone. These seem to be renderer-related. For instance, Resident Evil only shows a black screen after the company logo screens with the OpenGL renderer, yet it renders and works fine with the Vulkan renderer. These issues will still need to be resolved..
  • There might be issues with more than one gamepad right now.
  • Savestates are not reliable right now. It’s technically hooked up but it’s bug/crash-prone.
  • We still intend to have built-in game setting defaults so that even the current step of having to download these Game Settings from our buildbot is unnecessary. A prime design goal of libretro cores is that not only should there be as little dynamic library dependencies as possible, but also as few external data file requirements. So in other words, for certain data files to exist in some random directory is often regarded as not being nearly portable enough for our tastes. We rather like that the entire program is encapsulated inside one dynamic library file and that is all there is to a working configuration.

Note on maintenance

We’d like to stress that porting Dolphin is a big endeavor and undertaking, and as such, Dolphin developers and users alike should consider this a code experiment laboratory right now. This is also why we’d really appreciate it if anybody DO NOT BUG the Dolphin project right now on any issues they might experience in this alpha core yet. We were pretty much left to our own devices porting this. The intent is for us to get to complete feature parity with the standalone version and once we have managed to do so, figure out a way to get this in a form so that it can be upstreamed again. If there is going to be a hard fork of Dolphin, it will be separate from a mainline, upstream-compatible Dolphin core so that people who always prefer to be in lockstep with upstream will get what they want, while people who would like to see the advantages of a hard fork could still go for that separate version as well. We are trying to appease both sides here, certain codebases lend themselves better to libretro core-ification vs. others and often developers and users alike are not fully cognizant of the different approach this requires. That all being said, we intend to get along better with emulator teams provided we are given a fair shake and cooperation can happen instead of antagonism. We do not intend to step on anybody’s toes, and we’d like to be able to work together with anybody. There is some interests at least amongst some Dolphin devs to help us finish up these remaining parts, which is very refreshing to see.

New core: OpenLara (Windows/Linux)

OpenLara is now available as a libretro core! This is a new work-in-progress Tomb Raider game engine by developer XProger and is already progressing rapidly.

If you’d like to know more about the project, please visit its site here. There’s even a cool web demo you can check out here.

Available for

The OpenLara core is currently available for:

  • Windows (32bit/64bit)
  • Linux (32bit/64bit)

Further requirements: This core requires that you turn on ‘Enable Shared Hardware Context’, otherwise you will only see a single texture being displayed onscreen instead of the game screen.

Note for macOS users: There is currently no ‘working’ macOS version available because of the aforementioned reason. Please be patient and keep the faith, we have not forgotten about macOS users and we have not relegated them to second-class citizen either. Just going to take a little bit of time before we sort this out.

How to get it

  1. Start RetroArch.
  2. Go to Online Updater -> Update Cores.
  3. Download ‘Tomb Raider (OpenLara)’ from the list.


  • This core requires that you use OpenGL as the video driver. Go to Settings -> Driver. If ‘video driver’ is set to ‘vulkan’, switch it back to ‘gl’, and then restart.

How to turn on shared hardware context (required)

This core also requires that you turn on ‘Enable Shared Hardware Context’. If you don’t do this, you will only see a single texture on the screen, like this –

If you see this, then 'Enable Shared Hardware Context' should be turned on!
If you see this, then ‘Enable Shared Hardware Context’ should be turned on! Read below on how to do that!

First, you need to ensure that ‘Show Advanced Settings’ is turned on. Go to Settings -> User Interface and turn ‘Show Advanced Settings’ on.

Now, go back, and go to Settings -> Core.

Once inside the ‘Core’ settings, set ‘Enable Shared Hardware Context’ to ON.

The upcoming version of RetroArch (version 1.6.1) might make it unnecessary to toggle this, saving you the hassle of having to do this.

How to use it

Convincing self-shadowing effects which the original games didn't have.
Convincing self-shadowing effects which the original games didn’t have.

Right now, OpenLara is more of a tech demo. You have to load separate levels into the program in order to play them. You cannot currently play Tomb Raider from beginning to end using this core. We hope that it will book major progress so that one day we can replay the old Tomb Raider games entirely with these enhanced graphics and enhanced framerates. To this end, we intend to support the project.

For demonstration purposes, we provide you with the Tomb Raider 1 demo levels so that you can test it out. It is also possible to use levels from the PC/PSX version and load this into the game engine core, so try that out at your own discretion.

How to use the demo

We assume you have already followed the steps in ‘How to get it’, and that the core is already installed.

  • Go to Online Updater -> Content Downloader.

  • Go to ‘Tomb Raider’, and select the file ‘’.

  • Go back to the main menu, and now select ‘Load Content’. Select ‘Downloads’. Go to the folder ‘Tomb Raider’, and select LEVEL2.PSX. If all went well, OpenLara should now start at Level 2 of Tomb Raider 1.


Be aware that certain gameplay elements are simply not implemented as of yet, such as health bars, taking damage, etc. You can ‘complete’ the stage technically but you also cannot die or continue to the next level.


The controls on the RetroPad are set up to mirror those of the PSX Tomb Raider games.

L2 – Sidestep left

R2 – Sidestep right

R1 – Hold to walk

Y button – Jump

B button – Action button. Can be used to flick switches/toggles, etc, or to grab a ledge.

X button – Draw weapon. Press B button to shoot, and press X again to withdraw.

A button – Do a roll. This works a bit different from regular Tomb Raider mechanics in that it will perform a back dash if you press the A button without moving.

Start button – This will toggle a fullscreen mode that is very much like what Mirror’s Edge would have looked like with a PS1-era game engine.  Note that toggling this right now is very finicky, and will be improved in the future.

There is currently no way to toggle the inventory or to select weapons on the RetroPad other than the default guns. The reason for there being no inventory is because OpenLara itself doesn’t have that yet.


The MIrror's Edge-style first person mode along with Lara's shadow projected onto the wall
The MIrror’s Edge-style first person mode along with Lara’s shadow projected onto the wall

The nice thing about OpenLara is that, while staying true to the original look and feel of the original, it also adds some graphical enhancements to it that manages to make the boxy old-school Tomb Raider games look a bit less archaic. Some examples include :

  • Self-shadowing on Lara, enemies, etc.
  • New water effects which replaces the simple vertex manipulation of the water surface on the PSX. The Saturn version actually was the only version that tried to do something a bit more sophisticated with the water. If you dislike these very nice graphical enhancements, I inserted a core option so you can turn these off (‘Enable water effects’ in Quick Menu -> options).
  • Shading effects – after Lara gets out of the water, her skin has a slightly wet shading effect.
  • A first-person mode that is more convincing and fun than what you’d expect. It behaves a bit like Mirror’s Edge in that the camera bobs up and down, and you can see Lara’s hands move in front of you. If you try to do a somersault – the camera will rotate along with it as well. What makes the firstperson mode a bit more convincing is the new self-shadowing effects that have been added.

Extra features

To access these settings, while the game is running, go to the RetroArch menu, and select 'Quick Menu -> Options'.
To access these settings, while the game is running, go to the RetroArch menu, and select ‘Quick Menu -> Options’.
  • You can increase the resolution all the way up to 2560×1440. Higher resolution modes might become available as time goes on.
  • The OpenLara core is framerate-independent. Go to Quick Menu -> Options, change ‘Framerate’ to the value you desire, and then restart the core. You can run OpenLara at 30fps / 60fps / 90fps / 120fps / 144fps. The default framerate is 60fps.
  • You can turn the advanced water effects off if you so desire. Go to Quick Menu -> Options, change ‘Water effects’ to ON/OFF, and then restart the core. You can also turn on/off bilinear filtering similarly.


There are still some things which are not fully implemented in this version.  Some examples include:

  • Save states are not implemented. And savestates don’t seem to be implemented in upstream either, so not much that can be done about it at this stage.
  • As mentioned before, this is still more of a tech demo project. You cannot complete any Tomb Raider game right now from beginning to end; you can only play individual levels.
  • The analog sticks are currently unbound. It might be a good idea to bind camera manipulation to the second analog stick.
  • There are no mouse controls. The standalone version does have this. We will try to hook this up as well later.

Still coming up!

Still yet to be released shortly (in the next few days) is:

  • Dolphin (Gamecube/Wii emulator, with Gamecube-only controls at first)

This will probably coincide with a new version of RetroArch, version 1.6.1. Stay tuned!

More new cores: MelonDS, SameBoy, ARM Linux cores!

This week will be all about a dripfeed of new cores along with a version bump of RetroArch, which will be needed for some of the new cores that will be arriving this week.


This is an up-and-coming Nintendo DS emulator by StapleButter, and it now has a libretro port. Some of the things that are still not properly implemented is touchscreen/mouse support and multithreading for the software 3D rasterizer, but we will take care of that soon. This emulator might not yet be a replacement for DesMuMe, but it’s quickly progressing so definitely keep your eyes on it, as DesMuMe certainly needs some competition.

You can get this new core on our buildbot. Start up RetroArch, go to ‘Online Updater’, and check for ‘MelonDS’.

For more information on MelonDS, check out its official homepage here.

Available for

The MelonDS core is currently available for:

  • Windows (64bit/32bit)
  • Linux (32bit/64bit)
  • macOS
  • iOS
  • Android

BIOS instructions, etc. (required)

MelonDS requires a real BIOS file in order to work. These need to be placed inside your System directory. If you don’t know where your System directory is, inside RetroArch, go to Settings -> Directories and read where your System Directory is located.

The following three files are all required:

  • bios7.bin
  • bios9.bin
  • firmware.bin



SameBoy is an accuracy-focused Game Boy/Game Boy Color emulator in the vein of Gambatte. We now have a libretro core of it and its author has also helped us earlier with some implementation details, so that is very much appreciated!

Some features that are still missing is savestate support, but we intend to get that done soon.

For more information on SameBoy, check out its official homepage here.

Available for

The SameBoy core is currently available for:

  • Windows (64bit/32bit)
  • Linux (32bit/64bit)
  • macOS
  • iOS
  • Android

BIOS instructions, etc. (optional)

Here is a tiny convenience feature you added – normally SameBoy relies on reverse engineered Game Boy/Game Boy Color boot ROMs in order to load. You can load these instead of the real BIOS file. For this libretro core, instead of requiring you to put these homebrew boot roms somewhere so that the emulator can read them, we have baked these into the core itself. So you don’t even need to put them somewhere in your system directory.

However, if you’d like to override these, you can do that too. Go to your system directory (if you don’t know what this is, inside RetroArch, go to Settings -> Directories and read where your System Directory is located) and put these files there:

Game Boy boot ROM – ‘dmg_boot.bin’

Game Boy Color boot ROM – ‘cgb_boot.bin’

ARM Linux cores!

Our buildbot is now providing fresh new ARM Linux cores for hardfloat configurations! These cores could be used for instance on Lakka-based devices as well as the NES Mini!

You can grab them here:

Miscellaneous updates

  • Mednafen/Beetle Saturn has been updated to the latest version.
  • Updates to ParaLLEl N64 core.

What’s still coming up this week?

In no particular order:

  • Redream (new Sega Dreamcast emulator made by inolen)
  • OpenLara (Tomb Raider 1 game engine, in early alpha development stages but already promising)
  • Dolphin (will have Gamecube controls only at first, will work for both GL and Vulkan)
  • Citra

New Core: PX68k (Android/iOS/Windows/Linux/Mac)

Disclaimer: This article was written by Tatsuya79, who has also contributed many improvements to the X-68K core. Developer r-type is the one who made the port

The Sharp X68000 was a home computer released exclusively in Japan in 1987. It was a powerful machine for its time and saw a great number of arcade ports, exclusive titles and doujin (indie) games developed for it, even years after the last model was launched in 1993.

Until now the only way to run Sharp X68000 games in RetroArch was with MAME. Its driver isn’t really the most advanced one and it is quite demanding, excluding many platforms such as smartphones.

Outside Retroarch, PX68k was aimed to be fast enough for that usage. Based on Winx68k, targeting the PSP and ported to iOS and Android by its Japanese developer Hissorii, it was possibly the only X68000 emulator on those platforms. As its development stopped some years ago, compatibility issues due to OS upgrades made its usage rather complicated.

Developer R-Type decided to port it to RetroArch, replacing its old 32 bits based CPU emulation by a 64 bits one from Yabause core. There is also a back end for the cyclone cpu on arm/android but surprisingly it didn’t give any speed enhancement and had more problems than the previously mentioned c68k.

After a common effort to fix various issues resulting from this change (thanks Retro-Wertz), it should now be at the same level of compatibility as the original emulator.

Running some tests on an old Samsung Galaxy S3, where we could barely emulate a 16MHz CPU before with PX68k stand-alone, we now achieve smooth results with a 66MHz setting. This makes it 4 to 5 times faster than before, and the libretro port is probably now the best performing Sharp X68000 emulator you can get for various cheap or old devices.

Testing on an [email protected] with “Akazukin Cha Cha Cha” achieved upwards of 1000fps on the default 10MHz emulated CPU. The same test gives 136fps in RetroArch using the Mame core.

The PX68k-libretro core still keeps the same main limitation of the original: no MIDI emulation. We also need to bring a virtual keyboard back, you can only use real ones at the moment. However, we did make some improvements:

1.) You don’t need to load a particular utility to define the amount of RAM the machine uses any more, there’s now a core option for that.

2.) You can change the CPU speed in real time.

If, like some old DOS games behaved, you encounter one that runs too fast (ex. Arkanoid), you can directly slow down your CPU from a fast 25MHz to the 10MHz clock speed it was programmed for.

We also added some overclock steps as high as 200MHz. High frequencies have the side effect of speeding up the floppy loading time, which is a much welcomed accident on this machine. (100MHz is already a lot faster for that.)

-We made some 8 buttons gamepad profiles which weren’t used that much on the system, but are great for the various Street Fighters II iterations.

You’ll need the bios files, which have been made publicly available by Sharp. Place them in your system/BIOS directory, in a subdirectory named “keropi”. The iplrom.dat and cgrom.dat are necessary, but you do not need the sram.dat. See the core information for a complete list.

L2 button or F12 key brings up the original px68k menu where you can change the inserted disks. They have to be unzipped to be accessible from this menu but can be zipped/archived when launching directly from RetroArch.

After the first boot a “config” file will be generated in the “keropi” folder. You can enter your rom folder into the “StartDir” line to make it accessible from the PX68k-libretro core’s in-game menu.

RetroArch 1.6.0 – Released!

RetroArch 1.6.0 has just been released!

Get it here.

PS3 port

Sony might have just ended production of the PlayStation3 in Japan as of two days ago, but we are still supporting it for RetroArch regardless! The last stable release for RA PS3 was back in 1.3.6 days, so the remaining diehard PS3 jailbroken users will be glad to hear that 1.6.0 is available for PS3 right now!

We are only supplying the DEX version. We will assume PS3 repackers will be able to make a CEX version out of this.

PowerPC OSX port

It’s also been a long time since we released a new build of the PowerPC OSX port. We have bundled the cores that have been ported to PowerPC inside the main app bundle. To use this version, you need at least MacOS X version 10.5 (Leopard) and a PowerPC Mac.

Wii port

The Wii port has received stability fixes amongst other things.

WiiU port

Each and every RetroArch release is always a community effort. FIX94 and aliaspider have made numerous improvements to the WiiU version of RetroArch. For one, it has HID controller support now, which means you can use gamepads other than the default Wii U gamepads on it. There is also support for the XMB and MaterialUI menu drivers. There are some graphical touches missing from it such as shader effects though, so don’t expect to see the fancy ribbon animating on the WiiU yet.

Overall, it is a big improvement on what went before. Netplay should also start to work on WiiU.

PS Vita port

Frangarcj has provided patches which fixes the slow file I/O speeds for the Vita port, an issue which afflicts a lot of homebrew on the Vita actually. Menu performance regressions should also be fixed. For instance, the menu was previously erroneously running at 30fps.

Windows version improvements

Windows users now can use the WASAPI audio driver for the first time, which should allow for lower-latency audio. And if that isn’t enough, there is another successfully completed bounty, a RawInput input driver, which should allow for lower-latency low-level input.

Vulkan renderer

The Vulkan renderer has received some improvements. It should now support Unicode font rendering and render certain accented French characters correctly.


There have been several localization improvements. The German and Japanese translations have been updated, and Korean text should finally display properly.

Audio mixer

Now here is a real standout feature courtesy of leiradel we are excited to tell you about! RetroArch now has a built-in audio mixer which allows you to mix up to 8 separate audio streams and splice them together with the game’s audio. To put it more simply, this means custom soundtrack support from inside RetroArch!

Currently, there are a couple of limitations here –

1 – The only supported audio files so far are Ogg Vorbis files (.ogg) and regular Wave files (.wav). Over time, there will be more audio codecs supported.

2 – The audio mixer tracks will only play when the game is running. They will not play while inside the menu, unless you turn off ‘Pause when menu activated’ (Settings -> User Interface -> Menu).

3 – You can only mix up to 8 simultaneous audio streams so far. Looping is not yet available, neither is pausing an audio stream or changing a stream’s volume. All of these might be added in later versions of RetroArch though.

Here is a quick demonstration of how you use it:

While the game is running, go to Load Content, and select a supported audio file (either an Ogg Vorbis .ogg file or a .wav file)
While the game is running, go to Load Content, and select a supported audio file (either an Ogg Vorbis .ogg file or a .wav file)
Select ‘Add to MIxer’. If the game is already running, this should start playing the music immediately and also add it to your music collection.
You can easily access this music track at any point in time from this point on by going to your Music tab inside the XMB. You can then start mixing the audio again by selecting it again and choosing ‘Add to mixer’.


Here is a changelog of most of the things that changed:

– AUTOSAVE/SRAM – Fix bug #3829 / #4820 (
– ENDIANNESS: Fixed database scanning. Should fix scanning on PS3/WiiU/Wii, etc.
– NET: Fix bug #4703 (
– ANDROID: Runtime permission checking
– ANDROID: Improve autoconf fallback
– ANDROID: Improve shield portable/gamepad device grouping workaround
– ANDROID: Allow remotes to retain OK/Cancel position when menu_swap_ok_cancel is enabled
– LOCALIZATION: Update/finish French translation
– LOCALIZATION: Update German translation
– LOCALIZATION: Update Japanese translation
– LOCALIZATION/GUI: Korean font should display properly now with XMB/MaterialUI’s default font
– MENU: Improved rendering for XMB ribbon; using additive blending (Vulkan/GL)
– OSX/MACOS: Fixes serious memory leak
– WINDOWS: Added WASAPI audio driver for low-latency audio. Both shared and exclusive mode.
– WINDOWS: Added RawInput input driver for low-latency, low-level input.
– WINDOWS: Core mouse input should be relative again in cores
– MISC: Various frontend optimizations.
– VIDEO: Fix threaded video regression; tickering of menu entries would no longer work.
– WII: Fix crashing issues which could occur with the dummy core
– WIIU: HID Controller support
– WIIU: XMB/MaterialUI menu driver support
– WIIU: Initial network/netplay support
– LOBBIES: Fallback to filename based matching if no CRC matches are found (for people making playlists by hand)
– LOBBIES: GUI refinement, show stop hosting when a host has been started, show disconnect when playing as client
– LOBBIES: if the game is already loaded it will try to connect directly instead of re-loading content (non-fullpath cores only)
– LOBBIES: unify both netplay menus
– THUMBNAILS: Thumbnails show up now in Load Content -> Collection, Information -> Database
– VITA: Fix slow I/O
– VITA: Fix 30fps menu (poke into input now instead of reading the entire input buffer which apparently is slow)
– VITA: Fix frame throttle
– VULKAN: Unicode font rendering support. Should fix bad character encoding for French characters, etc.
– VULKAN: Fix some crashes on loading some thumbnails
– AUDIO: Audio mixer support. Mix up to 8 streams with the game’s audio.

New Lakka 2.1 RC release!

A new release candidate of Lakka, our popular set-top box solution powered by RetroArch, was recently released!

Please read more about it here.

Important shader-related changes

Please read hunterk’s extensive article on some organizational changes we are making to our popular shaders collection.

Upcoming events

Stay tuned for our first official unveiling of the Dolphin libretro core in the upcoming days, as well as releases of OpenLara, PX-68K, Neko Project II, Redream and other new cores! There will also be a survey/poll which will let you decide which cores we are going to port next!

Shader Changes


GLSL shaders now preferred over Cg when possible
Update to latest RetroArch for compatibility with updated GLSL shaders

Cg shaders demoted, GLSL promoted to first-class

Portability and compatibility are major goals for RetroArch and libretro, so we invested heavily in Nvidia’s Cg shader language, which worked natively anywhere their Cg Toolkit framework was available (that is, Windows, Linux and Mac OS X), as well as on PS3 and Vita, and could be machine-compiled to messy-but-usable GLSL (lacking a few features, such as runtime parameters) for platforms that lacked the framework (primarily ARM / mobile platforms). Cg was also so close to Microsoft’s HLSL shader language that many Cg shaders will compile successfully with HLSL compilers, such as those available with Windows’ D3D driver and on Xbox 360.

This was great for us because we could write shaders once and have them work pretty much everywhere.
Sadly, Nvidia deprecated the Cg language in 2012, which left us in a bad spot. Since then, we’ve been limping along with the same strategy as before, but with the uneasy understanding that Nvidia could stop supplying their Cg Toolkit framework at any time. Rather than sit idly by, waiting for that other shoe to drop, we took it upon ourselves to hand-convert the vast majority of our Cg shaders to native GLSL with all of the bells and whistles. TroggleMonkey’s monstrous masterpiece, CRT-Royale, still has a couple of bugs but is mostly working, along with its popular BVM-styled variant from user Kurozumi. Additionally, before this conversion, many of our Cg shaders were flaky or completely unusable on libretro-gl cores, such as Beetle-PSX-HW’s OpenGL renderer, but these native GLSL conversions should work reliably and consistently with any core/context except for those that require Vulkan (namely, ParaLLEl-N64’s and Beetle-PSX-HW’s Vulkan renderers).

With the GLSL shaders brought up to speed, we can finally join Nvidia in deprecating Cg, though it will still remain as an option–that is, we’re not *removing* support for Cg shaders or contexts at this point–and we will continue to use it where there is no other choice; namely, Windows’ D3D driver and the Xbox 360, PS3 and Vita ports. Moving forward, our focus for shaders will be on native GLSL and our slang/Vulkan formats, though we will likely still port some to Cg from time to time.

RetroArch now correctly handles #version directives in GLSL shaders; GLSL shader repo updated to match

There have been a number of updates to the GLSL shader language/spec over its long life, and shader authors can use #version directives (that is, a line at the top of the shader that says #version 130 or whatever) to tell compilers which flavor/version of GLSL is required for that shader. However, RetroArch has long had a strange behavior whereby it injected a couple of lines at the beginning of all GLSL shader files at compile time, and this broke any shader that attempted to use a #version directive, since those directives must be on the first line of the shader. This meant that our shaders couldn’t use #version directives at all, and all of our shaders lacked #version directives until very recently for this reason. These #version-less GLSL shaders are still perfectly compliant GLSL because GLSL v1.10 didn’t support directives, either, but the necessity of leaving off the #version started to cause some problems as we whipped our GLSL shader library into shape.

The error caused by adding a #version directive under the old behavior.

On AMD and Nvidia GPUs, the compilers would just toss up a warning about the missing directive and still expose whatever GLSL features were available to the GPU, which worked out great. On Intel IGPs, however, the compiler tosses the error and then reverts to only exposing the features available in ancient GLSL v1.10 (released way back in 2004). As a stopgap, we gave many shaders fallback codepaths that would still work in these circumstances, but a number of other shaders were either impossible to make compatible or even the compatible result was imperfect.

So, as of this commit (courtesy of aliaspider), RetroArch will no longer reject shaders with explicit #version directives, and we have added those directives to any shaders that require them at the lowest version that still compiles/functions properly. That is, if the shader doesn’t use any features that require greater than #version 110, they will still have no #version specified, and any shader that requires #version 120 but not #version 130 will not have its requirements increased to the higher version for no reason. This should keep our GLSL shaders as compatible as possible with older hardware, and including the #versions explicitly when needed will also make it easier for other programs/developers to utilize our shaders without any unnecessary guesswork due to behind-the-scenes magic.

This change does require a clean break, insofar as older versions of RetroArch will choke on the new #version directives (that is, they’ll fail to compile with the “#version must occur before any other program statement” error pictured above), so users with Nvidia or AMD GPUs must update their RetroArch installation if they want to use the updated shaders. Users with Intel IGPs will be no worse off if they don’t update, since those shaders were already broken for them, but they’ll probably *want* to update to gain access to the many fancy shaders that now work properly on their machines.

Mobile GPUs using GLES had many of the same issues that Intel IGPs had, with many shaders refusing to work without #version directives, but GLES compatibility added in a further complication: GLES requires its own separate #version directives, either #version 100 es or #version 300 es, which are different from and incompatible with desktop GL’s #versions. To get around this, we added a trick in RetroArch to change any #version of 120 or below to #version 100, which is roughly comparable in features to 120, and any #version 130 or above to #version 300 es whenever a GLES context is used. This should get everything working as effectively and consistently as possible on mobile GPUs, but if anything slipped through the cracks, be sure to file an issue report at the GLSL shader repo.