RetroArch 1.6.6 – Released!

RetroArch 1.6.6 has just been released! Grab it here.

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

General changelog

– 3DS: Fixes serious performance regression that affected every core; rewind was always implicitly enabled.
– AUDIO: MOD/S3M/XM sound should now be properly mixed in with the core’s sound.
– GUI: Visual makeover of MaterialUI.
– GUI: Added ‘Music’, ‘Images’ and ‘Video’ collection options to RGUI/MaterialUI.
– GUI: Allow the user to add ‘Favorites’.
– GUI: Allow the user to rename entries.
– GUI: Performance optimizations for XMB menu driver.
– LOCALIZATION: Update Italian translation
– INPUT: Overlay controller response – when we press buttons on the gamepad or keyboard, the corresponding buttons on the overlay will be highlighted as well.
– NETBSD: Silence some compilation warnings.
– COMMON: Fixed bug ‘Deleting an entry from a playlist would not update the list view inside XMB’.
– COMMON: Fix inet_ntop_compat on *nix

If you want to read about the latest bounty and core updates, read this post instead here.

Complete overhaul of the mobile User Interface! (MaterialUI)

On mobile devices, RetroArch uses the mobile UI, MaterialUI, by default. This interface is designed around touchscreen and pointer devices like a mouse/trackball.

We have given this menu interface a significant overhaul now for version 1.6.6! We are aware that there is a significant percentage of people that to date have been completely unsatisfied with the current state of the menu system on mobile devices like Android and iOS. Our menu UI improvements in version 1.6.6 is our first step to try to remedy this. In later releases, we might follow it up with more elaborate animations, more advanced widgets, etc.

The menu should look less monotonous now due to the usage of context-specific icons. We have also made some other UX improvements:

– The opacity of the game’s image clashed quite badly with the ingame menu before. This has been rectified.
– We have added ‘Music’, ‘Image’ and ‘Video’ playlists to the ‘Favorites’ tab.

Music, Video and Images which have previously been loaded in RetroArch can be easily accessed from the Playlists tab now.
Music, Video and Images which have previously been loaded in RetroArch can be easily accessed from the Playlists tab now.

– The file browser is easier to read now because files show up with specific icons to indicate what they are. For instance, music files have a music icon, a directory has a folder icon, selectable content files show up as a plain file, etc.

The file browser is easier to read now because files show up with specific icons to indicate what they are. For instance, music files have a music icon, a directory has a folder icon, selectable content files show up as a plain file, etc.
The file browser is easier to read now because files show up with specific icons to indicate what they are. For instance, music files have a music icon, a directory has a folder icon, selectable content files show up as a plain file, etc.

Usability tips

You can customize the color theme of the menu in MaterialUI at any time.

1 – Go to User Interface.
2 – Go to Views.
3 – Go to ‘Menu Color Theme’ and set it to the color theme you want.

General menu improvements


You can now add a game to a ‘Favorites’ list for easy access! This has been an often-requested feature for years, and in the past we always felt that ‘Load Recent’ was good enough. However, if you load a lot of content, that can easily get cluttered over time.

To add a game to the Favorites list, do the following:
1 – Once a game is running, go to ‘Quick Menu’.
2 – Select ‘Add To Favorites’.
3 – Once added, you can now start the game at any time from the Favorites list.

On RGUI – go to Load Content -> Favorites.
On MaterialUI – go to the Playlists tab -> Favorites.
On XMB – go to the Favorites tab.

To add a game to the 'favorites' list, inside Quick Menu, select 'Add To Favorites'. It should now be added to the Favorites list. You can access the 'Favorites' list inside MaterialUI by going to the Playlists tab. On RGUI, you go to Load Content -> Favorites. On XMB, you go to the Favorites tab instead.
To add a game to the ‘favorites’ list, inside Quick Menu, select ‘Add To Favorites’. It should now be added to the Favorites list. You can access the ‘Favorites’ list inside MaterialUI by going to the Playlists tab. On RGUI, you go to Load Content -> Favorites. On XMB, you go to the Favorites tab instead.

Renaming entries inside playlists

You can now rename an entry from any playlist!

To do this, do the following:

1 – Go to a playlist of any type (it can be the history list, a system playlist, favorites, music/video/images playlists, etc).
2 – There should be an option called “Rename”. Select it. If you are using MaterialUI and/or XMB, an onscreen keyboard will now pop up. Input the new title for the entry and then hit either the Enter key on your keyboard ,the Start button on your gamepad or press the ‘Enter’ key on the onscreen overlay in order to confirm the changes.

You can now rename any entry! Say for instance you loaded a Quake data file. Instead of the playlist showing 'PAK0.PAK', you can rename it to Quake 1 instead.
You can now rename any entry! Say for instance you loaded a Quake data file. Instead of the playlist showing ‘PAK0.PAK’, you can rename it to Quake 1 instead.

Overlays show button presses

Previously, overlays would only show button presses if they were actually being clicked on by either the touchscreen or the mouse.

A user submitted a bounty to make onscreen reactions possible through the gamepad and/or keyboard. A bounty hunter has now successfully completed this bounty and has been paid out. We have enabled this feature by default. If you want to turn it off, you can do so by doing the following:

1 – Go to Onscreen Display -> Onscreen Overlay.
2 – Go to ‘Show Inputs on Overlay’. Set this to off if you don’t want the overlay to react to keyboard/gamepad input, turn it on if you want this to happen (turned on by default).

Nintendo 3DS regression fix – all cores were running slower

A serious issue has been fixed in the Nintendo 3DS RetroArch port which compelled us to push this release sooner rather than later.

It appears that by mistake, rewind was always forcibly enabled in the 3DS port, which led to a halving of performance. This should now be fixed.

What’s next?

The new cores

We are still determined to get the promised cores like PPSSPP into your hands before the end of the month. We just felt it very important to get this release out of the door so that people can see that we are determined to improve the menu on mobile, and also so that the 3DS RetroArch port is repaired again.

Wii input fix

Finally, after years of struggling with this very pesky issue, it seems we are on the verge of a breaktrhough here that could lead to this random input issue finally being fixed –

it seems there was a regression in libogc at some point which lead to this input regression. Superssonic reports that going back to an older version of Wiiuse fixes the issue. What we are probably going to do is make a custom baked-in libogc version for the Wii port for the next release.

Core updates and bounty updates (since version 1.6.4)

Despite the short release cycle, there has been a fair bit of core work since the 1.6.4 release, including some significant contributions driven by the recently implemented bounty system. In no particular order:

Core updates

Snes9x 2005

JamSilva has been pushing various updates/fixes/improvements:
* Loading savestates seems to no longer cause segfaults
* Improved sound in the non-plus version – especially noticeable in Secret of Evermore.
* Working SPC7110 emulation (quickly tested with Tengai Makyou Zero and Momotarou Dentetsu Happy).
* CPU emulation fixes – E.V.O – Search for Eden
* CPU emulation fixes – Wizardry V
* The SA1 fixes correct the VLDC9 “WORST” level transition problem I mentioned in #36.
* Backport Brunnis lag fixes. I did not actually measure the input lag after applying the patch, only that there was no (obvious) game breakage on a few games.

Genesis Plus GX

Ekeeke pushed the following changes to upstream and the libretro core –
* [Core/CD] fixed CD hardware buffer initialization when using dynamic memory allocation – should fix crash at startup on WiiU

Parallel N64

* Add delay SI entries for Mischief Makers


r-type has ported this core to WiiU.

Beetle PSX

Various fixes have been committed:
* Fix PSX EXE loading.
* Fix some OpenGL regressions that crept in. Should fix in specific backgrounds in Crash Bandicoot games.

Beetle PC Engine Fast

rtissera has committed the following:
* MAME CHD image support

Beetle PC-FX

rtissera has committed the following:
* MAME CHD image support

Beetle SuperGrafx

rtissera has committed the following:
* MAME CHD image support

Final Burn Alpha

Various fixes and backports have been committed by barbureadmon and others:
* Fix for sound issues in Strikers 1945 Pro (s1945p)
* Hotfixes in upstream
* Fix some weird CPS2 layout
* Fix EEPROM saving
* PGM – single pcb boards, missing bios issue


underball has committed the following improvements:
* Added new DB entry for Double Dragon (RC7b) hack, also corrected MD5 value for Double Dragon (RC7). Added value=1 for “Flags” to One on One, and Basketbrawl. Also added missing values for Ninja Golf.

Bounties fulfilled/paid out

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.

Core updates (since version 1.6.3)

Despite the short release cycle, there has been a fair bit of core work since the 1.6.3 release, including some significant contributions driven by the recently implemented bounty system. In no particular order:

  • r-type fixed Beetle NGP‘s longstanding bugs with big-endian architecture, which should allow that core to control properly on those architectures. He also fixed compilation of the atari800 and Hatari cores on Wii U and fixed some issues with the cap32 core on that platform.
  • Twinaphex and r5 continued overhauling Beetle PSX HW‘s OpenGL renderer, doing much behind-the-scenes work that isn’t particularly visible to end-users but should improve stability and lay the groundwork for future improvements.
  • Twinaphex also added MSVC2005 solutions for many cores, making them compatible with our Win98 port of RetroArch.
  • bparker fixed some memory and GL issues with the Craft Minecraft clone core, which should correct an issue where the core was crashing at launch for some people.
  • markwkidd backported C-based MIPS3 support to MAME2003, which gets Killer Instinct and Killer Instinct 2 working with this core. Without a MIPS dynarec, they’re too demanding for most ARM devices, unfortunately (Killer Instinct 1 is not quite full speed on my Shield ATV, while Killer Instinct 2 is pretty far from full speed; Raspberry Pi is, of course, not even close), but they should work fine on x86 and x86_64 devices.
  • Bounty hunter rtissera added CHD support to Beetle Saturn and Beetle PC Engine Fast – with plans to add support for this format to several other disc-based cores in the near future–and hooked up support for the Saturn’s 3D pad. He also fixed an issue with MAME 2003 with Midway DCS games that would lead to audio issues at set intervals. This should fix the sound in Mortal Kombat 1/2/3/Ultimate, NBA Jam, Total Carnage, etc. other games.
  • casdevel, another active bounty hunter, fixed mouse input in Desmume libretro.
  • albertofustinoni submitted changes for a variety of cores to make them compatible with his RetriX UWP libretro frontend, which is compatible with Windows 10, Windows Phone and Xbox One developer mode.
  • orbea committed some buildfixes for the early work-in-progress Basilisk2 core.
  • yoshisuga continued adding build targets for iOS ARM64 in various cores.
  • hunterk did the mind-numbing work of bisecting and correcting a regression in Snes9x Libretro that apparently broke the game Phalanx back in May.
  • psyke83 fixed a crash with Tyrquake that could happpen on Raspberry Pi-based devices (e..g. Retropie).
  • Citra / OpenLara / Dolphin will now work without having to explicitly enable ‘Shared Hardware Context’ in RetroArch.

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

Recent Core Updates

As always, there have been many updates to various libretro cores from a number of contributors, some of whom are regular contributors and some of whom have never contributed to libretro projects before. Here are some of the highlights, in no particular order:

  • r5 and Twinaphex did a deep-dive on the Beetle PSX HW OpenGL renderer to resolve a host of issues that would lead to crashes whenever users messed with internal resolution and/or toggled fullscreen. Those context changes should now be handled gracefully and without any major issues.
  • RobLoach updated MelonDS to match StapleButter’s upstream v0.4 release and added to the ScummVM libretro core the ability to launch *.scummvm files located inside game directories. He also merged a variety of updates from upstream EasyRPG to the libretro core and added FFMMidi for MIDI support.
  • bparker snatched up the $50 bounty to fix a longstanding issue with 3DO emulator 4DO Libretro, which caused saving to be broken. Prior to this fix, saves were just garbage data and the core would try to load *other* garbage data. Everything should work fine now.
  • Twinaphex backported a slew of per-game hacks/fixes from upstream Mupen64Plus to ParaLLEl-N64 to fix audio sync in Resident Evil 2 FMVs, fix Indiana Jones, fix missing sound in Episode 1 Pod Racer and to fix Perfect Dark when using the Angrylion or ParaLLEl renderers, among other fixes and cleanups. He also added a toggle for dithering with the Angrylion renderer, which can provide a cleaner image and also squeeze out a few more frames per second for users who were hovering around full speed with that highly accurate plugin. He also added a fix for Mario Kart 64 when using the Rice video plugin. Twinaphex also added very high internal resolution multipliers for cores that support it, including Dolphin Libretro, Beetle PSX HW, OpenLara Libretro, Craft libretro and Mupen64plus Libretro, and he updated OpenLara Libretro to have an inventory screen and a working healthbar.
  • oxavelar added 4-player controller support to the still-nascent Dolphin Libretro core.
  • Meepingsnesroms improved rotation functionality in Beetle WonderSwan Libretro and fixed the Amiga emulator core, (P-)UAE Libretro core on Android x86.
  • frranck tweaked the AI in MrBoom Libretro to make playing against computer opponents a better experience.
  • danieljg backported to our FBA2012 core a turbo speedhack for Metal Slug 2.
  • r-type updated MAME Libretro to stay in lockstep with upstream MAME, as well as adding a bunch of new resolutions to the “alt renderer” core option, which should allow for clean, anti-aliased vector graphics, as well as clean use of MAME’s artwork feature. r-type fixed an issue with the MAME Libretro core where some games could launch with incorrect framerates. He also added more target systems to his libretro port of Vice, along with a core option to choose different models of C64 and/or VIC20.
  • yoshisuga has added iOS-ARM64 build targets for many cores to make them compatible with newer Apple iDevices. He also helped track down and squash a longstanding bug that was causing a handful of cores to display only a black screen on iOS devices.
  • Tatsuya79 added support for Colecovision/Spectravideo/Sega SG1000 and an option to crop overscan to the blueMSX libretro core, along with fixing a variety of mapper issues in that core. He also added a core option to Beetle PCE Fast to allow users to choose which CD-ROM BIOS to use, as well as adding a bunch of new functionality for Prboom Libretro, including keyboard and mouse support and savegame slots.
  • Gingerbeardman made significant updates to the fMSX core.
  • hunterk backported some minor fixes from upstream Higan to our bsnes and bsnes-mercury cores to fix an elusive hanging issue in Magical Drop and audio issues with several games using the performance core. He also added a fix for Nestopia-UE‘s libretro interface that was preventing autoselection of the Japanese 4-player adapter when using the NstDatabase. hunterk also added core options to increase the internal resolution of the Vectrex emulator core, Vecx Libretro, which greatly reduces the ugly jaggies caused by 1x rendering.
  • barbudreadmon updated FBAlpha Libretro to the upstream v0.2.97.42 and fixed a segfault that could occur with some pgm games.
  • radius fixed savestates in FBAlpha Libretro and re-applied a fix to Mupen64plus Libretro for stuttering that some users experienced with games that run at 30 fps. He and webgeek also added AArch64 build support for various cores to coincide with the compatibility of RetroArch Android on that architexture.
  • sergiobenrocha2 and shakalakka provided more intuitive button layouts for the MAME2014-libretro and MAME2016-libretro cores. sergiobenrocha2 also merged in endrift’s upstream changes from mGBA v0.6.0.
  • kivutar made a lot of improvements to the lutro-platformer core, while RobLoach added Love support to it.
  • markwkidd did a variety of quality-of-life improvements for MAME2003-libretro, including adding a catver.ini file that helps with categories and fixing the Makefile to compile in the MIPS engine for x86, which should fix Killer Instinct on x86 (that is, KI is still broken on x86_64 and ARM) with this core. He also added DAT and catver.ini for MAME2000-libretro and submitted a fix from RetroPie user poi to MAME2010-libretro to fix Xevious and Bosconian.
  • TylerLoch (with some cleanup help from radius) added a SuperFX chip 20 MHz overclock option (i.e., instead of starting at 40 Mhz) for snes9x-libretro.
  • andwn fixed a silly issue with NXEngine libretro whereby during the last-boss fight with Misery, her sprite would change to that of a large block.
  • SpiralBrad backported from upstream the ability to automatically set the BIOS time in Beetle Saturn based on the host system’s clock, which is particularly useful for the real-time holiday functionality in Christmas NiGHTS.
  • j-selby continued improving the already impressively complete Citra Libretro port to include touchscreen emulation using the mouse and optional right analog stick among other improvements.
  • Retro-wertz added additional mappers to FCEUmm.

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.


Cores progress report – Catering to high-end desktops – Dolphin libretro core and others now supports resolutions of 8K and up!

Soul Calibur 2 running on the Dolphin core. Internal resolution is 12K, which gets downsampled to a 4K desktop resolution through Nvidia DSR.
Soul Calibur 2 running on the Dolphin core. Internal resolution is 12K, which gets downsampled to a 4K desktop resolution through Nvidia DSR.
Here at RetroArch/libretro, we have always insisted on catering to both the low-end as well as the high end. To further this purpose, we always make design considerations from this perspective, that whatever we do shouldn’t be at the cost of worse performance on lower specced hardware that we still support.

Newer generation emulators are increasingly catering to the high end and almost demand it by virtue of them being based on much more recent videogame systems. While testing RetroArch and various libretro cores on our new high-end Windows desktop PC, we noticed that we could really take things up a few notches to see what we could get out of the hardware.


While working on the Dolphin libretro core some more, we stumbled upon the issue that internal resolution increases were still not working properly. So while fixing that in the latest core, we felt that the default scaled resolution choices that Dolphin provides (up to 8x native resolution) weren’t really putting any stress on our Windows development box (a Core i7 7700K equipped with a Titan XP).

So, in the process we added some additional resolution options so you can get up to 12K. The highest possible resolution right now is 19x (12160×10032).

As for performance results, even at the highest 19x resolution, the average framerate was still around 81fps, although there were some frame drops here and there and I found it to be generally more safe to dial the internal resolution down to a more conservative 12x or 15x instead). 12x resolution would be 8680×6336, which is still well over 8K resolution.

Note that the screenshots here are compressed and they are downscaled to 4K resolution, which is my desktop resolution. This desktop resolution in turn is an Nvidia DSR custom resolution, so it effectively is a 4K resolution downsampled to my 1080p monitor. From that, I am running RetroArch with the Dolphin core. With RetroArch, downscaling is pretty much implicit and works on the fly, so through setting the internal resolution of the EFB framebuffer, I can go beyond 4K (unlike most games which just query the available desktop resolutions).

We ran some performance tests on Soul Calibur 2 with an uncapped framerate. Test box is a Core i7 7700k with 16GB of DDR4 3000MHz RAM, and an Nvidia Titan XP video card. We start out with the base 8x (slightly above 4K Ultra HD) resolution which is the highest integer scaled resolution that Dolphin usually supports. If you want to go beyond that on regular Dolphin, you have to input a custom resolution. Instead, we made the native resolution scales go all the way up to 19x.

On the Nvidia Control panel, nearly everything is maxed out – 8x anti-aliasing, MFAA, 16x Anisotropic filtering, FXAA, etc.

Resolution Performance (with OpenGL) Performance (with Vulkan)
8x (5120×4224) [for 5K] 166fps 192fps
9x (5760×4752) 165fps 192fps
10x (6400×5280) 164fps 196fps
11x (7040×5808) 163fps 197fps
12x (7680×6336) [for 8K] 161fps 193fps
13x (8320×6864) 155fps 193fps
14x (8960×7392) 152fps 193fps
15x (9600×7920) [for 9K] 139fps 193fps
16x (10240×8448) [for 10K] 126fps 172fps
17x (10880×8976) 115fps 152fps
18x (11520×9504) [for 12K] 102fps 137fps
19x (12160×10032) 93.4fps 123fps


OpenLara running at over 16K
OpenLara running at over 16K

The OpenLara core was previously capped at 1440p (2560×1440). We have added available resolutions now of up to 16K.

Resolution Performance
2560×1440 [for 1440p/2K] 642fps
3840×2160 [for 4K] 551fps
7680×4320 [for 8K] 407fps
15360×8640 [for 16K] 191fps
16000×9000 176fps


Craft core running at over 16K
Craft core running at over 16K

Previously, the Craft core supported only up to 1440p. Now it supports up to 16K and slightly higher.

For the Craft core, we are setting the ‘draw distance’ to 32, which is the highest available draw distance available to this core. With the draw distance set this far back, you can even see some pop-in right now (terrain that is not yet rendered and will only be rendered/shown when the viewer is closer in proximity to it).

Resolution Performance
2560×1600 [for 1440p/2K] 720fps
3840×2160 [for 4K] 646fps
7680×4320 [for 8K] 441fps
15360×8640 [for 16K] 190fps
16000×9000 168fps

Parallel N64 – Angrylion software renderer

This scene serves as our benchmark test for both the software Angrylion renderer as well as the Vulkan-based Parallel renderer.
This scene serves as our benchmark test for both the software Angrylion renderer as well as the Vulkan-based Parallel renderer.

So accurate software-based emulation of the N64 has remained an elusive pipe dream for decades. However, it seems things are finally changing now on high-end hardware.

This test was conducted on an Intel i7 7700K running at Boost Mode (4.80GHz). We are using both the OpenGL video driver and the Vulkan video driver for this test, and we are running the game Super Mario 64. The exact spot we are testing at it is at the Princess Peach castle courtyard.

Super Mario 64

Description Performance (with OpenGL) Performance (with Vulkan)
Angrylion [no VI filter] 73fps 75fps
Angrylion [with VI filter] 61fps 63fps

Quake 64

Description Performance (with OpenGL) Performance (with Vulkan)
Angrylion [no VI filter] 81fps 82.5fps
Angrylion [with VI filter] 68fps 72fps

Killer Instinct Gold

Description Performance (with OpenGL) Performance (with Vulkan)
Angrylion [no VI filter] 57.9fps 58.7fps
Angrylion [with VI filter] 54.6fps 55fps

GoldenEye 007

Tested at the Dam level – beginning

Description Performance (with OpenGL) Performance (with Vulkan)
Angrylion [no VI filter] 54.9fps 43.8fps
Angrylion [with VI filter] 45.6fps 40.9fps

Note that we are using the cxd4 RSP interpreter which, despite the SSE optimizations, would still be pretty slow compared to any RSP dynarec, so these results are impressive to say the least. There are games which dip more than this – for instance, Killer Instinct Gold can run at 48fps on the logo title screen, but on average, if you turn off VI filtering, most games should run at fullspeed with this configuration.

In case you didn’t notice already, Vulkan doesn’t really benefit us much when we do plain software rendering. We are talking maybe a conservative 3fps increase with VI filtering, and about 2fps or maybe even a bit less with VI turned off. Not much to brag about but it could help in case you barely get 60fps and you need a 2+ fps dip to avoid v-sync stutters.

Oddly enough, the sole exception to this is GoldenEye 007, where the tables are actually turned, and OpenGL actually leaps ahead of Vulkan quite significantly, conservatively by about 5fps with VI filter applied, and even higher with no VI filter. I tested this many times over to see if there was maybe a slight discrepancy going on, but I got the exact same results each and every time.

Parallel N64 – Parallel Vulkan renderer

Quake 64 on Parallel N64 - tested with both Angrylion and Parallel
Quake 64 on Parallel N64 – tested with both Angrylion and Parallel

So we have seen how software-based LLE RDP rendering runs. This puts all the workload on the CPU. So what if we reverse the situation and put it all on the GPU instead? That is essentially the promise of the Parallel Vulkan renderer. So let’s run the same tests on it.

This test was conducted on an Intel i7 7700K running at Boost Mode (4.80GHz). We are using the Vulkan video driver for this test, and we are running the game Super Mario 64. The exact spot we are testing at it is at the Princess Peach castle courtyard.

Super Mario 64

Description Performance
With synchronous RDP 192fps
Without synchronous RDP 222fps

Quake 64

Description Performance
With synchronous RDP 180fps
Without synchronous RDP 220fps

Killer Instinct Gold

Description Performance
With synchronous RDP 174fps
Without synchronous RDP 214fps

GoldenEye 007

Tested at the Dam level – beginning

Description Performance
With synchronous RDP 88fps
Without synchronous RDP 118fps

As you can see, performance nearly doubles when going from Angrylion to Parallel renderer with synchronous RDP enabled, and beyond with it disabled. Do note that asynchronous RDP is regarded as a hack and it can result in many framebuffer oriented glitches among other things, so it’s best to run with synchronous RDP for best results.

We are certain that by using the LLVM RSP dynarec, the performance difference between Angrylion and Parallel would widen even further. Even though there are still a few glitches and omissions in the Parallel renderer compared to Angrylion, it’s clear that there is a lot of promise to this approach of putting the RDP on the GPU.

Conclusion: It’s quite clear that even on a quad-core 4.8GHz i7 CPU, the CPU ‘nearly’ manages to run most games with Angrylion [software] at fullspeed but it doesn’t leave you with a lot of headroom really. Moving it to the GPU [through Parallel RDP] results in a doubling of performance with the conservative synchronous option enabled and even more if you decide to go with asynchronous mode (buggier but faster).

Beetle PSX

Previously, Beetle PSX would only provide internal resolution increases up to 8 times the original resolution. We have now extended this to 32 x for software and Vulkan, and 16x for OpenGL.

The results are surprising – while the Vulkan renderer is far more mature than the OpenGL renderer and implements the mask bit unlike the GL renderer (along with some other missing bits in the current GL renderer), the GL renderer leaps ahead in terms of performance at nearly every resolution.

Crash Bandicoot

Crash Bandicoot running at over 10K. Note this is being downsampled to 4K.
Crash Bandicoot running at over 10K. Note this is being downsampled to 4K.

Crash Bandicoot is a game that ran at a resolution of 512×240.

Resolution Performance (with OpenGL) [with PGXP] Performance (with OpenGL) [w/o PGXP] Performance (with Vulkan) [with PGXP] Performance (with Vulkan) [w/o PGXP] Performance (software OpenGL) Performance (software Vulkan)
8192×3840 [16x] [for 5K] 188.8fps 266fps 217fps 239fps 4.4fps 5.3fps
4096×1920 [8x] [for 2K] 216fps 296fps 218fps 240fps 16fps 17.5fps
2048×960 [4x] 215fps 296fps 216fps 239fps 52fps 57.9fps
1024×480 [2x] 216fps 296fps 216fps 239fps 138fps 145fps

Tekken 3

Tekken 3 running at over 10K, being downsampled to 4K.
Tekken 3 running at over 10K, being downsampled to 4K.

Tekken 3 is a game that ran at a resolution of 368×480.

Resolution Performance (with OpenGL) [with PGXP] Performance (with OpenGL) [w/o PGXP] Performance (with Vulkan) [with PGXP] Performance (with Vulkan) [w/o PGXP] Performance (software OpenGL) Performance (software Vulkan)
11776×15360 [32x] [for 12K] N/A N/A 127fps 127.4fps N/A N/A
5888×7680 [16x] [for 4K] 188.5fps 266fps 184.4fps 211fps 4.4fps 6.6fps
2944×3840 [8x] [for 2K] 186.5fps 208fps 183.5fps 269fps 22fps 25.2fps
1472×1920 [4x] 184.5fps 270fps 230.5fps 210fps 52fps 59.4fps
1024×480 [2x] 232fps 271fps 185.5fps 210fps 129fps 137fps


Dead or Alive 2 running at over 12K resolution on Reicast
Dead or Alive 2 running at over 12K resolution on Reicast

Daytona USA 2001 running at over 12K resolution on Reicast
Daytona USA 2001 running at over 12K resolution on Reicast

Sonic Adventure running at over 12K resolution on Reicast
Sonic Adventure running at over 12K resolution on Reicast

Dead or Alive 2

Description Performance
4480×3360 206fps
5120×3840 206fps
5760×4320 206fps
6400×4800 204fps
7040×5280 206fps
7680×5760 206fps
8320×6240 204fps
8960×6720 204fps
9600×7200 207fps
10240×7680 206fps
10880×8160 207fps
11520×8640 207fps
12160×9120 194fps
12800×9600 193fps

As you can see, it isn’t until we reach 12160×9120 that Reicast’s performance finally lets up from an almost consistent 206/207fps to a somewhat lower value. Do note that this was testing the same environment. When alpha effects and RTT (Render to Texture) effects are being applied onscreen, there may well be dips on the higher than 8K resolutions whereas 8K and below would be able to handle it with relative ease.

Mupen64plus – GlideN64 OpenGL renderer

Super Mario 64 running at 8K resolution with Gliden64.
Super Mario 64 running at 8K resolution with Gliden64.

This core uses Mupen64plus as the core emulator plus the GlideN64 OpenGL renderer.

Super Mario 64

Description Performance
3840×2880 – no MSAA 617fps
3840×2880 – 2x/4x MSAA 181fps
4160×3120 – no MSAA 568fps
4160×3120 – 2x/4x MSAA 112fps
4480×3360 – no MSAA 538fps
4480×3360 – 2x/4x MSAA 103fps
4800×3600 – no MSAA 524fps
4800×3600 – 2x/4x MSAA 94fps
5120×3840 – no MSAA 486fps
5120×3840 – 2x/4x MSAA 82fps
5440×4080 – no MSAA 199fps
5440×4080 – 2x/4x MSAA 80fps
5760×4320 – no MSAA 194fs
5760×4320 – 2x/4x MSAA 74fps
6080×4560 – no MSAA 190fps
6080×4560 – 2x/4x MSAA 68fps
6400×4800 – no MSAA 186fps
6400×4800 – 2x/4x MSAA 61.3fps
7680×4320 – no MSAA 183fps
7680×4320 – 2x/4x MSAA 39.4fps

GoldenEye 007

Tested at the Dam level – beginning

Description Performance
3840×2880 – no MSAA 406fps
3840×2880 – 2x/4x MSAA 100fps
4160×3120 – no MSAA 397fps
4160×3120 – 2x/4x MSAA 65fps
4480×3360 – no MSAA 375fps
4480×3360 – 2x/4x MSAA 60fps
4800×3600 – no MSAA 342fps
4800×3600 – 2x/4x MSAA 54fps
5120×3840 – no MSAA 310fps
5120×3840 – 2x/4x MSAA 51fps
5440×4080 – no MSAA 70fps
5440×4080 – 2x/4x MSAA 46fps
5760×4320 – no MSAA 78.9fs
5760×4320 – 2x/4x MSAA 42fps
6080×4560 – no MSAA 86fps
6080×4560 – 2x/4x MSAA 37fps
6400×4800 – no MSAA 79fps
6400×4800 – 2x/4x MSAA 27fps
7680×4320 – no MSAA 79fps
7680×4320 – 2x/4x MSAA 33.2fps

Preface: Immediately after going beyond 3840×2880 (the slightly-higher than 4K resolution), we notice that turning on MSAA results in several black solid colored strips being rendered where there should be textures and geometry. Again, we notice that enabling MSAA takes a huge performance hit. It doesn’t matter either if you apply 2 or 4 samples, it is uniformly slow. We also notice several rendering bottlenecks in throughput – as soon as we move from 5120×3840 to 5440×4080 (a relatively minor bump), we go from 310fps to suddenly 70fps – a huge dropoff point. Suffice to say, while you can play with Reicast (Dreamcast emulator) and Dolphin (Gamecube/Wii) at 8K without effort and even have enough headroom to go all the way to 12K, don’t try this anytime soon with Gliden64.

We suspect there are several huge bottlenecks in this renderer that prevent it from reaching higher performance, especially since people on 1060s have also complained about less than stellar performance. That being said, there are certain advantages to Gliden64 vs. Glide64, it emulates certain FBO effects which GLide64 doesn’t. It also is less accurate than Glide64 in other areas, so you have to pick your poison on a per-game basis.

We still believe that the future of N64 emulation relies more on accurate renderers like Parallel RDP which are not riddled with per-game hacks vs. the traditional HLE RDP approach as seen in Gliden64 and Glide64. Nevertheless, people love their internal resolution upscaling, so there will always exist a builtin audience for these renderers, and it’s always nice to be able to have choices.

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.