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.

Dolphin

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

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

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 OpenGL 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 at fullspeed but it doesn’t leave you with a lot of headroom really. Moving it to the GPU alone 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).

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 ‘dolphin-data.zip’.

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

Controls

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!

Implemented

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.

Unimplemented

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

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

Note on maintenance

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

New core: OpenLara (Windows/Linux)

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

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

Available for

The OpenLara core is currently available for:

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

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

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

How to get it

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

Important!

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

How to turn on shared hardware context (required)

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

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

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

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

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

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

How to use it

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

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

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

How to use the demo

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

  • Go to Online Updater -> Content Downloader.

  • Go to ‘Tomb Raider’, and select the file ‘tombraider1-demo.zip’.

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

 

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

Controls

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

L2 – Sidestep left

R2 – Sidestep right

R1 – Hold to walk

Y button – Jump

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

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

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

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

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

Enhancements

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

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

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

Extra features

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

Unimplemented

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

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

Still coming up!

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

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

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

New core: Redream (Windows/Linux)

Redream is now available as a libretro core! This is a new Sega Dreamcast emulator by developer inolen and is already progressing rapidly.

If you’d like to know more about the project, please visit its site here. Please try to support inolen’s efforts! Open-source Dreamcast emulation still leaves much to be desired, and this project is one of the most promising ones to date that is actively worked on.

Available for

The Redream core is currently available for:

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

Further requirements: This core requires OpenGL 3.3 or higher in order to work. If your GPU driver doesn’t support that, you’re out of luck unfortunately.

Note for macOS users: There is currently no ‘working’ macOS version available. This is because this core requires OpenGL core 3.3 context, and RetroArch on macOS currently does not support this. We will have to add support for this to a future version of RetroArch on macOS before this core will start to work on it. 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 ‘Sega Dreamcast (Redream)’ from the list.

BIOS instructions, etc. (highly recommended)

Redream can use either a real BIOS boot ROM, or a high-level emulated version that has been baked-in to the emulator. We highly recommend you use a real BIOS for the best overall compatibility. These need to be placed inside your System directory. If you don’t know where your System directory is, inside RetroArch, go to Settings -> Directories and read where your System Directory is located.

Create a directory called ‘dc’ inside your system directory. Inside it, you should put the following files:

  • boot.bin / dc_boot.bin
  • flash.bin / dc_flash.bin

You can tell that Redream has used the real BIOS if you see the Dreamcast logo swirl at the beginning. If you don’t see this, it means that it’s using the HLE BIOS. Compatibility will be far lower then.

Important!

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

 

Tempering expectations

Please note that Redream, like its subtitle itself states, is a ‘work-in-progress Dreamcast emulator’. Don’t expect it to be better right now than Reicast. There will be sound issues, general compatibility issues, and a general rougher experience right now than say Reicast.

However, what is important is that inolen is rapidly making progress on this emulator, whereas Reicast’s development has stood still for years. For that reason alone, it should be heavily supported.

Other notes:

  • Redream right now has experimental CDI image support. However, many CDI images that run on Reicast might not run yet on Redream. GDI images should work fine however though.

Unimplemented

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

  • Save states are not implemented. And savestates don’t seem to be implemented in upstream either, so not much that can be done about it at this stage.

Still coming up!

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

  • OpenLara (open-source Tomb Raider game engine clone, work-in-progress)
  • Dolphin (Gamecube/Wii emulator, with Gamecube-only controls at first)

Stay tuned!

New Core: Citra (Windows/Linux)

Citra is now available as a libretro core! This port was made singlehandedly by developer j-selby and is already at a pretty impressive state of development.

This is an in-development Nintendo 3DS emulator.

Available for

The Citra core is currently available for:

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

Further requirements: This core requires OpenGL 3.3 or higher in order to work. If your GPU driver doesn’t support that, you’re out of luck unfortunately.

Note for macOS users: There is currently no ‘working’ macOS version available. This is because this core requires OpenGL core 3.3 context, and RetroArch on macOS currently does not support this. We will have to add support for this to a future version of RetroArch on macOS before this core will start to work on it. 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.

In addition to this, Citra also demands right now a shared hardware context so that fullscreen toggling works reliably. This is another feature missing right now on RetroArch macOS, and will require additional time.

How to get it

  1. Start RetroArch.
  2. Go to Online Updater -> Update Cores.
  3. Download ‘Nintendo 3DS (Citra)’ from the list.

Important!

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

  • You need to turn on ‘Enable Shared Hardware Context’ so that fullscreen toggling will work properly.

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.

Unimplemented

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

  • Save states are not implemented. And savestates don’t seem to be implemented in upstream either, so not much that can be done about it.
  • Touchscreen / mouse support is very premature so far and does not really work well. This will be fixed later; some kind of onscreen cursor should have to be shown as well in non-windowed mode.

Still coming up!

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

  • Redream (new Sega Dreamcast emulator)
  • OpenLara (open-source Tomb Raider game engine clone, work-in-progress)
  • Dolphin (Gamecube/Wii emulator, with Gamecube-only controls at first)

Stay tuned!

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

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

MelonDS

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

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

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

Available for

The MelonDS core is currently available for:

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

BIOS instructions, etc. (required)

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

The following three files are all required:

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

 

SameBoy

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

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

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

Available for

The SameBoy core is currently available for:

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

BIOS instructions, etc. (optional)

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

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

Game Boy boot ROM – ‘dmg_boot.bin’

Game Boy Color boot ROM – ‘cgb_boot.bin’

ARM Linux cores!

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

You can grab them here:

https://buildbot.libretro.com/nightly/linux/armhf/latest/

Miscellaneous updates

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

What’s still coming up this week?

In no particular order:

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

RetroArch 1.6.0 – Released!

RetroArch 1.6.0 has just been released!

Get it here.

PS3 port

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

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

PowerPC OSX port

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

Wii port

The Wii port has received stability fixes amongst other things.

WiiU port

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

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

PS Vita port

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

Windows version improvements

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

Vulkan renderer

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

Localization

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

Audio mixer

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

Currently, there are a couple of limitations here –

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

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

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

Here is a quick demonstration of how you use it:

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

Changelog

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

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

New Lakka 2.1 RC release!

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

Please read more about it here.

Important shader-related changes

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

Upcoming events

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

SDL Libretro Proof of Concept

The larger design goal behind Libretro is to make programs modular. To us, modularity means that a program should run from within the confines of a dynamic library, and that it should be possible for this program to then run inside any of the libretro-compatible players that exist out there.

In order to make a libretro core as it stands right now, you need to be familiar with how the API works. There is some obligatory documentation available for this purpose but we understand that API familiarity is still not where it should be, and that to some developers out there looking to get started with libretro, it might be intimidating to get started.

To that end, we are searching for ways to ease the difficulty and learning curve that comes with getting to grips with Libretro. We know that SDL for instance is already heavily used out there by game developers and emulator creators alike.

SDL and libretro cannot reasonably be compared. The entire purpose behind Libretro is to make a cohesive, consistent ecosystem of modular programs that, like a plugin, can be inserted into any frontend player that supports our API. Something like SDL is more generic in that it doesn’t really care what your program is going to be; it just acts as convenient middleware for your program so that you don’t have to write against a myriad of programming APIs across all the various platforms. And while libretro allows for something of that nature too, it does so with distinct design goals in mind that are more or less forced on you for the purpose of a better play experience.

SDL Libretro

SDL Libretro is a project that was started out by me half a year ago. Back then it was more or less in an unusable state. To date, I had ported a couple of SDL programs already to libretro (like NXEngine), but previously I always did so by manually baking in parts of SDL and then shoehorning the runloop such that it would fit inside libretro. A libretro core’s runloop consists of a ‘lifebeat’ that lasts for exactly one frame, which can pose a problem for many SDL programs, because how the programmer implements the runloop there is entirely up to the programmer, whereas libretro forces this runloop model on you. It does this for good reasons, so that the frontend can easily do advanced operations like fast forwarding, rewinding, etc. But nevertheless, if you have an existing program, it might take time to whip it into shap such that it fits the confines of a libretro program.

Developer r-type has done an awesome job of making SDL Libretro finally a viable project. Right now it exists as a Proof of Concept that works on both Linux and Windows, and to illustrate that it works, r-type has made available three Proof of Concepts to show off SDL Libretro:

  • An OpenTyrian SDL port
  • A Mandelbrot game port (using SDL)
  • A Tetris game port (using SDL)

Right now, this SDL port is obviously in its infancy, and this might be an area where we could make use of further contributions.

To go over some of these:

  • Because an SDL program can be implemented any number of ways, right now we have to rely on libco in order to implement the main runloop.
  • Right now we are targeting SDL 1.2.15. There are currently no plans for SDL 2 support, although if we do, it’s likely it would be a separate project.
  • Lastly, be cognizant of the fact that when we say ‘Proof of concept’, we really mean it. Things are not perfect yet and it will take some time to iron out all of the bugs.

To use libretro SDL in conjunction with your game program, right now you would first build the SDL libretro part. You run the Makefile and once successful, it will create a statically linked ‘archive’ (such as ‘libSDL_unix.a’ and/or ‘libSDL_win.a’). From there, you would manually link this archive into your libretro core. That way, your libretro program can interface against SDL.

If you want to see some test examples of how this is done in practice, go to the directory ‘tests‘. ‘opentyrian’, ‘sdl-mandelbrot’ and ‘sdl-tetris’ are three current proof of concepts.

What does this mean for endusers?

It means that developers familiar with SDL have an easier time getting themselves acquainted with libretro. It also will mean that we can get SDL ports up and running quicker instead of having to reimplement and rewrite everything from scratch.

Right now, my current plan is to take the quick and dirty OpenTyrian port, and divorce it from most of its SDL idiosynchrasies and turn it into a nice, native, fleshed out libretro core. However, at the same time, I also want to help improve, build and foster further work going into libretro SDL. So if anything, we need to strive for even more well fleshed-out tests at the same time.

Credit to r-type

We want to thank r-type a lot for coming up with this wonderful Proof-of-Concept. Without him, this project would have barely stumbled out of the gates and it would have taken many more months for it to end up running anything. Hopefully we can once return the favor for all the hard work and effort guys like this have provided to our project. It’s the passion and the commitment of most of the followers surrounding this project that keeps us going.

RetroArch 1.5.0 – Released!

RetroArch 1.5.0 has just been released!

Where to get it?

You can get the latest version here.

On Android, you can expect version 1.5.0 to be downloadable on the Google Play Store later today. If you want to install the APK manually, you can do so by downloading it from the URL linked to above.

Changes since last version (1.4.1)

  • MOBILE: Single-tap for menu entry selection
  • MOBILE: Long-tap a setting to reset to default
  • ANDROID: Autoconf fallback
  • ANDROID: Mouse support / Emulated mouse support
  • AUTOCONF: Fix partial matches for pad name
  • CHEEVOS: Fix crashes in the cheevos description menu
  • CHEEVOS: WIP leaderboards support
  • COMMON: Threading fixes
  • COMMON: 9-slice texture drawing support
  • CORETEXT/APPLE: Ability to load menu display font drivers and loading of custom font.
  • DOS: Add keyboard driver
  • DOS: Improve color accuracy and scaling
  • GUI: Various settings are now only visible when advanced settings is enabled
  • GUI: Allow changing icon theme on the fly
  • GUI: Add a symbol page in the OSK (Onscreen Keyboard)
  • GUI: Better dialogs for XMB
  • LOCALIZATION: Add/update Korean translation
  • LOCALIZATION: Rewrite German translation
  • LOCALIZATION: Update several English sublabels
  • LOCALIZATION: Update several Japanese labels
  • NET: Allow manual netplay content loading
  • NET: Announcing network games to the public lobby is optional now
  • NET: Bake in miniupnpc
  • NET: Fix netplay join for contentless cores
  • NET: LAN games show next to lobbies with (LAN) and connect via the private IP address
  • NET: Use new lobby system with MITM (Man In The Middle) support
  • NET: Fix netplay rooms being pushed on the wrong tab
  • NUKLEAR: Update to current version
  • SCANNER: Always add 7z & zip to supported extensions
  • VULKAN: Find supported composite alpha in swapchain
  • VULKAN: Add snow/bokeh shader pipeline effects – at parity with GL now
  • WIIU: Keyboard support
  • WINDOWS: Logging to file no longer spawns an empty window
  • WINDOWS: Fix loading of core/content via file menu

We’ll go into some of the important features in more detail below.

UPNP support out of the box! (Windows/MacOS/Linux/Android/iOS)

Previously, in order for netplay to work, you as the hoster would need to manually port forward on your router. Starting with version 1.5.0, RetroArch now supports UPNP out of the box! If you have a home network router that supports UPNP, you should now be able to host netplay games without having to manually open ports on your router!

NOTE: The platforms that come with UPNP support out of the box as of this point includes: Android, MacOS, Linux, iOS, and Windows. If you have a version of RetroArch for any other platform, it’s likely it does not have UPNP support, and therefore you would still need to fallback on manual port forwarding if you want to host a game.

Menu improvements

An often-heard complaint was that touch navigation on mobile devices was not intuitive enough. You had to double tap in order to select an entry instead of being able to single tap which is the norm for most mobile programs out there.

We have changed this so that you now only have to single tap. Also, you can now ‘long-tap’ a setting in order to ‘reset’ it to default. This is useful in case you are tinkering with some setting using touch and you want to set it back to its default setting.

Other new features – changing the icon theme now works on-the-fly, so you no longer need to restart RetroArch for these changes to take effect.

Android controller detection improvements

If RetroArch cannot find a preconfigured entry for your gamepad on Android, it will now try to use the Android standard default controls for the gamepad instead. This should help with a bunch of gamepads that are lacking a current autoconfiguration file, and should prevent the user from having to manually setup the controls.

Vulkan improvements

Previously, the menu effects ‘Snow’ and ‘Bokeh’ were not available if you were running RetroArch with the Vulkan video driver enabled. Now you can use them with Vulkan as well!

In case you don’t know how to access these, go to Settings -> User Interface -> Menu -> Menu Shader Pipeline.