By Squarepusher – This will be more like a development diary to document the continuining development of RetroArch and all things related to libretro.

Desmume libretro

Meancoot made a libretro port of Desmume last week. There are currently some talks between me and zeromus to get this port merged into Desmume mainline. I’ll try to get this done ASAP.

Desmume is a Nintendo DS emulator.
Link to repository:  https://github.com/libretro/desmume-libretro

FCEUmm libretro

The libretro port has recently been adopted by FCEUmm author Ca4e3.

FCEUmm is a Nintendo Entertainment System /Nintendo Famicom emulator. This fork of FCEU focuses on experimental mapper compatibility among other things.

Link to repository: http://fceumm.svn.sourceforge.net/viewvc/fceumm/.

I will continue to update both our own repo on Github as well as submit patches back to mainline whenever a change has been made to the libretro API that affects the port.

TGB Dual

Also done by an external party, lifning (who also takes credit for the RetroArch Pandora port) spent some time making a libretro port of TGB Dual last week.

TGB Dual is a Game Boy / Game Boy Color emulator with one unique feature – it allows you to play Game Link-compatible games in two-player splitscreen mode. This works by using the Sufami Turbo API functions in libretro where two cartridges have to be loaded one after another (one each for each player with his own Gameboy).

Note that Sufami Turbo loading functionality is not yet in the RetroArch console ports and will need to be added later by me.

Link to repository: https://github.com/libretro/tgbdual-libretro

In many ways this is the release that the original should have been. We have been working non-stop for the past week to iron out most of the major complaints and we believe this is a much more well-rounded package now.

New key features (0.9.8.1)

• Higher-resolution overlays (old ones are still available for older devices)
• Now compatible with Android 2.3+
• Fixed Wonderswan core (Mednafen Wonderswan)
• Numerous PCSX ReARMed improvements (PAL games should be fixed and emulator should now work on devices that didn’t work before)
• Custom input mapping
• Numerous pads added to autodetection list (see below).

Downloads

Google Play – https://play.google.com/store/apps/details?id=org.retroarch

APK Link (r8) – https://anonfiles.com/file/0afb3a1b35c4280139a6fcb24742ecc1

Screenshots

Videos

Changelog

r8 (Jan 30, 2013) – VERSION 0.9.8.1
———————————————————–
* Is now compatible with Android version 2.3 and up.
* Back button issues with certain gamepads should now be fixed.
* Wonderswan core was broken (Mednafen Wonderswan) – is now fixed.
* ‘Detect’ button for manual input binding for touchless devices.
* Old overlays are back and put into a directory called ‘Low-resolution’ for devices with slower CPUs –
the higher-resolution ones are somewhat more demanding than the original 256×256 ones.
* Input autodetection expanded –
– DragonRise USB Gamepad

r7
—
Test that was released on certain forums – never pushed to Play Store.

r6 (Jan 29, 2013)
————————–
* PlayStation1 [PCSX ReARMed] core fixes (from notaz)
– Fixes 50Hz PAL games (were running with sound being too fast and other irregularities before)
– Should fix emu crashing on some devices due to memory mapping issues.
* New system-specific overlays added – on new installs only these new ones will be there and the old bad ones will no longer be there. On pre-existing installs – just use the new ones – they should be much better. If you’re still unsatisfied, nothing is stopping you from editing these files yourself with a text editor and an image editor – it’s really simple to do.
* New ‘custom binding’ when you turn off ‘Configuration Autodetect Enable’ – allows you to manually put in button mapping in case we don’t support your pad. Note – it’s probably more reliable right now to select the ‘keycode’ from the dropdown list instead of pressing the button on the pad.
– Input autodetection expanded –
– Trust Raptor
– Should fix Logitech F710/Elecom/RetroUSB NES/etc

r5 (Jan 28, 2013)
————————–
* Input autodetection expanded
– Archos gamepad
– Xperia Play
– Xbox 1 (Titanium X-JoyConverter)
– Xbox 360 (wired)
– Red Samurai Bluetooth
– Another variant of Mayflash Wii Classic
– RetroUSB SNES RetroPort
– RetroUSB NES RetroPad
– Buffalo SNES Pad
– Logicool F710 (Japanese Logitech F710)
– Elecom PS1/PS2 to USB

r4 (Jan 27, 2013)
————————–
* Input autodetection expanded
– Nyko Playpad Pro
* Fixed bug where device name would not be onscreen for long enough –
useful for reporting input name

r3 (Jan 26, 2013)
————————–
* More user-friendly core selection names
* Input autodetection expanded
– Added Mayflash Super Joy Box 3 Pro
– Added JXD S5110
– Added Logitech Dual Action
– Added Snakebyte idroid

It’s almost time for a new release of RetroArch, and there a number of big changes coming up. First of all, RetroArch 0.9.9 will mark the release of RetroArch on iOS and Blackberry 10/Playbook Tablet OS. These ports were made possible with the help of CatalystG and meancoot, respectively – for which many thanks. The iOS port will be released on Cydia and on our forum. It is possible to run it on a non-jailbroken device – but it will require that you are able to code-sign yourself (ie. if you are a registered Apple developer with the ability to code sign).

PCSX ReARMed on iOS

For iOS, perhaps the single biggest hurdle was getting PCSX-ReARMed working, which required notaz to rewrite much of the assembly code to work with Apple’s ancient GAS assembler version (big thanks to him for that!). With that completed, this should be the first time PCSX ReARMed will appear on iOS – through RetroArch.

RGUI

Elsewhere, Themaister and Squarepusher have been toiling away at a million other features, including the promotion of RGUI to a robust and feature-filled in-game menu system for the platforms that otherwise lacked such a thing, particularly the PC platform (i.e., Windows, Mac OS X and Linux). From its humble beginnings with the Gamecube/Wii port, RGUI now provides a way to change emulation cores, swap out ROMs, configure shaders and more, all without leaving the fullscreen gaming interface:

Cave Story (NXEngine)

ToadKing and Squarepusher have also done some work on ‘uncrippling’ Cave Story (ie. NXEngine). Previously, the file I/O would make it unbearably slow on consoles. This has mostly been fixed now that everything is pre-cached into RAM at initial startup. There are still some incidental dips to 59.50fps and 59.2fps, though, which causes some sound stuttering. The cause of these dips is still unknown but we feel that–compared to before–NXEngine can be safely released on consoles now without being an utter embarrassment. “Xbox 1/360 will require some further patching up of the codebase because NX Engine did some global symbol table trickery and the MSVC linkers have the (oh so ‘smart’) tendency to ‘strip away’ unreferenced symbols as an ‘optimization feature’ with no way to stop it from doing that (even /ref:noopt doesn’t help there),” Squarepusher noted.

TyrQuake

The port of TyrQuake will also be bundled with RetroArch 0.9.9. A lot of work went into making it work on Xbox 1 and Xbox 360 – including making the C99 codebase cross-compilable as C++98 and (for Xbox 1) resorting to a hacked-up template ‘typeof’ implementation (ye, don’t ask) for MSVC 2003. “I also threw in some additional ‘hackish’ features like ‘dither filtering’ (borrowed it from some guy that implemented it earlier) – this more or less looks like the Unreal 1 software renderer’s ‘bilinear filtering’ implementation,” Squarepusher said. “There is also a third-person chase cam view and a way to ‘lerp’ the animations (ie. add key-frame interpolation in order to make the animation of enemy models look smoother and have more frames of animation than they originally did).”

“I plan to eventually rebase the TyrQuake port and push it upstream to the original authors (ie. the maintainers of TyrQuake) – I did a lot of careless code rewriting that I’ll be sure to avoid for the rebase,” he added.

Shaders

There has been a major overhaul of the way shaders are handled, which has paved the way for advanced, multipass shaders that can be easily setup by end users without needing to tinker with any code. As part of these changes, the old XML/GLSL shaders with fixed-pipeline functions have been deprecated, but will still work just fine. In the future, we ask that interested shader authors try to stick to the multiplatform Cg format when possible. The GLSL/GLES formats will still be supported for compatibility with platforms that don’t support Nvidia’s Cg Toolkit, such as Android and iOS, and Cg shaders can be converted to these legacy formats programmatically using Themaister’s cg2glsl python script.

A couple of examples of newly written shaders that utilize some of the recently added features are Themaister’s NTSC Composite shader, which should work well on any libretro core, and Harlequin’s Gameboy shader:

There is no firm release date for v0.9.9, but if you would like to try any of these features out or get involved in the development, you can grab the code from git and compile it yourself for your platform of choice. If you have any questions about these features or RetroArch/libretro in general, stop by the libretro forums or drop by #retroarch on Freenode IRC.

Discuss this post

RetroArch v0.9.9 has officially been rolled out on all platform targets.

The new platforms that are supported with this release of RetroArch are as follows:

• iOS (both jailbroken and non-jailbroken – non-jailbroken requires that you are a registered developer and can compile your own copy of RetroArch + cores)
• Blackberry 10
• Blackberry Playbook Tablet OS

The other platforms which are already supported by the RetroArch/libretro projects have all received updates (with some pretty extensive changes – more on that in an upcoming blog post).

WHERE TO GET IT

Windows: New users can download 32- and 64-bit flavors of RetroArch and RetroArch-Phoenix from Themaister’s site:

http://themaister.net/retroarch.html

Existing users can/should download the new version through RetroArch-Phoenix’s built-in ‘RetroArch Updater’ utility. (this is the preferred update method for existing users to save massive bandwidth!)

Mac OS X users can download hunterk’s builds from this post on the libretro forum:

http://forum.themaister.net/viewtopic.php?pid=459#p459

Debian/Ubuntu/Mint users can add hunterk’s Launchpad PPA repository to their Synaptic/apt sources:

https://launchpad.net/~hunter-kaller/+archive/ppa

iOS users can find RetroArch iOS in one of Cydia’s default repositories – ZodTTD & MacCiti.

You can also add our own Cydia repository in order to get it, located at:

http://themaister.net/cydia

Most cores will work with both tethered and untethered jailbreaks, but cores that require the use of a dynamic recompiler (dynarec; DeSmuME and PCSX-ReARMed) will require a full, untethered jailbreak to function.

Android users can get the latest version from the Google Play Store. Xperia play controls seem to be wonky, but we hope to have that fixed very soon.

Wii users should use this package:

https://anonfiles.com/file/4536ac12f0071a397b2f1d70672814cf

Blackberry Playbook users should use this package:

http://themaister.net/retroarch-dl/blackberry/playbook/RetroArch-1_0_0_1.bar

Blackberry 10 users should use this package:

http://themaister.net/retroarch-dl/blackberry/bb10/RetroArch-Cascades-1_0_0_1.bar

PS3 users can get the DEX and CEX versions from the usual sources.

Xbox1 and Xbox360 users can get their respective versions from the usual sources.

OpenPandora users can get builds from lifning’s repo:

http://repo.openpandora.org/?page=detail&app=retroarch.lifning.001

Craft

We have decided to port over a promising Minecraft clone to the libretro API. The original source repository can be found here, and the libretro repository can be found here.

Windows/Linux/OSX users can already download this core by going to the Core Updater and downloading ‘Craft’. You can directly start the core since it requires no content to be loaded, it can be started as-is without needing any ROM or content file.

The original Craft upstream repository was a bit barebones, so we have decided to expand this port:

• Biomes were added (these were located on a branch that was never merged into master), this adds hills / fortresses as can be seen in the screenshot
• Water was added (this was located on a branch, never merged into master).
• More sophisticated sunrise/sunset color blending (from Konstrukts).
• A ‘Jumping Flash’ mode that allows you to jump infinitely into the air all while the camera faces downwards.
• Configurable draw distance. The draw distance has a big effect on the framerate, a draw distance of 1 or 2 can make this core playable even on very lightweight computers.
• Configurable field of view.
• Gamepad support (including analog stick support) configurable analog sensitivity and deadzones, preliminary mouse and keyboard support.
• Configurable resolutions, up to 4K.
• A lot of changes under the hood, some of them which are detailed in the Making Of Article.

Some things have been stubbed out so far such as the libcurl support which is required for the login authentication system to work. Network support will undoubtedly become a priority in the upcoming weeks as we plan to flesh out the main game’s content.

So far, one user has reported that he has gotten it to work on a Raspberry Pi although there are still some graphics glitches. It does not work so far on Android/iOS, and we are eagerly intending to fix that as soon as possible.

Expect to see big changes for this core. It’s currently  very bare bones but it won’t be for long.

Rustation

This is an up-and-coming Sony PlayStation emulator made by simias (Lionel Flandrin). The libretro repository can be found here, and the upstream repository here.

Rustation requires OpenGL and has been written entirely in Rust instead of C/C++. It interfaces with the libretro API through Rust bindings that have been written some time ago by an external contributor.

Mednafen/Beetle PSX

Mednafen/Beetle PSX has been a libretro core for quite some time now. As a direct result of the work that has gone into Rustation in recent weeks, simias has backported a considerable number of enhancements to the Mednafen/Beetle PSX core.

These include:

CPU Overclocking – Turning this core option on will eliminate drastic framerate drops in many games without any perceivable side-effects. Plenty of PlayStation games struggled to maintain a consistent framerate, Tomb Raider for instance would often drop down to 20fps and even the low teens in certain scenes. Other examples include Castlevania: Symphony Of The Night: after beating a boss, a spot effect would bring the framerate to its knees for around 4 to 5 seconds.

Resolution upscaling – Mednafen/Beetle PSX is no longer limited to native resolution but can now  be upscaled to 2x , 4x or 8x its original size. This greatly enhances the quality of the graphics at the cost of performance (and some minor graphics glitches when going above 2x). The graphics are still software-rendered.

Dithering – Dithering would be used by Nintendo 64 and/or PlayStation games to simulate higher color depth at the side effect of having some dithering patterns which a CRT TV would smooth over anyway and make nearly imperceptible. The alternative would have been color banding which would have been worse and definitely noticeable. However, dithering is a little more noticeable now on high definition screens than it ever was on a CRT. Dithering is now configurable, it can be turned off, left to its original native scale or upscaled depending on the upscaled resolution (if going above 1x).

This is not all that simias has brought to the table though. The next feature is not yet ready but it will be a definite game changer once a little further along:

Upcoming – OpenGL rendering

Right now work is underway on an OpenGL renderer for Mednafen/Beetle PSX. Essentially this is Rustation’s renderer made to work as a video plugin for Mednafen/Beetle PSX. This is mutually beneficial for both the Rustation and Mednafen PSX project this way, the Rustation graphics renderer can be battle tested against a more mature emulator and Mednafen/Beetle PSX in turn is finally no longer limited to slow software rendering.

Some work-in-progress screenshots. Do note that many things are still missing, you might be able to tell some of them in the current screenshots (missing blending for some textures, no sprites/lines being sent yet to the external renderer, etc.)

PCem

This is a new core that is still a work-in-progress but is steadily coming along together with the help of MoochMcGee. It is a libretro port of PCem, a PC emulator that some could consider a rival to Dosbox.

In terms of features, it supports a large variety of graphics, sound cards and BIOS / machine models. It is also unique in that it has 3Dfx Voodoo support. There is also preliminary nVidia Riva 128/TNT emulation that might be further fleshed out.

Together with an x86/x64 dynarec, it has been possible to play Pentium/Windows 9x-era games with 3Dfx Voodoo support at playable framerates.

Right now, this core is not yet ready but is making considerable strides. Video is now working, the runloop is more or less implemented, all that remains is adding all the remaining options and improving keyboard/mouse support.

GameGirl

This is not a libretro core project but a hardware project. Jean-Andre Santoni (Lakka head developer) and engineer David Perrenoud have created an open-spec portable handheld console called the ‘GameGirl’.

Please check it out and like it .

It consists of a 120Hz 320×240 display connected to a Raspberry Pi Zero.

Its main distinguishing points are:

• Uses the Lakka distribution (and therefore by all accounts is a RetroArch/Libretro handheld portable game console)
• Thin and tiny (only 66 mm x 99 mm)
• Very inexpensive
• Ability to shutdown at any time because of the Lakka distribution (it has a read-only filesystem which allows the user to turn off the device at any one time without the risk of corrupting the filesystem)
• Future prototyps will include a thin-film rechargeable battery and a proper speaker (current prototypes will have a buzzer
• An inexpensive and convenient portable solution for Lutro-based games (Love2D based games) and the Craft Minecraft core is an enticing offer.

By liking the project on Hackaday, you can help along its funding.

We are going to be making Libretro (and RetroArch, by extension) more usable for content creators, and the first part in that endeavor is the official launch of Lutro.

Lutro is an in-development Love 2D reimplementation written in Lua and implemented as a libretro core. With Lutro, it is possible to easily create Lua games with no knowledge of C being necessary, or having to compile any code.

Sample games

To demonstrate the flexibility and power of Lutro, we have assembled a few Lutro-based games which you can freely download from our server. They are purposefully kept simple so that the content creator can use them for their own attempts at creating a game.

LutroPong

A recreation of the game Pong for Lutro.

Sienna

This is a Love2D-based endless runner game that has been ported to Lutro.

Platformer

One of kivutar’s first proof of concept demos showing off Lutro. It’s a scrolling 2D platform game with no real game mechanics beyond jumping.

LutroSpaceship

Another 2D platformer showcase example for Lutro, this time illustrating how a Metroidvania-style game could work as a Lutro game. It has several screens which were implemented and some game mechanics including combat, item collecting, jumping, etc.

The Game Of Life

A recreation of Conway’s The Game Of Life. Press one of the buttons to regenerate the algorithm again. Can be quite CPU intensive depending on the system and environment you run Lutro on and/or whether or not LuaJIT is available.

Tetris

A recreation of Tetris for Lutro.

How to use the existing Lutro games

Start up RetroArch (version 1.3.6 or later).

Make sure you have downloaded the Lutro core first. To do that, do the following:

Downloading the Lutro core

1. Go to ‘Online Updater’.

2. Go to ‘Core Updater’.

3. Browse through the list and select ‘Lutro’. This will download the core. Once done, exit this screen and go back to the main menu by pressing the back button.

Downloading a game

There are several games we allow you to download from our servers.

1. Go to ‘Add Content’.

2. Go to ‘Download Content’.

3. Select the folder ‘lutro’.

4. Download any of the games. Once you’re done, press the back button or another key to go back to the main menu.

5. Go to ‘Load Content’.

6. Go to ‘Select Downloaded File and Detect Core’.

7. Go to the lutro directory.

8. Select the subdir of the Lutro game you want to play.

9. Select ‘main.lua’, and the game will start up.

Case study example : LutroSpaceship

In order to show off how Lutro could be used to create a good 2D game, kivutar has created a Metroidvania-style platformer game. It’s called ‘LutroSpaceship’. In it, you are thrown into a 2D Metroidvania style world with multiple screens you can explore. You can swing your lightsword to kill enemies. Enemies will drop collectibles that you can pick up. There are several traps you will have to avoid such as a laser beam. The game ends once you have reached a passageway.

As a budding content creator, you can pick up where we left off in this demo and continue the game from there. All it takes is some familiarity with how Love2D-based games work, a text editor and editing the Lua source files. After having edited these files, you can run the game again and immediately sample your changes.

Work in progress

Be aware that Lutro right now is not feature-complete with Love2D.

• There are several missing API functions that still have to be implemented. View the list here. We will keep this updated as we go along.
• We are in the process of adding an audio mixer to Lutro to complete some of the remaining missing Love2D functionality.
• Right now, there is no hardware rendering acceleration, everything is done mainly on the framebuffer. This would not be ideal for games that rely heavily on 3D-based rendering or transformation/scaling but it does have the advantage that the Lutro core/games can run on systems where there is no OpenGL support to begin with.

RetroArch keeps moving forward, being the reference frontend for libretro and all. Here comes version 1.3.6, and once again we have a lot to talk about.

Where to get it

Windows/Mac/iOS (build only)/Nintendo/PlayStation – Get it here.

Android: You can either get it from F-Droid or from Google Play Store.

Linux: Since RetroArch is included now on most mainline Linux distributions’ package management repository systems, we expect their versions to be updated to 1.3.6 shortly.

I will release versions for MacOSX PowerPC (10.5 Leopard) and 32-bit Intel MacOS X 10.6 (Snow Leopard) later on, maybe today or tomorrow.

Usability improvements

Windows Drag and Drop support

Courtesy of mudlord, with the Windows version, you can now drag and drop a ROM (or any other content) onto RetroArch’s window, and it will attempt to load the correct core for it. If there is more than one core available for the type of content you dragged and dropped, it will present you with a slidedown list of cores to select from.

Vastly improved content downloading features

Starting with v1.3.6, RetroArch users can download compatible freeware content, such as the shareware release of Doom, right from the app. This video goes through the steps, which include fetching the core from the online updater, fetching the content from the repository and then launching the core and content we just downloaded.

Menu customization and aesthetics – XMB and MaterialUI

RetroArch v1.3.6 adds support for a number of themes in the default mobile menu, including both bright and dark themes.

There’s also the ability now to set a custom wallpaper in XMB and be able to colorize it with a color gradient. To do this, you go to Settings -> Menu, you set a wallpaper, and from there you have to set ‘Menu Shader Pipeline’ to OFF. You can then choose from one of the color palettes in ‘Color Theme’ in order to shade the background wallpaper, or just select ‘Plain’ in case you don’t want to colorize it.

Undo Load/Save State

Have you ever gotten through a tough part of a game and wanted to make a savestate only to hit the “load state” button instead and have to do it all over again? Or maybe you were practicing a particularly difficult maneuver–for a speedrun, perhaps–and accidentally saved a bad run over your practice point because you hit “save state” instead of “load state”? While savestates are considered one of the great advantages to emulating retro games, they can also lead to these frustrating situations where they wipe out progress instead of saving it, all because of one slip of the finger. RetroArch now has the ability to undo a save- or load-state action through some automatic state-shuffling that happens behind the scenes, so you never have to worry about these situations again.

Undo Load State – Before the ‘current’ state is altered by e.g. a ‘Load Savestate’ operation, ‘current’ is saved in memory and ‘Undo Load State’ restores it; you can also undo this option by using it again, which will make you flip-flop between 2 states.

Undo Save State – If there was a savestate file that was overwritten, this option restores it.

New Features

The main event of RetroArch 1.3.6 is obviously the fact that it makes it possible to run the N64 Vulkan core, paraLLEl. Previous versions of RetroArch will not be able to run this because of the new extensions to libretro Vulkan which we had to push to make this renderer possible.

Vulkan

Async compute core support – ready for ParaLLEl

It was already possible to run Vulkan-enabled libretro cores, but with this release, a few crucial features have been added. Support for queue transfers was added and a context negotiation interface was added.

With this we can now use multiple queues to overlap compute and shading in the frontend level, i.e. asynchronous compute. ParaLLEl would certainly not have been as fast or as effective were it not for this.

ParaLLEl now joins triple-A games like Rise of the Tomb Raider and Doom in heavily relying on Vulkan’s async compute capabilities for maximum efficiency. A test core was also written as a proof of concept for this interface.

If you want to read more about ParaLLEl, we have a compendium blog post for you to digest here.

Supports Windows, Linux, Android equally well now

The previous version already had Vulkan support to varying degrees, but now we feel we are finally at the point where Vulkan driver support in RetroArch is very much mature across most of the supported platforms.

Vulkan should work now on Android, on Windows, and on Linux, provided your GPU has a working Vulkan driver.

On Linux we now support even more video driver context features, such as VK_KHR_display support. This is a platform-agnostic KMS-like backend for Vulkan, which should allow you to run RetroArch with Vulkan without the need of an X11 or Wayland server running.

On Windows and Android, we include Vulkan support now. Vulkan has been tested on Android with NVIDIA Shield Tablet/Console, and both work. Be aware that there are some minuscule things which might not work correctly yet with Vulkan on Android. For instance, orientation changing still doesn’t work. This will be investigated.

Max swapchain images – driving latency even lower with Vulkan and friends

RetroArch already has built up quite a reputation for itself for being able to drive latency down to very low levels. But with new technologies, there is always room for improvement.

Max amount of swapchain images has now been implemented for both the DRM/KMS context driver for OpenGL (usable on Linux) and Vulkan now. What this entails, is that you can programmatically tell your video card to provide you with either triple buffering (3), double buffering (2) or single buffering (1). The previous default with DRM/KMS was 3 (triple buffering), so setting it to 2 could potentially shave off latency by at least 1 frame (as was verified by others). Setting to 1 won’t often get you single buffering with most monitors and drivers due to tearing and they will fall-back to (2) double buffering.

With Vulkan, RetroArch can programmatically infer to the video card what kind of buffering method it likes to be able to use, a vast improvement over the nonexistent options that existed before with OpenGL (from a platform-agnostic perspective).

What Vulkan brings to the table on Android

Vulkan has been tested to run on Android devices that support Vulkan, like Shield Tablet/Console. Latency has always been very bad on Android in the past. With Vulkan, frame times are significantly lower than with OpenGL, and we no longer have to leave Threaded Video enabled by default. Instead, we can turn off Threaded Video and letting RetroArch monitor the refresh rate dynamically, which is the more desirable solution since it allows for less jittery screen updates.

Audio latency can also be driven down significantly now with Vulkan. The current default is 128ms, with Vulkan we can drive it down to 64 or even 32ms.

Couple this with the aforementioned swapchain images support and there are multiple ways to drive latency down on Android now.

OpenGL music visualizer (for FFmpeg-enabled builds)

Versions of RetroArch like the Linux and Windows port happen to feature built-in integrated FFmpeg support, which allows you to watch movies and listen to music from within the confines of RetroArch.

We have added a music visualizer now. The scene is drawn as a cylindrical mesh with FFT (Fast Fourier Transform) heightmap lookups. Different colors are shaded using mid/side channels as well as left/right information for height.

Note that this requires at least GLES3 support (which is available as well through an extension which most GPUs should support by now).

Improvements to cores

TyrQuake

User leileilol contributed a very cool feature to TyrQuake, Quake 64-style RGB colored lighting, except done in software.

To be able to use this feature, you need to create a subdir in your Quake data directory called ‘maps’, and you need to move ‘.lit’ files to this directory. These are the lighting map files that the Tyrquake core will use in order to determine how light should be positioned.

From there on out, you load up the Tyrquake core, you go to Quick Menu -> Options, you enable Colored Lighting. Restart the core and if your files are placed correctly, you should now see the difference.

Be aware that in order to do this, the game renderer shifts to 24bit color RGB rendering, and this in turn makes things significantly slower, although it should still be fairly playable even at higher resolutions.

View the image gallery here.

To download this, go to ‘Add Content’ -> ‘Download Content’. Go to ‘Tyrquake’, and download ‘quake-colored-lighting-pack.zip’. This should extract this zip to your Downloads dir, and inside the Quake directory. From there, you can just load Quake and the colored lighting maps should be found providing the ‘Colored Lighting’ option has been enabled.

SNES9x emulator input lag reduction

A user on our forum, Brunnis, began some investigations into input latency and found that there were significant gains to be made in Super Nintendo emulators by rescheduling when input polling and video blitting are being performed. Based upon these findings and after some pull requests made to SNES9x, SNES9x Next, and FCEUmm, at least 1 to 2 frames of input lag should be shaved off now.

Do read this highly interesting forum thread that led to these improvements here.

News for iOS 10 beta users

There is now a separate version for iOS 10 users. Apple once again changed a lot of things which makes it even more difficult for us to distribute RetroArch the regular way.

Dynamic libraries cores cannot be opened from the Documents directory of the app anymore in iOS 10. They can be opened from the app bundle, as long as they are code-signed. This reverts back to the previous behavior of RetroArch, where the cores need to be in the modules directory of the app bundle.

Go to this directory:

https://github.com/libretro/RetroArch/tree/master/pkg/apple

and open RetroArch_iOS10.xcodeproj inside Xcode.

Note – you will need to manually compile the cores, sign them, and drag them over to the modules directory inside Xcode.

Example –

1. You’d download a core with libretro-super.

A quick example (type this inside the commandline)

git clone https://github.com/libretro/libretro-super.git

./libretro-fetch.sh 2048

./libretro-build.sh 2048

This will compile the 2048 core inside /dist/ios.

2. Move the contents of this directory over to the ‘modules’ directory inside the RetroArch iOS 10 Xcode solution. It should presumably handle signing by itself.

Bugfixes/other miscellanous things

• Stability/memory leak fixes – We subjected RetroArch to numerous Valgrind/Coverity/Xcode Memory leak checks in order to fix a plethora of memory leaks that had reared their ugly heads inbetween releases. We pretty much eliminated all of them. Not a sexy feature to brag about, but it involved lots of sweat, tears and effort, and the ramifications it has on the overall stability of the program is considerable.
• There were some problems with Cg and GLSL shader selections which should now be taken care of.
• ScummVM games can now be scanned in various ways (courtesy of RobLoach)
• Downloading multiple updates at once could crash RetroArch – now fixed.
• Several cores have gotten Retro Achievements support now. The official list of systems that support achievements now is: Mega Drive, Nintendo 64, Super Nintendo, Game Boy, Game Boy Advance, Game Boy Color, NES, PC Engine, Sega CD, Sega 32X, and Sega Master System.
• You can now turn the supported extensions filter on or off from the file browser.

Effort to addressing user experience feedback

I think a couple of things should be addressed first and foremost. First, there is every intent to indeed make things like a WIMP (Windows Icons Mouse Pointers) interface around RetroArch. To this end, we are starting to make crossplatform UI widget toolkit code that will make it easy for us to target Qt/GTK/Win32 UI/Cocoa in one fell swoop.

We have also spent a lot of time plugging some of the rough edges around RetroArch and making the user interface more pleasurable to work with.

Youtube libretro channel

Hunterk/hizzlekizzle is going to be running the libretro Youtube channel from now on, and we’ll start putting up quick and direct Youtube videos there on how to be able to use RetroArch. It is our intent that this will do a couple of things:

1. Show people that RetroArch is easy to use and has numerous great features beneath the surface too.
2. It allows users to give constructive criticism and feedback on the UI operations they see and how they think they should be improved.
3. We hope to engage some seasoned C/C++ coders to help us get some of these UI elements done sooner rather than later. Most of RetroArch development mostly relies on a handful of guys – 5 at the most. It is a LOT of hard work for what amounts to a hobbyist project, and if we had a lot more developers seasoned in C/C++, stuff could be done quicker.
4. There is no intention at all to make RetroArch ‘obtuse’ for the sake of it, there is every intention to make it more accessible for people. Additional help would go a very long way towards that.

Regarding the current UIs and their direction, it is obviously meant to be a console-like UI experience. This might not be what desktop users are used to on their PCs but it is what we designed menu drivers like XMB to be. It is true that keyboard and mouse are mostly seen as afterthoughts in this UI but really, we wrote the UI with game consoles and something where a gamepad is the primary input device at all times, particularly since a keyboard to us is a poor way of playing these console-based games anyway.

Anyway, menu drivers like XMB and MaterialUI will never have any WIMP UI elements. HOWEVER, in upcoming versions, we will be able to flesh out the menubar and to allow for more basic WIMP UI elements.

RetroArch is meant to be a cutting-edge program that is ultra-powerful in terms of features. With that comes a bit of added complexity. However, we have every intent of making things easier, and with every release we put a lot of time and effort into improving things. But again, more developers would help out a substantial lot in speeding up certain parts that we are working on.

Our vision for the project involves an enormous workload and we’re considering differnt ways of generating additional support. If a Patreon might allow us to get more developers and get more stuff done faster, we might consider it. But we want such things to be carefully deliberated by both our internal development staff and the users at large. I hope you’ll be able to appreciate the relative rough edges around the program and appreciate the scope and the craft we have poured into the program. Please appreciate that we are pouring a lot of blood, sweat and tears into the program and that mostly we try to maintain an upper stiff chin when faced with all the criticism, but we do care and we do intend to do better. Volunteer coders are very welcome though, by people who have some time to spare and who want to make a difference. We ask for your understanding here, and we hope that by finally speaking out on this, users can gain a better understanding of our intent and be able to appreciate the program better in light of that.

Also see our other major announcements today:

RetroArch 1.3.6 released

Lutro – easy retro game creation, powered by libretro

And our earlier story featured a couple days back on ParaLLEl –

First ever Vulkan Nintendo 64 emulator, ParaLLEl, coming soon, only for Libretro/

What is paraLLEl?

This is a standalone libretro core for now that we keep separate from the regular Mupen64plus libretro core that it is based on. It includes only a Vulkan rendering backend and a low-level RSP. This core will only work right now if you are running it with a Vulkan driver.

In the future, paraLLEl will be the new name for our N64 emulator which (while initially starting out as a Mupen64plus core) has grown into its very own entity. It will have among other things:

– Completely rewritten CPU cores, both interpreter and dynarec. We want to fix the remaining CPU bugs that prevents Mupen64plus from being able to run certain games that PJ64 can, for instance. We also want to be able to move away from having two separate dynarec systems in Mupen64plus, where one is aimed at Atoms and ARM CPUs, and the other is meant for desktop x86, and neither is particulary fast.
– A unified HLE video renderer that combines the best of Glide64, Gliden64, Rice, and GLN64, and offers optional runtime codepaths for performance.
– A unified LLE video renderer infrastructure that allows for both software rendering (Angrylion) and the Vulkan/GL 4.3 powered equivalent (the video plugin we now call paraLLEl).
– As part of the CPU rewrite, an RSP dynarec will also have been written around that time.

How to use this

• Download RetroArch 1.3.6 (or any future version from this point on). See this blog post here.
• Download the ParaLLel core. To do this, start up RetroArch. Inside the menu, go to Online Updater -> Core Updater. Scroll down in the list until you see Nintendo 64 (ParaLLEl).
• Download it.
• IMPORTANT! READ! Before starting, make sure that you have selected the Vulkan display driver. To check this, go to Settings -> Driver, and see if ‘Video’ says ‘vulkan’. If not, select it, and then restart RetroArch for the changes to take effect.
• Load the core with a ROM.

Preliminary requirements

* A GPU capable of supporting the Vulkan API
* Vulkan drivers installed on your system

nVidia

ParaLLEl has been tested on an nVidia Maxwell GPU and has been confirmed to be running well.

AMD

ParaLLEl has been tested on an AMD Radeon 250 and has been confirmed to be running well.

Intel MESA iGPU

Easily the biggest problem right now out of all Big Three. Thankfully, Mesa developer Jason Ekstrand was very receptive to our feedback and together with him, we have been able to get Vulkan N64 successfully booting now on Ivy Bridge all the way up to Broadwell.

When we first started the renderer, it would crash at startup and not even let us ingame.

Apparently some of the patches that helped get paraLLEl up and running also helped The Talos Principle finally start to go-ingame, so that is nice to see!

If you want to test paraLLEl on an Intel iGPU on Linux, be sure to read on until the last paragraphs. You will have to compile a bleeding edge fork of Mesa, we will explain to you how to do this. Do note that in the future, all these patches will have been pushed to upstream, so if you are reading this blog post a month from now, just go with the latest upstream Mesa instead.

At a later date in time it is likely that your Linux distribution’s package management system will feature newer versions of Mesa with these patches already incorporated.

See some of the before/after screenshots here.

RDP emulation status

As this is a pre-alpha release, the full transplantation of Angrylion to compute shaders is not yet completely done, although many games already run reliably.

Hunterk made a couple of videos of RetroArch running ParaLLEl using RetroArch’s built-in recording feature.

Super Mario 64

The quintessential N64 game. Not too many surprises here.

Note – you might have to enable ‘Synchronous Sync’ on Intel Ivy Bridge in order to be able to progress beyond the title screen. This might not be an issue on other hardware.

Mario Kart 64

The popular karting game. Note the framebuffer readback activity on the wall.

Legend of Zelda: Majora’s Mask

The follow-up to the Legend of Zelda: Ocarina of Time.

Note – for both Majora’s Mask and Ocarina of Time, it is required to enable ‘Synchronous Sync’ so that the subscreen works correctly.

Body Harvest

In some ways the spiritual precursor to GTA3, made even by the same company. Note a couple of things: unlike with any RDP HLE plugin ever, not only can we cross the bridge, but we can do so without the player literally walking through the bridge instead of walking correctly on top of it. High-level RSP up until now has been too buggy to accurately enable both Body Harvest US and European versions from working with the crossbridge (a patch by LegendofDragoon made it work for the European version, but with any HLE plugin you would still see the player character essentially walking through the bridge when passing over it, and in the US version you just plain cannot cross the bridge unless you are using a low-level RSP plugin.

So, low-level RDP in conjunction with low-level RSP takes care of all that.

Jet Force Gemini

One of the later games released by Rare before the big Nintendo-Rare breakup. Shares some microcode with Diddy Kong Racing and Mickey’s Speedway USA, so all three games pretty much work without any major issues on paraLLEl.

There are some things to talk about here. There is one core option in paraLLEl in specific which has a heavy bearing on emulation accuracy:

* Synchronous RDP *

Turning this off allows for higher CPU/GPU parallelism. However, we found so far that many games either won’t run or have broken framebuffer effects if left disabled, so we felt it was safer to leave it enabled for now.

It has been verified that with certain games, disabling this can provide for at least a +10fps speedup. Try experimenting with it.

Things you need to know before running the alpha

Like they say, Rome wasn’t built in a day. This is an alpha release. Keep in mind that not every game right now will run correctly but that it’s expected we will be able to nail all these issues in quick succession shortly.

* Even though this renderer delivers on its promises and completely eliminates the RDP rendering bottleneck, the RSP bottleneck still remains. In order to make emulation significantly faster, we will therefore have to start moving away from having only an LLE interpreter RSP core, and move towards a dynamic recompiler. Work on this is commencing, so this bottleneck is just temporary. For now, the beefier your CPU is, the less chances you have of running into said bottlenecks.
* Not all games will work correctly right now. Porting the Angrylion renderer to Vulkan has been a challenge to say the least. There are still some unimplemented edge cases which will be fleshed out in the upcoming weeks.

Major bugs remaining/things left to be done

Some of the current issues that still makes this a pre-alpha candidate

• VI overlay.
• Some framebuffer management corner cases
• Some obscure combiner features
• Interlacing bugs – games that output to the screen in interlaced mode will show some graphics glitches right now. Should be one of the more trivial things to fix.

What’s different between this and Angrylion RDP AIO/CEN64?

Angrylion RDP AIO and CEN64 are using the software-rendered Angrylion plugin (the base for most RDP-based renderers) and optimizing it with SSE code and multithreading. ParaLLEl instead is porting Angrylion to the GPU (through Vulkan) with compute shaders and leveraging async compute to be able to parallelize it as best as possible. CEN64 is also going for an RSP dynarec to speed up things further.

The next step for ParaLLEl will also be an RSP dynarec to increase performance, and in fact MarathonMan (the author of CEN64) has been willing to help us out with some performance ideas in this department.

Both approaches (optimizing the software-rendered Angrylion plugin) and hardware acceleration (ParaLLEl) are valid and worthwhile.

Android port

Honestly, for this release I have not yet bothered compiling it for Android and seeing if it will run on the Shield tablet. I will start doing that after this release is over. I think it will become more useful once RSP dynarec is in but it might already be neat to be able to run it regardless.

Source

The sourcecode for ParaLLEl can be seen here. In order to compile it yourself right now, you need to git clone the mupen64plus libretro repository, and run the following command:

make HAVE_VULKAN=1

Compiling bleeding-edge Mesa for Intel Vulkan (Linux) in order to use paraLLEl

There are not a lot of Vulkan test cases out right now, so paraLLEl needed some special patches pushed to Mesa in order for it to work.

Here are the steps required:

1. Type these lines into the commandline:

git clone git://people.freedesktop.org/~jekstrand/mesa

Go to the directory by typing:

cd mesa

git checkout wip/retroarch

autoreconf -vfi

./configure --with-vulkan-drivers=intel --with-gallium-drivers= --with-egl-platforms=wayland,x11 --with-dri-drivers=i965


(Verify that in the output, Vulkan drivers does not say ‘no’).

make

2. After we have done all this, we will need to setup a file to point to our vulkan driver. If it does not exist, create it here:

/etc/vulkan/icd.d/dev_icd.json

This file should point to the compiled Vulkan driver library file’s path. This is the file you just created before.

Here is a local example of how it could look like. You will have to change the filename path to wherever your libvulkan_intel.so file is located.

Here is an example of how it could look:

{
"file_format_version": "1.0.0",
"ICD": {
"library_path": "/home/squarepusher/libretro-super/mesa/lib/libvulkan_intel.so",
"abi_versions": "1.0.3"
}
}

You should replace the library path with the exact filename location on your system. Save this file (you might need root permissions for this).

What’s next?

Expect major speedups soon and other exciting news regarding dynarec unification plans. Daeken will be guest blogging about that soon, and it will have far ranging ramifications for libretro cores and emulators in general. Also, expect Beetle PSX to be one of the other major beneficaries of that.

Today we are releasing a beta version of RetroArch 1.3.6+ (latest snapshot, release candidate for 1.3.7) for the Playstation3 and PS Vita. Be sure to thank frangarcj for the latter since he went through the trouble of making sure we could make the jump from Rejuvenate to HENKaku in swift order.

Where to get it

You can get the PS Vita/PS TV version here:

http://buildbot.libretro.com/nightly/playstation/vita/

Grab the latest archive.

How to install

1. Extract the contents of this 7zip archive to a folder somewhere on your PC. This will extract a bunch of vpk files to your harddrive.
2. On the PS Vita/PS TV, make sure the HENkaku exploit has already been installed. Go to the bubble ‘molecularShell’ and start it. Once inside the filebrowser, press ‘Select’ to start the FTP server. Write down the FTP server address you see here.
3. Go back to your desktop PC, start up an FTP client, and input the IP address and port that was displayed on your PS Vita/PS TV. Transfer the vpk files to some place on either ur0: (internal storage) or ux0: (this being your Memory Card).
4. On the PS Vita/PS TV, press circle to go back. Then once back inside the filebrowser, go to the directory where you extracted the vpk files. Install the cores you want.
5. Exit the ‘molecularShell’ program. You should now be back inside the home screen. From here,
RetroArch bubbles should start appearing in the menu. You can now use RetroArch.

How to install ROMs

1. The same way you installed RetroArch. Start ‘molecularShell’, go through the previous section’s steps 2 and 3 again, but this time transfer roms over instead. Then load them from RetroArch.

State of the port

What works

* (Core-related) CatSFC / SNES. Works fine. Should run at fullspeed for most games (dip to 42fps on Yoshi’s Island intro screen (SuperFX2 game), seems to be fullspeed otherwise).
* (Core-related) FB Alpha CPS1. Works fine. Fullspeed. Runs all games. Use an older FBA romset.
* (Core-related) FB Alpha CPS2. Works fine. Fullspeed. Runs all the big CPS2 ROMs. Use an older FBA romset.
* (Core-related) FB Alpha Neo Geo. Works fine. Fullspeed. Not all big ROMs will work right now though. KOF 96 could be loaded (about 23/24MB). Might have to play around with heap to be able to get bigger ROMs to load. For now expect same size limitations as the Wii port. Hopefully we can get past this soon.
* (Core-related) FCEUmm. Works fine. Fullspeed.
* (Core-related) Genesis Plus GX. Works fine. Fullspeed.
* (Core-related) Mednafen Neo Geo Pocket Color. Works fine. Framerate at around 52/53fps. There might be a new Neo Geo Pocket Color core coming soon (not Mednafen NGP) which would run at fullspeed with no problems.
* (Core-related) Handy / Lynx. Works fine. Fullspeed.
* (Core-related) Mednafen Wonderswan. Works fine. Fullspeed.
* (Core-related) Mednafen Virtual Boy. Works. Too slow (around 26fps). Corrupted pitch (likely due to 32bit color). Speedups/idle loop optimization hacks MIGHT bring this fullspeed later on.
* (Core-related) NXEngine / Cave Story. Works fine. Fullspeed.

What doesn’t work

* ROMS have to be currently unzipped now (EXCEPT for the FB Alpha ROMs).
* No core switching yet from inside RetroArch. For now, each core is a standalone program.
* Add Content -> Download Content currently doesn’t work. If you do try it, you might have to restart.
* History list doesn’t work yet.
* Save states can be saved, but cannot be loaded yet. We need to figure out why.
* Threading needs to be still implemented.
* (Core-related) 2048 core. ‘Start content’ does not work yet like it should. Wait until we fix this.
* (core-related) Prboom/Doom core. Crashes after loading a Doom WAD. Wait until we fix this.
* (Core-related) Picodrive core. Crashes after loading a ROM. Wait until we fix this.
* (Core-related) QuickNES core. Doesn’t load a ROM. Wait until we fix this.
* (Core-related) Gambatte core. Doesn’t load a ROM. Wait until we fix this.
* (Core-related) SNES9x Next core. Doesn’t load a ROM. Wait until we fix this. Will likely be too slow compared to CatSFC anyway, so not sure if worth it for Vita.
* (Core-related) DOSBox core. Haven’t tried this yet. Likely too slow to be worthwhile.

Future plans

* More cores, fix remaining cores that are broken.
* Try to get Cg runtime working so we can have Cg shaders running.
* Try to get multiple gamepads working on PS TV.
* More.

A sneak peek at 1.3.7 features

Since this is a current nightly snapshot release, PS3 and Vita users are able to get a sneak peek at some of the features that will be part of RetroArch 1.3.7 for the other platforms.

• Improved error handling. When loading the wrong ROM into a core, most cores should be able to now gracefully exit instead of just quitting or crashing RetroArch.
• Much more complete info message system. Press ‘Select’ on any entry and 99% of the time it should show you a handy help message explaining to you what each setting does. The ‘English’ language setting is currently the one that is most complete, for all other languages we need to wait until translators have finished adding all the help messages in their own language.

An Emscripten port of RetroArch has existed for years, but until recently, we never had a good opportunity to launch it in a state we felt comfortable with. Well, until now that is.

Web Player

So what is RetroArch Web Player? It’s a port of RetroArch that runs inside your web browser, powered by emscripten and asm.js. Most modern browsers available today should be compatible. That being said, we strongly recommend you use Google Chrome right now for smooth v-synced gameplay with no audio crackling.

You can check it out right here!

Your browser does not support iframes.

Dropbox support may not work in this embedded-player we added to this post, we haven’t enabled SSL on our main site and Dropbox doesn’t allow any sort of wildcard or regex on web apps.

You can also click on ‘Web Player’ in the top-right corner of the libretro.com website and in our itch.io page in order to use it.

Current state of the port

• Over 40+ libretro cores available
• Gamepad support via SDL2
• Hybrid filesystem including cloud syncing courtesy of BrowserFS. This filesystem stores userdata in one of two backends (browser application storage or Dropbox); assets are loaded synchronously from an online repository and cached by the browser for future usage

Known frontend issues

• Player 1 gamepads can sometimes control both player 1 and 2 at the same time in games that support 2 players.
• Guide button mapping is currently not available. We’re not sure if this is a limitation of the SDL2 input driver.
• Recent History doesn’t work yet.
• GLSL shaders don’t work (yet?).

Known core issues

• BlueMSX (MSX) currently doesn’t work.
• Craft core (Minecraft) currently hangs.
• Desmume core (Nintendo DS) currently doesn’t work.
• EasyRPG core (RPG Maker game engine) currently doesn’t work.
• FFmpeg core (Movie/music player) currently doesn’t work.
• Mupen64plus core (Nintendo 64) currently doesn’t work.
• PicoDrive core (Sega Genesis/32X) currently doesn’t work.
• QuickNES core (Nintendo NES) has slightly distorted graphics.
• Tyrquake core (Quake 1 engine) currently hangs at startup loading screen.

Special thanks

• Jvilk — for his excellent BrowserFS implementation and fixing a few bugs for us immediately when they were reported
• RobLoach — for his work on the template
• Twinaphex — for his tireless work on RetroArch and the cores
• ToadKing — for the initial emscripten port and some fixes he sent on our way recently
• Radius — for something? idk I did some work I think