RetroArch 1.6.0 – Released!

Libretro Team

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

Libretro Team

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.