RetroArch 1.7.4 – Metal 2 macOS version available now!

RetroArch with Metal 2 support for macOS High Sierra users!

Up until now, we had three versions of RetroArch for macOS/OSX users:

  • RetroArch for OSX PowerPC (10.5) – For users with an old PowerMac or iBook/Powerbook. You should have at least Mac OS X version 10.5 (Leopard) installed in order for this version to work. Cores are packaged with this version because our buildbot does not serve fresh 32bit PowerPC cores for OSX.
  • RetroArch for OSX 32bit Intel (10.6) – For users with an old MacBook that has a 32bit Intel processor (for instance, 1st generation MacBook). In order to use this, you should have at least MacOS X version 10.6 (Snow Leopard) installed. Cores are packaged with this version because our buildbot does not serve fresh 32bit Intel cores for OSX.
  • RetroArch for macOS/OSX 64bit Intel (10.6) – This is what you are likely wanting to use on a modern Mac computer. You should have at least MacOS X/macOS version 10.7 (Lion) installed. Cores are distributed separately on our buildbot.

We are now adding a fourth one:

  • RetroArch for macOS 64bit Intel with Metal 2 support (10.13) – This version has all of the features of ‘RetroArch for macOS/OSX 64bit Intel’ plus a Metal 2 video driver. This version requires at least macOS 10.13 (High Sierra), a fairly modern version of macOS. For this version, we default to the Metal video driver by default.

If you have relatively modern Mac and you want to enjoy the latest in cutting edge technology, you should definitely try out this latest version. Get it by going to our Downloads page, and click on the download link below macOS High Sierra (or later).

Some important things you should know about Metal 2 – not all of the devices that can run macOS 10.13 necessarily support this. Here is a compatibility list of all supported hardware:

  • MacBook (Early 2015 or newer)
  • MacBook Pro (Mid 2012 or newer)
  • MacBook Air (Mid 2012 or newer)
  • Mac mini (Late 2012 or newer)
  • iMac (Late 2012 or newer)
  • Mac Pro (Late 2013)

What is Metal, and why is it relevant?

Up until the ’10s, Mac OS X has relied on the crossplatform OpenGL API to provide hardware accelerated rendering to developers writing Mac applications. However, since 2014, there has been an industry-wide push towards lower-level APIs, and Apple in specific decided to go with its own proprietary graphics API. This API is called Metal, and was first premiered with iOS 7 and Apple A7 devices. It has since some years ago made the switch to macOS as well, and this year the API has been bumped to version 2.

Apple has announced OpenGL will be deprecated in the future, its graphics driver stuck with the dated OpenGL 4.1 spec for years now. While we regret this industry wide push away from a standardized, cross-platform graphics API, we have been forced to move with the times and instead cater to all the major graphics APIs. There is no longer the potential for one single graphics API to cater to all platforms.

With the release of RetroArch 1.7.4, we have achieved an important milestone: we now have fully functioning graphics drivers for the three major next-generation graphics APIs. This includes Khronos’ Vulkan API (added to RetroArch since 2016), Microsoft’s Direct3D 11/12 (added to RetroArch since earlier this year), and now Apple’s Metal 2 for macOS. Thanks to Hans-Kristian Arntzen’s SPIRV-Cross middleware, we can reuse the same shaders across Direct3D/Vulkan/Metal. We therefore are very close to having a universal shader specification that will work on all the major platforms.

We are now ready for a future when Apple will outright kill OpenGL support, while at the same time we have ensured that we have one common set of shaders that can be used across all these video drivers. The developer who has added Metal 2 support to RetroArch has already indicated he intends to bring this over to iOS and tvOS as well. And who knows, maybe even backwards compatibility with Metal 1 could arrive.

How complete is the Metal video driver right now?

Fairly complete. You get:

  • Fully functioning menu drivers. XMB, MaterialUI and RGUI should work fine.
  • XMB shader pipeline effect should work as expected.
  • You can take screenshots.
  • You can go into fullscreen mode.
  • You can use slang shaders with the Metal video driver, the same shaders that can be used with Vulkan/D3D10/D3D11/D3D12.

Things that have still yet to be added which the author is considering adding:

  • Recording support independent of ffmpeg.
  • Support for the libretro API’s RETRO_ENVIRONMENT_GET_CURRENT_SOFTWARE_FRAMEBUFFER.
  • Hardware renderer context support, so that libretro cores could make use of the Metal API.

General changelog

– COMMON: Support for “OEM-102” key (usually ‘\’ on Euro keyboards).
– MENU/QT/WIMP: Add option to filter extensions inside archives when adding to a playlist.
– METAL: Add screenshot support.

Beetle PSX HW PSA for Windows/AMD GPU users – update your drivers!

Written by rz5

From at least February to mid August there was a bug on beetle-psx’s GL renderer that only affected users with AMD GPUs.

This bug was exposed when user ‘orbea’ corrected a mistake in glsm (an OpenGL state manager, made by libretro, used in beetle-psx), where it would it would hint that beetle-psx wanted a version 3.1 core profile OpenGL rendering context but, by specification, the ‘core profile’ is only from version 3.2 onward.

It is still unknown why, but after orbea’s patch, AMD GPUs would render black frames on every situation except for FMVs.
Intel and Nvidia GPUs were unaffected.
Trying to find out what was wrong was very frustrating. CodeXL and RenderDoc were briefly used in the expectation that they would point out obvious API mistakes or perform API call order analysis and give a warning e.g. “are you sure you want to change this complex colored frame for a single-colored frame and present it?”

It is unfortunate that sometimes bugs like this pop up and due to the blackbox nature of closed-source proprietary drivers, using a debugger like gdb becomes unfruitful for hobby developers when you arive at the point where your opensource the code starts calling into driver code.
Then one begins to wonder: was it one of my commits in the past? Is our code going against the OpenGL spec in some way that triggers this behavior on the typically strict spec-following AMD drivers? Is it our fault at all?

And while this bug was active, users affected by it surely grew frustrated at the lack of progress and some even got dissuaded from using beetle-psx altogether.

Eventually, in mid August, update 18.8.1 came out for AMD’s Radeon Software graphics software and that seemingly fixed the bug. Which seems to indicate towards the problem being on the AMD driver side, not in beetle-psx.

Introducing Reicast OIT libretro core + updated Reicast regular core

The Reicast libretro core has seen several big improvements as of late, and we thought it would be remiss of us if we did not take this opportunity to talk about it.

There are two cores now

There are now two Reicast cores:

  • Reicast regular
  • Reicast OIT

Reicast regular: Contains an OpenGL renderer that requires OpenGL 2.x on the desktop and GLES 2.x on mobile.

Reicast OIT: Contains an OpenGL renderer that requires OpenGL 4.3, and as a result is only available for Windows and Linux. Reicast OIT might have significantly increased system requirements, but in return you get much more accurate graphics which tend to fix nearly all the issues that plague Dreamcast graphics with the regular version.

How to get it

In RetroArch, go to Online Updater -> Update Cores. From there, Reicast and Reicast OIT should be available for the following platforms:

  • Linux
  • Windows
  • Mac (Reicast OIT is not available for Mac due to no GL 4.3 support)

What is new/improved in both Reicast versions?

Reicast regular

Reicast regular’s OpenGL renderer has received many improvements that greatly increases the graphics accuracy and squashes many graphics bugs that plagued games in the past.

Here are some of the Dreamcast’s GPU features that are now implemented:

  • Tile clipping support.
  • Fogging support.
  • Volume modifier shadow support.
  • Multipass rendering.
  • Render to texture buffer.
  • Log 2 depth buffer.

Some additional enhancements include a log 2 depth buffer, fixing much of the polygon glitching that could happen in the distant background in many games.

All of these additions to the existing GL2 renderer in Reicast regular come courtesy of flyinghead.

Reicast OIT

Reicast OIT uses an entirely new graphics renderer written by flyinghead targeting OpenGL 4.3. In addition to boasting all the features that Reicast regular also enjoys as of this date, it also has the additional advantage of incorporating Order Independent Transparency, so that we don’t have to do hacky and error prone alpha sorting hacks, which is our main resort in Reicast regular.

  • Tile clipping support.
  • Fogging support.
  • Volume modifier shadow support.
  • Multipass rendering.
  • Render to texture buffer.
  • Log 2 depth buffer.
  • Order independent transparency.
  • Two-volume mode support.

NOTE: This requires a compatibility context for OpenGL 4.3. You might encounter issues with Intel/AMD GPUs right now on Linux using Mesa drivers since they require core context. Core context cannot currently be used becasue there are still graphic bugs to be solved when using this.

Showcase of new emulated features

Flyinghead has a terrific fork of Reicast that dramatically increased the rendering accuracy of Reicast’s OpenGL renderer. We backported these features with the gracious help of flyinghead. All kudos goes to him.

Tile clipping support


The Dreamcast’s PVR2 had a tile clipping GPU feature that was used to obscure portions of the screen. It was cheaper to keep rendering portions of the screen that were not meant to be seen by the user and just clip them away instead of deciding not to render them at all. This was previously unimplemented, which led to all sorts of graphics glitches. This has now been finally implemented in both cores.

Fogging support


The Dreamcast had a 128-bit fogging table that games could take advantage of. Plenty did, such as Cannon Spike, Blue Stinger, Resident Evil: Code Veronica, Virtua Fighter 3tb, and more games. This is now finally implemented for both cores.

Volume modifier shadow support


The Dreamcast made use of volume modifiers in order to simulate shadows in many games. This was previously either completely unimplemented or very buggily rendered. Volume modifiers are now correctly implemented in both cores (Reicast and Reicast OIT). Performance costs should be minimal and you definitely notice the shadows being cast now by characters and other objects.

Multipass rendering


The game V-Rally 2 relies on multipass rendering for rendering the UI elements on top of the game screen. This has finally been emulated on both cores (Reicast and Reicast OIT).

Render to texture buffer


Not only has render to texture being reimplemented (leading to much faster performance), but certain games such as Tony Hawk’s Pro Skater 1/2 would render to VRAM for rendering shadows. The upshot of this is that the shadow looks much more convincing vs. merely using volume modifiers in order to simulate shadows. This feature has been finally implemented in both cores.

Log 2 depth buffer


Thanks to the logarithmic depth buffer, many rendering bugs have been fixed. Some games have been completely fixed as a result, such as Cannon Spike, while others such as Soul Calibur no longer have the scenery in the background glitch out.

Note that this relies on gl_FragDepth being available. This might become an issue when we bring the Reicast libretro core to mobile, since it’s not a part of the GLES2 spec and might require either extensions or GLES3 support.

Order Independent Transparency

NOTE: This feature is exclusive to Reicast OIT, and is not available in the regular Reicast core.


Other improvements

Date/time saving is finally fixed


Finally you don’t have to keep inputting date/time again whenever starting a game with the Reicast cores.

Be sure to set a correct date/time, as entering a wrong date might lead to it not being able to save.

Analog triggers

The core finally supports analog triggers. The Dreamcast had analog L/R triggers, previously we only had digital trigger simulation, where the L1/R1 would simulate 50% press of the trigger and L2/R2 would be a 100% press of the trigger. While this mode is still available if you enable the option ‘Digital Triggers’, you can also now just take advantage of the new digital trigger capabilities.

In addition to this ,deadzone issues should be fixed now, so there should hopefully be no more analog input disparities between Xbox pads and PS4 pads.

Videos