RetroArch 1.8.0 released!

RetroArch 1.8.0 has just been released. The default mobile UI has seen a complete overhaul and we hope this will address many of the usability issues people had with RetroArch’s menu on Android/iOS. Note that we are far from done and that the next versions will have even more enhancements coming up!

In addition to the MaterialUI menu improvements, we now have MAME overlay compatibility for the OpenGL driver, seamless driver switching, and more!

Grab it here.

If you’d like to show your support, consider donating to us. Check here in order to learn more. In addition to being able to support us on Patreon, there is now also the option to sponsor us on Github Sponsors! You can also help us out by buying some of our merch on our Teespring store!

Big features

Complete overhaul of MaterialUI – UX for Android/iOS massively improved!

With version 1.7.9, we already improved the mobile UX significantly by adding touchscreen gestures and better touch responsiveness.

This however pales in comparison to what has been done for version 1.8.0 in this department. We will quickly go over the major highlights, most of the text here has been written by jdgleaver (the author of these changes) with only minimal edits by myself –

New menu scaling

At present, Material UI is scaled according to screen resolution and hard-coded magic numbers. This ‘kinda-sorta’ works on some mobile devices, but in general (and specifically on desktop computers and tablets) the interface is too large, and scaling is highly inconsistent when resizing windows. To combat these inadequacies, there existed a ‘DPI override’ feature which allowed the user to set a specific scale – but this didn’t work in real-time (so adjustments were blind), and it’s not user friendly (since the average user can’t be expected to know the correct DPI setting for their screen).

This new version modifies the scaling of Material UI such that it uses the hardware-reported DPI value of the display, with empirical adjustments to accommodate very large and very small screen sizes (where normal DPI scaling fails). This should ensure an appropriate default interface size regardless of hardware. Moreover, it removes the ‘DPI override’ and replaces it with a generic Menu Scale Factor under User Interface > Appearance, which is a simple fractional multiplier (much easier for the user to understand!). This Menu Scale Factor is now also used by XMB (instead of the previous XMB-specific scale factor) – it is intended that Ozone and menu widgets will obey this setting in the future.

  • DPI Override Removed – Menu Scale Factor comes in its place – starts out at 1.00x and can be made smaller or higher than the default value
  • Material UI now correctly readjusts its layout when screen orientation changes on mobile devices
  • Material UI now resizes in real-time when the user manually sets the Menu Scale Factor (this never worked properly with the old DPI override)
  • Material UI no longer leaks memory on ‘context reset’

Menu animations

A new ‘Menu Transition Animation’ option has been added under User Interface > Appearance. When this is enabled, menu transition events are animated.

All sorts of animations have been added – fade-in effects, slide effects, etc. If you dislike any of these, you can always turn the setting off completely to go back to the previous behavior.

System bar

A new Android-style ‘system bar’ has been added. This shows current core name, clock and battery level.

Navigation bar

The navigation bar is now shown at all times – i.e. it is an actual navigation tool, rather than a ‘top-level-menu’ curiosity.

Two new context-sensitive buttons have been added:

On the bottom left we have a ‘back’ button. This performs the same function as tapping the menu bar, but the button is in a more ergonomic/standard position. This should address most of the complaints Android users have about RetroArch ignoring the hardware back button.

On the bottom right we have a ‘resume content’ button. This means we can easily change/test runtime settings without performing finger gymnastics. e.g. we can change a core option or apply a shader and immediately toggle the menu off without having to hit back to get to the quick menu, and scroll up to the resume content entry.


A new ‘Auto-Rotate Navigation Bar’ option has been added under User Interface > Appearance. When enabled (this is the default setting), the navigation bar is moved to the right hand side of the screen when using landscape screen orientations. It looks something like this:

If you don’t like this and you want it to always appear at the bottom of the screen, turn this option off.

Title bar

The title bar now uses a larger font, and the sublabel font has also been enlarged a little, to more closely align with Material Design standards.

Optimize Landscape Layout

A new Optimize Landscape Layout option has been added under User Interface > Appearance. This is intended to address the rather uncomfortable appearance of Materail UI in landscape orientation on wide displays (particularly on the desktop). The option is disabled by default on mobile platforms (like iOS/Android), and enabled by default everywhere else. When enabled, it looks something like this:

Graceful switching between video drivers

Graceful switching between video drivers has been added for Linux and Windows PCs thanks to Rinnegatamante (Patreon here). This feature originated as a bounty request, and it’s on the verge of being completed.

RetroArch in the past behaved unpredictably and unstably when switching to cores that wanted a context other than what was currently active. This could happen because of video_driver settings being different in a core config override or because a core’s core options were telling it to use a different renderer than what was active (e.g., GL vs Vulkan)

What happens now, is that RetroArch can seamlessly switch video drivers if a core requires it.

Example –

one of the new cores we have added over the past few weeks, VitaQuake 2, is a core that has two renderers. It has a software renderer and an OpenGL 1.x renderer. Say that RetroArch is running with the ‘vulkan’ video driver. We want to load VitaQuake 2.

What would happen with RetroArch 1.7.9

  • The renderer of VitaQuake 2 has two options – Software and OpenGL. Because there is no hardware context in the core for Vulkan, it would switch to Software.

What happens now with RetroArch 1.8.0 (with driver switching enabled)

  • The renderer of VitaQuake 2 has two options – Software and OpenGL. We make the assumption that you wouldn’t want to use the software renderer if OpenGL is available, so instead, RetroArch will seamlessly switch to OpenGL. When you unload the core/game, it will switch back to ‘vulkan’, so the driver switch will not be written to the config file.

What if you still want to use the Software renderer with a core like this with Vulkan?
That is certainly possible. To do this, we need to turn off the ‘driver switching’ feature. First, you need to make sure that ‘Show Advanced Settings’ is enabled under ‘User Interface’ settings. Once you have made sure of that, go to ‘Settings -> Core’. Then turn off ‘Allow cores to switch the video driver’. It should now behave like before again.

What if a core has several hardware context renderers? (like Dolphin/PPSSPP)
Cores like Dolphin and PPSSPP have several renderers available, such as OpenGL, Direct3D11 and Vulkan. Say you have RetroArch running with the vulkan driver. It would then naturally pick the ‘Vulkan’ renderer. Ditto for OpenGL and Direct3D11. So nothing changed there in that regard.

What is this particularly useful for?
The big issue with using the Vulkan video driver in RetroArch in the past (or Direct3D 11) is that while some software rendered cores might run faster with these drivers vs. OpenGL, there are plenty of Libretro cores that require the use of OpenGL. With this new feature, it will properly fallback to OpenGL for these exclusive cores but still use Direct3D 11 or Vulkan for all other cores. You can get the best of both worlds this way.

MAME layout compatibility with OpenGL driver

This started as a bounty request, and it has now been implemented at least for the regular OpenGL driver.

If you don’t know what MAME layout files are, you can read this here.

How to get this working?

First, ensure that you are using the OpenGL driver. NOTE: Make sure this is ‘gl’ driver, ‘glcore’ will not work right now but might work in a future version. Only the regular ‘gl’ driver right now will work with MAME layouts.

  • Find a layout bundle, like these:
  • Go to Settings > Onscreen Display > Video Layout and set ‘Enable Video Layout’ to ON, then use the ‘Video Layout Path’ option to navigate to your layout bundle.

NOTE: It’s only available for the GL driver right now, but we would like to extend it to other drivers in the future. Automatic loading of layouts based on content filename would also be a good improvement.



  • AI SERVICE: Added in fix for BMP returns to AI service. Added in label passing to AI service call
  • BSV: Fix BSV recording/playback
  • BUGFIX: Fix crash when setting Thumbnail Directory
  • BUGFIX/STABILITY: Set “Automatically Add Content to Playlist” to false by default, this was unstable on PS3 and Mac and other platforms potentially as well.
  • COMMON: Graceful driver switching for Windows and Linux
  • COMMON: Cache frame before converting 0RGB1555
  • LAKKA: Wi-Fi Access Point settings
  • MENU: Menu scaling improvements
  • MENU/MATERIALUI: There are no longer any animation glitches when ‘wraparound’ scrolling from the last entry in a list to the first, or when performing horizontal swipe navigation gestures on certain settings-type entries
  • MENU/MATERIALUI: List entries underneath the title and navigation bars are no longer highlighted when touching the title/navigation bars (this was only a cosmetic issue, but it was annoying…)
  • MENU/MATERIALUI: The current menu list is no longer reloaded when pressing the currently active tab on the navigation bar
  • MENU/MATERIALUI: The ticker text spacer has been set to a ‘bullet’ character (same as Ozone)
  • MENU/MATERIALUI: The default colour theme has been set to ‘Ozone Dark’
  • MENU/MATERIALUI: Three new colour themes have been added.
  • MENU/MATERIALUI: A new Menu Transition Animation option has been added under User Interface > Appearance. When this is enabled, menu transition events are animated
  • MENU/MATERIALUI: The navigation bar is now shown at all times – i.e. it is an actual navigation tool, rather than a ‘top-level-menu’ curiosity
  • MENU/MATERIALUI: Two new context-sensitive buttons have been added to the navigation bar – back button and resume button
  • MENU/MATERIALUI: A new Auto-Rotate Navigation Bar option has been added under User Interface > Appearance. When enabled (this is the default setting), the navigation bar is moved to the right hand side of the screen when using landscape screen orientations
  • MENU/MATERIALUI: The playlists tab is now correctly hidden when User Interface > Views > Show Playlist Tabs is disabled
  • MENU/MATERIALUI: Material UI now correctly readjusts its layout when screen orientation changes on mobile devices
  • MENU/MATERIALUI: Material UI now resizes in real-time when the user manually sets the Menu Scale Factor (this never worked properly with the old DPI override)
  • MENU/MATERIALUI: Material UI no longer leaks memory on ‘context reset’ (fonts were previously never free()’d)
  • MENU/MATERIALUI: A new Android-style ‘system bar’ has been added. This shows current core name, clock and battery level
  • MENU/MATERIALUI: A new search icon is shown on the title bar when viewing playlists and file browser lists. Pressing this launches the search interface
  • MENU/MATERIALUI: The title bar now uses a larger font, and the sublabel font has also been enlarged a little, to more closely align with Material UI standards
  • MENU/MATERIALUI: A number (quite a large number) of layout/spacing issues have been fixed
  • MENU/MATERIALUI: The existing colour theme handling code is not fit for purpose, so the whole lot got ripped out and reimplemented. In doing so, also adjusted all the theme colours to better match Material UI standards – with a few liberties taken for aesthetic purposes.
  • OSD: Fix fast forward indicator when not using menu widgets
  • PSP1: Remove duplicated FPS indicator on the screen
  • LIBNX/SWITCH: Make audren threaded audio driver the new default
  • VIDEO LAYOUT: Add video layout MAME overlay compatibility. Enabled for Windows/Linux/OSX/iOS/Android/libnx. Only works with GL driver for now, no glcore yet

RetroArch Overlay Editor – Create and edit your own overlays easily – now available for free!

Article written by meepingsnesroms

Download here –

Since RetroArch was first running on touchscreen devices, it has been dependent on overlays for onscreen controls. But there has been no good way of editing them, for the last 6 years the only way to make overlays was to edit numbers in a text file, see if they looked good and if they didn’t edit them again until they did, I found this to be quite bizarre and when I made the Palm device overlay for Mu and I made a small buggy overlay editor with an incomprehesible fixed function GUI, it was a project I tried to make in a week as a challenge to myself and as a tool to make the Palm overlay because there was no way I would have the patience to edit the text file that many times.

At first I though no one really cared about it because whenever anyone talked about overlays it was just a border around the game screen and RetroArch wanted an excessive amount of work converting all the GUI files into text by hand, although recently I have gotten slightly bored with Palm stuff and someone was making an overlay and my editor was mentioned, since someone actually wanted an overlay editor I decided that it was worth it to finish it and make it user friendly so anyone can make a good RetroArch overlay.

There is no current plan to integrate the code with RetroArch itself but the source code will run on Windows, Mac and Linux and I will maintain a Win32 binary that can be run on all Windows versions and emulated elsewhere.

Here is a video of its current functionality, more will be added to allow easily making animated overlays from pictures and allowing advanced users to edit the text file directly for things that don’t have a GUI option.

It is in beta right now. If you choose to use it, submit all issues to not the RetroArch repo.

vitaQuake II Libretro core WIP available right now on Windows/Mac/Linux! Plus high refresh rate support in libretro core games

We’ve always felt at libretro that RetroArch is a platform that is agnostic to emulators. That is, the libretro API is not in any way tied to emulators and allows for far more applications to be ported beyond just emulators. So it’s always a delight to us when game engines get ported as libretro cores to add to the growing pool of non-emulator libretro cores. So it was music to our ears when the talented PS Vita homebrew coder Rinnegatamante graced us with a new libretro core – vitaQuake II! This is a port of a Quake II engine source port that he made originally for the PS Vita.

With this core, you will be able to play Quake II on RetroArch (or any libretro-compatible program for that matter).

YouTube videos coming later today showcasing the game running at both 60Hz and 120Hz!

Where to get it and for what platforms

The core is available right now on our buildbot. It will be only available for Windows PCs, Mac and Linux for now given the OpenGL fixed function requirements right now. We will see where we can go from here.

To install this core, in RetroArch’s Main Menu, go to Online Updater. First make sure your core info files are updated. Select ‘Update Core Info Files’.

After this is done, select ‘Core Updater’. From here, you can select ‘Quake 2 (vitaQuake 2)’ from the list and download it.

How to start Quake 2

You need to load Quake 2’s PAK0.PAK. This is usually found inside the Quake 2 directory’s ‘baseq2’ directory. Both the shareware version and the full version should work fine.


It’s a very early version, and some bugs will still exist. Some examples:

  • If you want this to run with the regular gl driver, “Shared Hardware Context” needs to be enabled in Settings -> Core (you might need to enable Show Advanced Settings first in Settings -> User Appearance). The glcore driver on the other hand does not require you to enable this in order for the game to work as normal.
  • A savefile bug where after having selected New Game for the first time, starting it again after closing vitaQuake 2 for the first time will start you off at the beginning with all enemies already killed and the elevator button missing. In case this happens, you then need to go to the directory where your Quake 2 datafiles are, and manually delete the baseq2/save directory contents. Obviously this is very inconvenient and not at all intentional, so hopefully we can fix this soon.
  • After about 5/7 minutes, there might be a big freeze that can last for 5 seconds, after which the game will resume again. Obviously very nonideal and something we want to fix ASAP.

Technical details

Let us discuss some of the intricacies of this port:

  • Quake II dates back to an era where 3D graphics APIs and 3D video cards in general were truly in their infancy. Quake II makes use of a very limited subset of OpenGL 1.x. To complicate matters, right now the renderer is using some OpenGL 2.x functions as well such as glGetTexImage. We’ll have to see where we go from here – mobile would need a renderer that is at least compatible with GLES2, which means making use of non-fixed function vertex and pixel shaders, while on the other hand we can see an exclusively OpenGL 1.x renderer being very useful for low end hardware such as the 3DS, PS Vita and PSP – all these platforms have an OpenGL 1.x wrapper to some degree that translates back to their native graphics APIs. Frangarcj and Rinnegatamante are discussing possibly adding an OpenGL 1.x hardware context to the libretro API that would make it possible to target these platforms. So perhaps the future of this port is multiple renderers so that we can cast a wide net in terms of compatibility.

    Long story short – for now, this renderer is making use of fixed function GL, so you’ll need to be on a desktop computer to run this for now.

  • The glcore video driver will run this core right now without having to enable ‘Shared Hardware Context’. To get it to run with the regular gl driver, you will need to enable ‘Shared Hardware Context’ inside Settings -> Core. You might need to enable ‘Advanced Settings’ first in Settings -> User Interface before this shows up.
  • The libretro core has been changed slightly from the original so that the Quake II frame logic operates in fixed timesteps. In normal Quake 2 ports, this is usually done with a timer which acts as the framerate limiter. In libretro instead, we can guarantee that each retro_run iteration is exactly one frame, so all we have to do is pass the exact timestep delta for the framerate we are to target to Qcommon_frame. This gives us a silky smooth framerate with minimal frametime deviations. This might complicate matters in terms of existing Quake 2 server compatibility, but we kinda figure that it’s not worth it having suboptimal performance and that the existing Quake 2 server pool is very limited anyway and that it has its own drawbacks in terms of performance as it stands (with hard caps on framerate – most servers cap at 60-70 fps).
  • Quake II in general seems to have a default framerate cap of 90fps. We want to make as many libretro game engine cores suitable for high refresh rate gaming as possible, so we’ve gotten rid of this cap. We’ve tested the game to be running flawlessly at 100Hz and 120Hz.
  • The UI in Quake II normally doesn’t scale, so at higher resolutions it would appear very small. Because it’s 2019 and not a lot of people play their games at 640×480 anymore, there is now UI scaling implemented so that the UI text popups will be readable at 1080p and beyond.
  • Rumble has been implemented and is available as a core option, just like it was in the PS Vita standalone version.

High refresh rate gaming with libretro/RetroArch

There has been an increased focus on making sure libretro game cores are all they can be when it comes to supporting higher refresh rates. So far we have already had the following libretro game cores that can run at higher framerates (>60fps):

  • Prboom (Doom 1/2 game engine core)
  • Cannonball (Outrun game engine core)
  • OpenLara (Tomb Raider game engine core)
  • Tyrquake (Quake 1 game engine core) (NEW)
  • vitaQuake2 (Quake 2 game engine core) (NEW)

Tyrquake and vita Quake2 are two recent additions to this list. In order to get them to run without audio crackling at higher refresh rates, we had to change the audio samplerate from 44Khz to 48Khz, which seemed to do the trick.

To further increase the convenience factor, we’ve also implemented a nifty feature in these libretro cores: support for libretro’s ‘preferred refresh rate’ option. Basically, if you leave the ‘Framerate’ option at ‘Auto’, the libretro core will look at RetroArch’s configured ‘refresh rate’, and it will use this for the framerate. This means that inside RetroArch, you can switch to a 1440p 120Hz mode with the Resolution setting, then start the core, and without having to configure the framerate, it will then run the game at 120fps. Likewise, if you then switch to a 4K resolution at 60Hz, and close and reload the Quake core, the game will automatically run at 60fps instead. So, with cores that support the ‘RETRO_ENVIRONMENT_GET_TARGET_REFRESH_RATE’ environment callback, you don’t have to keep switching back and forth between separate framerates inside the core – you can simply leave it at ‘Auto’ and RetroArch will do the rest.

This feature has not been added yet for OpenLara and Prboom, but we’ll do so soon.