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.
The Redream core is currently available for:
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
Go to Online Updater -> Update Cores.
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.
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.
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.
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.
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)
GLSL shaders now preferred over Cg when possible
Update to latest RetroArch for compatibility with updated GLSL shaders
Cg shaders demoted, GLSL promoted to first-class
Portability and compatibility are major goals for RetroArch and libretro, so we invested heavily in Nvidia’s Cg shader language, which worked natively anywhere their Cg Toolkit framework was available (that is, Windows, Linux and Mac OS X), as well as on PS3 and Vita, and could be machine-compiled to messy-but-usable GLSL (lacking a few features, such as runtime parameters) for platforms that lacked the framework (primarily ARM / mobile platforms). Cg was also so close to Microsoft’s HLSL shader language that many Cg shaders will compile successfully with HLSL compilers, such as those available with Windows’ D3D driver and on Xbox 360.
This was great for us because we could write shaders once and have them work pretty much everywhere.
Sadly, Nvidia deprecated the Cg language in 2012, which left us in a bad spot. Since then, we’ve been limping along with the same strategy as before, but with the uneasy understanding that Nvidia could stop supplying their Cg Toolkit framework at any time. Rather than sit idly by, waiting for that other shoe to drop, we took it upon ourselves to hand-convert the vast majority of our Cg shaders to native GLSL with all of the bells and whistles. TroggleMonkey’s monstrous masterpiece, CRT-Royale, still has a couple of bugs but is mostly working, along with its popular BVM-styled variant from user Kurozumi. Additionally, before this conversion, many of our Cg shaders were flaky or completely unusable on libretro-gl cores, such as Beetle-PSX-HW’s OpenGL renderer, but these native GLSL conversions should work reliably and consistently with any core/context except for those that require Vulkan (namely, ParaLLEl-N64’s and Beetle-PSX-HW’s Vulkan renderers).
With the GLSL shaders brought up to speed, we can finally join Nvidia in deprecating Cg, though it will still remain as an option–that is, we’re not *removing* support for Cg shaders or contexts at this point–and we will continue to use it where there is no other choice; namely, Windows’ D3D driver and the Xbox 360, PS3 and Vita ports. Moving forward, our focus for shaders will be on native GLSL and our slang/Vulkan formats, though we will likely still port some to Cg from time to time.
RetroArch now correctly handles #version directives in GLSL shaders; GLSL shader repo updated to match
There have been a number of updates to the GLSL shader language/spec over its long life, and shader authors can use #version directives (that is, a line at the top of the shader that says #version 130 or whatever) to tell compilers which flavor/version of GLSL is required for that shader. However, RetroArch has long had a strange behavior whereby it injected a couple of lines at the beginning of all GLSL shader files at compile time, and this broke any shader that attempted to use a #version directive, since those directives must be on the first line of the shader. This meant that our shaders couldn’t use #version directives at all, and all of our shaders lacked #version directives until very recently for this reason. These #version-less GLSL shaders are still perfectly compliant GLSL because GLSL v1.10 didn’t support directives, either, but the necessity of leaving off the #version started to cause some problems as we whipped our GLSL shader library into shape.
On AMD and Nvidia GPUs, the compilers would just toss up a warning about the missing directive and still expose whatever GLSL features were available to the GPU, which worked out great. On Intel IGPs, however, the compiler tosses the error and then reverts to only exposing the features available in ancient GLSL v1.10 (released way back in 2004). As a stopgap, we gave many shaders fallback codepaths that would still work in these circumstances, but a number of other shaders were either impossible to make compatible or even the compatible result was imperfect. So, as of this commit (courtesy of aliaspider), RetroArch will no longer reject shaders with explicit #version directives, and we have added those directives to any shaders that require them at the lowest version that still compiles/functions properly. That is, if the shader doesn’t use any features that require greater than #version 110, they will still have no #version specified, and any shader that requires #version 120 but not #version 130 will not have its requirements increased to the higher version for no reason. This should keep our GLSL shaders as compatible as possible with older hardware, and including the #versions explicitly when needed will also make it easier for other programs/developers to utilize our shaders without any unnecessary guesswork due to behind-the-scenes magic.
This change does require a clean break, insofar as older versions of RetroArch will choke on the new #version directives (that is, they’ll fail to compile with the “#version must occur before any other program statement” error pictured above), so users with Nvidia or AMD GPUs must update their RetroArch installation if they want to use the updated shaders. Users with Intel IGPs will be no worse off if they don’t update, since those shaders were already broken for them, but they’ll probably *want* to update to gain access to the many fancy shaders that now work properly on their machines.
Mobile GPUs using GLES had many of the same issues that Intel IGPs had, with many shaders refusing to work without #version directives, but GLES compatibility added in a further complication: GLES requires its own separate #version directives, either #version 100 es or #version 300 es, which are different from and incompatible with desktop GL’s #versions. To get around this, we added a trick in RetroArch to change any #version of 120 or below to #version 100, which is roughly comparable in features to 120, and any #version 130 or above to #version 300 es whenever a GLES context is used. This should get everything working as effectively and consistently as possible on mobile GPUs, but if anything slipped through the cracks, be sure to file an issue report at the GLSL shader repo.
Half a year after RetroArch 1.3.6 was released, now comes the next big stable! Version 1.4.1 is by any yardstick a big massive advance on the previous version. There are about 5000 commits or more to sift through, so let’s focus on a few big main standout features that we want to emphasize for this release.
We are calling this release an ‘Open Beta’ because we want people to put the massively improved Netplay features through its paces! All of your feedback and issues will be taken onboard so that 1.5.0 (which we intend to ship somewhere beginning of March) will deliver on all the promises we have made for netplay.
Netplay has seen a big massive improvement since version 1.3.6.
To set up a netplay game, you have two options: Manual or automatic connection.
Naturally, the automatic way is easier:
To host, just load a core and launch some content as usual and, once the game is running, go back into the ‘quick menu’ (the default keyboard shortcut is F1) and scroll down to the ‘netplay’ submenu. From there, choose ‘Start netplay host’ and it will announce your game to the lobby server for other users to join. You can go ahead and start playing and new players can jump in at any time. That is, RetroArch no longer stalls out until clients join.
Joining an existing session is just as easy. From the main menu, navigate over to the netplay tab (the icon looks like a wifi symbol), scroll down to ‘Refresh Room List’ and hit the ‘accept’ key/button (the default keyboard shortcut is the ‘X’ key). RetroArch will fetch the current list of available hosts and display them right there in the netplay tab. From there, just pick the host you wish to join and RetroArch will cycle through your playlists searching for a content match. If it finds a match, you’ll jump right into the host’s game already in progress.
To use manual connection, the host does the exact same steps. The client must load the same core and game first, then choose the “connect to netplay host” option from the netplay menu. You will be prompted for the IP address of the host. Enter it to connect.
To keep your games private, the host may set a password, required to connect, in the network settings menu.
We want your feedback and input on netplay, and the aim is that we take your feedback into consideration for 1.5.0 (which we will launch early March) to put the final finishing touches on netplay in general. Things like chat, friend lists and so on will all need to be implemented still.
Multi-language support/Japanese language support
We have added UTF-8 support and we have added translations for several languages now. Of these, Japanese is probably second to English in terms of being the most complete translation.
In addition to this, the new onscreen keyboard also has multilingual support, and supports Japanese fully (Hiragana, Katakana).
Free homebrew Bomberman clone game – Mr.Boom
Mr.Boom is a Bomberman clone. It supports up to 8 players and features like pushing bombs, remote controls and kangaroo riding.
Right now, this core works for Mac/Windows/Linux/ We are still working on Android support!
Mr. Boom currently requires at least a minimum of 2 players. There is no singleplayer mode (yet). It can not yet be used with netplay but that is our ultimate aim! Free 8-player easy Bomberman-like gameplay for everybody! We will make an announcement later when netplay support is fully working for this core!
New menu graphical effects
In addition to the ribbon effects, we have added some new menu effects : Bokeh, and Snow.
Check the accompanying video to see them in action. You can access these menu effects by going to
Settings -> User Interface -> Menu and setting “Menu Shader Pipeline” to any effect of your choosing.
NOTE: These two new menu effects are not yet available for Vulkan and Cg. Ports would have to be made first of these menu effects, since they are completely shader-based.
Quality-of-Life improvements to the menu
We have taken all the criticisms of the menu UI to heart and we really pushed ourselves to make the menu much more pleasant to deal with.
We have gone to the painstaking effort of making sure that nearly every menu entry now has a small description below it.
Loading content has been massively streamlined. There is no longer a separate ‘Load Content’ and ‘Load Content (Detect Core)’ option. You simply select a starting point directory, you then select your game and you decide which core to use.
There is a new onscreen keyboard made for the menu which is compatible with touch and the mouse. It not only supports traditional western characters but thanks to improved multilingual support it will also support Japanese (Kanji, Hiragana, Katakana and Romaji).
In fullscreen mode, the mouse cursor inside the menu will only show for about 5 seconds. If there is no mouse activity it will disappear from the screen until you move the mouse again.
Improved error handling
Cores should now report an error message back to RetroArch in most instances where a ROM/content fails to load. We went over most cores and we are reasonably comfortable in that we took care of most of the trouble spots.
Vulkan N64 and PSX now works on Android!
To read more about these projects, read our past articles here –
ParaLLel (Nintendo 64 core with Vulkan renderer) and Mednafen PSX HW should now work on Android devices that support Vulkan!
Unfortunately, GPU is currently not the bottleneck here. In the case of both of these emulators, more work is required before they will start to run at fullspeed on Android devices. We need to get the LLVM dynarec working on ARM devices.
In the case of Mednafen PSX HW, the interpreter CPU core is the main bottleneck which prevents the emulator from reaching playable speeds right now. An experimental dynarec was written a year ago but it still needs a lot of work before it could be considered ‘usable’.
Lots of other miscellaneous stuff
(Linux) DRM/KMS context driver should be more compatible now
(Linux) The GLX context driver now uses GLX_OML_sync_control when available, leading to much improved swap control. Potential video tearing and frame time deviation will be way lower in general.
(Linux) Attaching a PS4 gamepad will allow you to use the audio headphone jack to route sound to your headphones if you use the ALSA audio driver. It will now query the available audio output sampling rates that an audio device supports, and if the recommended output sampling rate that we use in RetroArch doesn’t match, we will use a sampling rate that the audio device DOES support instead. The PS4 pad only works with 32Khz audio, hence why we need to switch to it on the fly in order to get sound working with it.
(Android) Should fix a longstanding touch input bug that might have prevented touch from working altogether on certain devices.
(Android) GLES3/3.1 support, the fancy ribbon effect and Snow/Bokeh should also be available on Android now.
(Linux/Wayland) Full input support, keyboard and mouse.
Too much stuff to mention
Also read our companion article for more information here –
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.
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.
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.
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
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.
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.
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.
Go to RetroArch, go to Online Updater, go to ‘Update Cores’, and download ‘PlayStation (Mednafen PSX HW)’. You might need to update your core info files first before this will show up properly. To do this, go to ‘Online Updater’, and select Update Core Info Files’.
Here’s a rundown on what you can expect from RetroArch v1.1, the next version of RetroArch to be released. Please bear with us that it has taken us so long since v126.96.36.199 to come up with a new official release. This v1.1 version has been long in the making to ensure that this new version will be a big major milestone for RetroArch in general.
So, here’s what the release will comprise of –
Going all PSP – PPSSPP core
We have ported the popular PlayStation Portable emulator, PPSSPP, over to the libretro API. This marks the second big libretro implementation to be using libretro GL after Mupen64 Plus.
It is shaping up to be a very stunning release. Linux users will especially appreciate the changes we’ve made which makes it possible to run PPSSPP in DRM/KMS mode (something which wasn’t possible in standalone since glew has X11 dependencies).
We’re aiming for two modes of operation. One mode will be in which the PPSSPP core functions much like standalone – where it saves everything inside a main PPSSPP assets directory and you install games from PPSSPP’s GUI. The other mode is more like a headless mode – the way every libretro core has functioned up until now. Saves will be saved in .srm form and it will be possible to directly boot ISOs/PBPs/.BINs without having to install them first from a GUI. There’s something to be said for both modes of operation.
We of course take no credit for any of the real emulation work in PPSSPP – the only thing we take credit for is porting it to the libretro API. We take nothing away of the accomplishments made by this team and we hope that the libretro port can be pushed upstream once it’s done. Please pay them a visit at http://www.ppsspp.org/ and support their efforts to improve PSP emulation – they’ve already come a long way in the two years it has been public.
We’ve made some screenshots of the core in action which you can check out here and on Twitter. We’re striving to expose as many of PPSSPP’s features as possible through core options for headless mode operation.
Needless to be said, we think this will be one of the main standout features of RetroArch v1.1. Hopefully it will open up people’s minds about how RetroArch and libretro doesn’t necessarily mean retro-grade graphics – some of these games like Tekken 6 and Soul Calibur Broken Destiny don’t look far removed from their PS3 versions when upscaled to 2x or 3x. And to see it running as fluidly as it does in RetroArch without any audio breakup whatsoever or any frames dropped is a sight to behold.
The PPSSPP core will be available for PC (we’re aiming for Linux/OSX and Windows), and mobile (iOS/Android/Blackberry). After version 1.1 is released, we will research an Xbox 360 port.
Going all PSP – RetroArch PSP
Just having a PSP core would be one thing, but RetroArch v1.1 is going to go one extra mile by also simultaneously appearing on the PSP itself.
Nearly all of the credit for this port should go towards aliaspider- I played only a minor but crucial part in the proceedings. He has really done a bang-up job porting over a great many new cores over that are useful for the PSP, as well as improving the performance of existing cores so that they run well on the PSP.
Right now we have greatly improved the performance of FCEUmm, NXEngine, Gambatte, Mednafen PC Engine (and others) so that they run fullspeed at PSP. Please keep in mind that a PSP for general purpose code is about two times as slow as a Raspberry Pi. So you’re dealing with a very weak CPU here, and so it necessitates specific PSP-specific code to really get the most out of its performance. And thankfully the libretro API allows for this – the libretro API doesn’t prevent you from taking advantage of PSP-specific hardware features in order to speed up performance inside a core.
Aliaspider also made a port of TempGBA over to the PSP. This is a Game Boy Advance emulator based on gpSP Kai (itself based on gpSP – a now defunct emulator by Exophase). There’s also a preliminary port of the popular CPS2/Neogeo emulator, but it isn’t yet done. No idea yet if this core will make it for the v1.1 release.
Like hunterk’s previous blog post indicated, the portability of RetroArch is really coming into its own now. With the PPSSPP core, it will be possible to run RetroArch PSP itself. So essentially what you have is that RetroArch PSP can be made to run inside a PSP emulator which itself is being run inside a native platform version of RetroArch. How much farther can we go from here? The future only knows.
Several new cores will be appearing. We made a port of fMSX and BlueMSX to the libretro API. This was a home computer released in the mid-1980s that was backed up by a consortium of companies (among them a little company called Microsoft and another small fish called Sony). Oddly enough, while it couldn’t really be considered a major worldwide success, it was relatively popular in Japan and (of all countries) The Netherlands. This home computer is also noteworthy for receiving some of the first games Hideo Kojima made in his career, such as Penguin Adventure (one of the first games I ever played BTW) and Metal Gear 1/2.
There will be RetroKeyboard support for these cores to sweeten the deal, but we will also try to have some sane default configs for the RetroPad per-game for some of the more popular games.
There will also be a Vectrex core, Vecx. This was another ’80s game console, and the main notability of this game console is that it wasn’t using sprite rasterization but rather vector-based. For all practical purposes it could be considered the first real home console capable of ‘3D graphics’.
Lakka – a new GUI beginning
Lakka will appear inside RetroArch starting as of version 1.1. So far, users have been using a very low-fi menu called RGUI. It is perfectly scalable from low-resolution displays to high-definition TVs, but there’s no denying it looks very much like something you would expect from a DOS program.
Lakka will be a more full-featured eyecandy UI. It will require OpenGL support inside the RetroArch version, so expect this to be usable on RetroArch PC and Android/iOS/Blackberry (PS3 maybe if it makes it for v1.1).
In terms of features and appearance, Lakka looks a lot like the PSP’s XMB frontend.
In the future, more menu drivers can be added, each being tailored towards a specific enduser preference. We have made the menu code far more generic to allow for different implementations which doesn’t require the coder to rewrite all the settings logic again and again.
You can watch a video of a prototype in action here – keep in mind that this is still a prototype and that the final version will look a lot more refined. In case you wonder, the guy showcasing it here is one of the authors responsible for the Lakka GUI – Jean-Andre Santoni (known also as kivutar).
Audio DSPs / Software Video Filters
We already touched upon this in the previous blog post about RetroArch v188.8.131.52 (which has now morphed into version 1.1). This feature has been implemented and it makes it possible to apply audio DSP filters and video software fitlters to RetroArch’s audio/video output.
We received a Blackberry Z10 phone from Blackberry sometime ago. In return, we will fully support Blackberry 10 starting as of v1.1. A new audio driver has been written, ALSA QNX, which should be far more optimal than the OpenAL driver we had before. We also intend on writing a nice Qt UI which wraps around RetroArch itself.
I know there has been a lot of discontent among Blackberry users that there have been so few releases, but rest be assured, we’re working on it.
Revamped iOS / OSX ports
I finally bought a Macbook Pro, and so I’ve been spending a lot of work on the OSX / iOS ports of RetroArch as of late. We’ve revamped nearly all of the settings so that it is possible for settings to be exposed to WIMP menus. This will be put to good use in the OSX / iOS ports of RetroArch.
The iOS version will be totally revamped as well. Cjori was working with me sometime ago on Controllers For All support. Hopefully I will be able to approach him a week before release time or so that we can do some final beta testing before we put the final polished version out.
X-Arcade Tankstick support
I received an X-Arcade Tankstick courtesy of Xgaming, and in return this device will be fully supported. Android support will be added, and I will also look into making it possible to bind it in RetroArch as two separate game controllers instead of it being recognized as a keyboard.
After v1.1, I will look into adding USB input drivers for the PlayStation3, Wii and Xbox 360 ports so that we will be able to use the X-Arcade Tankstick on thosee consoles as well without using their proprietary gamepad converter (which costs an additional $30).
Revamped Android port
Lots of work still remaining on the Android Port. The input code has been totally revamped and it should be possible to map a new gamepad directly from the menu. New input overlays have also been made (such as a a default RetroPad overlay) which works quite well.
Maybe if we make it in time we can revamp a lot of the UI code as well using our new generalized settings code which should prevent code duplication issues in the future.
Improvements to existing cores
Lots of improvements have been made to Mupen64Plus since the last new release, as well as a lot of other cores. We will also try to bring over the MAME/MESS 2014 cor e to Android – this might not appear on the Google Play Store since this will increase the APK size by about 150MB or so – instead a more fully featured version might be available on our new website.
Starting with the release of v1.1, there will be another big change – a new server (Virtual Private Server), and with it will come a buildbot. We will finally have the ability to do continuous integration tests and have daily builds for the cores and the RetroArch platform versions. The existing website will soon be moved over to the new host – the transition will be as seamless as possible to the user, so hopefully you guys won’t notice when we finally make the switch.
So when will it come?
The rest of this month will be spent by me and others feverishly working to get all of this stuff in a presentable state. We also want to do a fair bit of Quality Assurance so that this next big version will be very solid. The estimated release is somewhere in early September. A new release is contingent on all these different factors all coming together. In case some parts might take longer than expected, we might just drop a version of v1.1 with some of these features being added later. In any case, you shouldn’t have to wait longer than early September. Again, we’re sorry for some of the delays and announcements from before but we’re really trying to ensure here that this next RetroArch release will be a real big gamechanger and so the delays are justified from that perspective. Hopefully you’ll agree once it is dropped.
Also, I’m sure I neglected to mention a fair few new features as well in this writeup. In any case, there have been far too many changes since February of this year to sum up in one blog post. When v1.1 hits I will put up a more comprehensive overview of everything that has been added ,changed and improved.
It’s been a long time since the last release, and it’s been a long time since any news has been posted period.
So, first things first – yes, there will be a new release soon. I’m conflicted on whether to call it RetroArch 1.0 but I think we might as well get it over with so that we can have some kind of sane versioning from here on out.
We will relaunch on the Google Play Store. We still don’t know why we were pulled from the Play Store the last time, we never got a response from Google telling us the exact reason why they pulled us, and while this all sucks really badly and quite frankly makes me have second thoughts about committing myself too much to Google’s app store, we will try again. This time we have taken a few contingency measures –
Some GPL purists seem to want the option of being able to only have cores in RetroArch that are GPLv2 and/or GPLv3, but no cores which use proprietary non-commercial licenses. Rumor has it that this even led to RetroArch’s takedown from the Google Play store – the argument being cited was “license violation”. While it’s a quite spurious argument and I would have liked Google to have contacted me first so that I could have at least given my side of the story, we will meet these people half-way this time.
After the app gets installed, a popup disclaimer will show up. This asks you whether to remove the non-GPL licensed cores or whether to keep them. This is a permanent option and the only way to undo this is to get rid of your ‘user settings’ – upon which you get greeted with the same disclaimer again.
The logo has been redesigned by Agnes Heyer and it’s no longer a bog-standard Space Invaders icon. This is in case the takedown was over some copyright claim over the Space Invaders imagery being used. It’s still an invader, but at least it has a distinctive enough art style now as to make it “different enough”. Agnes also supplied us with some very nice handdrawn art that we’ll be using on the Google Play store.
Images from games running in RetroArch Android will no longer be on the store listing. Just in case we got pulled over that alone.
Anyway, hopefully this is sufficient to address all possible issues. Let it be said that if we get pulled again after this re-launch and Google doesn’t even have the decency to give us an e-mail explaining why they took it down, that will be it for me – I’m not going to continue republishing on the Play Store just because Google entertains random accusations of “license violations/copyright infringement” of whomever wants the app pulled. Google’s ‘public relations’ is quite frankly atrocious, not to mention insulting and demeaning since publishing apps on the Google Play Store is not free – we had to pay 25 dollars to be granted the “honor” by Google to get people to actually be able to install your app on their phones/tablets. Now granted, this is not yet as bad as Apple, but freedom this most certainly is not. I expect at least some very basic customer support for those 25 dollars instead of some “automated web form” that leads to nowhere.
Libretro/RetroArch going beyond traditional games/emulators
Anyway, with that negativity out of the way, I am very excited to finally uncover what I and others have been working on these past few months during the blackout. I have always maintained that RetroArch and libretro is about ‘more’ than just emulators and game ports, but to date there was not much to show for this claim.
I look at RetroArch not merely as a “frontend” for an application API, but also as a truly crossplatform architecture – something that abstracts input/video/audio/location/camera streams and lets you – the app creator – easily make use of these various streams to create very rich, full-featured applications without having to worry about which platform you’re developing for. Any game and/or emulator out there needs at least input/video/audio streams, and libretro/RetroArch so far has been catering to this need for a good few years now.
However, ever since the Wii and things like Kinect/PS Move, the videogames world is no longer as rigidly defined as it used to be, and some videogames are not even “videogames” anymore. Or, to put it more simply, just like art, nobody knows what a videogame is anymore. Thanks to motion sensors, cameras, and location-based sensors, we can do reasonably cool new things with a traditional 3D videogames engine that we simply weren’t able to do years ago because of the devices simply not having these kinds of hardware features at their disposal, and the infrastructure not being there.This kind of technology allows us to make stuff that can’t easily be shoehorned into pre-existing “game genres” like beat ’em ups, adventure games, RPGs, and so on.
So you’ve got things like augmented reality now establishing themselves thanks to mobile phones and tablets, and you’ve got peripherals like Occulus Rift resurrecting Virtual Reality from that early ’90s grave. You’ve got Sony dabbling with Augmented Reality on PS Vita and trying to get people energized and excited about that platform to no avail. What all these things have in common is that there’s no real easy way for a developer to be able to target all that technology here with ‘one codebase’, ‘one app’, through some ‘common’ interface. If you want to make a game/app utilizing all this stuff for most of the mainstream platforms out there (PC/Android/iOS/etc), you better be ready to invest some serious time into delving into every conceivable API there is and trying to work around insane platform limitations. There’s a big window of opportunity here to create a nice, crossplatform way to tap into all these features without having to resort to big, bloated APIs that all have to be duct-taped together to achieve the desired app.
For instance, if you want to develop a native app for Android right now that utilizes the camera and location services, you can forget about any easy NDK API interfaces being there. It’s all on the Java side and you’re just expected to come up with a big ‘hack’ which of course is not published anywhere. I had a look at the way OpenCV made camera access from the NDK possible and it just was not what I wanted – it was basically a big hack job in native land that would never really be scaleable and would require continuous maintenance. I also didn’t like how I needed to pull in this big monstrous SDK just to be able to access the camera.
So we came up with our own solution for this. It’s a basic JNI shim job and it’s compatible from Android 3.0 up to the latest Android version right now – 184.108.40.206. And it’s very, very fast. You basically pass a GL texture ID from C land to the RetroArch Java frontend side – it uses this ID for binding the camera framebuffer texture, and from there you can do with this camera texture whatever you want from within the confines of your libretro app.
We have made an example core that can instantiate a large amount of cubes with each face showing the camera screen. The only dependencies here are that it’s a libretro GL core, and that it runs from within RetroArch Android. There is no dependency on OpenCV, on any external “native C” camera shim driver library, etc.
The same goes for location APIs – it can’t be accessed from the NDK normally.
RetroArch slowly becoming suitable for AR applications
Here is where RetroArch comes in. Just like how input, video, audio have been abstracted and drivers have been written and implemented per platform – so too do we now have camera and location service driver implementations inside RetroArch.
The big plus point here is that you can write a core utilizing this stuff in a very platform-agnostic way – the only thing you have to worry about is implementing a bunch of callbacks, and RetroArch (the frontend implementing the libretro API) does the rest. You don’t have to worry about the Android camera driver behaving differently from the iOS camera driver and vice versa – you don’t have to worry about Android’s location API or the iOS/OSX location API – that all is handled by the frontend, you don’t need to worry about it. But you can still get access to location data streams and camera streams now all the same from within your GL app – with minimal effort.
Just like with the camera, Proofs-of-Concept have been made that demonstrate both GPS functionality working and camera functionality working. They tick all the boxes that to me define RetroArch – cross-platform, portability, fast, and above all, clean and slimline. The camera works on Linux (Video4Linux2), for the Emscripten WebGL port, iOS, and Android. The location interface has two implementations – one for Android (through the Google Play Services), and an Apple implementation that works for both OSX and iOS (in OSX’s case it should be even backwards compatible from Snow Leopard and up). Portability – in that both the camera and the location functionality gets exposed to the core through the libretro API. So the job of having to implement all this location functionality for every platform is totally outsourced to the frontend side – you don’t even have to think for that matter about your app being “for Android” or “for iOS”. Performance in that the camera driver that has been implemented for both iOS and Android is as fast as it could be. You’re simply binding the camera framebuffer to a GL texture ID and then re-routing that back to the libretro core where you’re able to do with this texture whatever you want – you could turn it into a skybox, or you could render it on top of every cube – and even instance those cubes (2 to the power of 16 no less) while still getting very high performance.
I’m fairly confident that with a few more tests we can easily demonstrate the potential of the libretro API to the outside world as something that is far more significant than simply “something that allows you to port emulators in a cross-platform way”, and I’m quite excited about being very close at realizing that goal. Existing users should not take this as a sign that the stuff they care about – emulators/games – is going to play a diminishing role – this is about being all-inclusive, about creating a big entertainment platform that allows the developer to do whatever he wants his multimedia applications to do.
So, where does this leave the emulation side? The stuff most people still care about when it comes to RetroArch? Well, the Mupen64 libretro core has been steadily improving – right now most effort has been focused on improving the Glide64 video plugin. I still would have preferred things to be even more solid at this point but I’d say it is getting close for a first release – people should be aware anyway that this is a continual “Work In Progress” and that improvements will be made on an ad-hoc basis.
Anyway, I can’t quite keep track of all the cores that have been added since, nor do I really know whether it’s wise to dump in the MAME 2013/2010 cores into the main package since the MAME 2013 core alone is 123MB in size. This wouldn’t go down well with a number of users that have complained about RetroArch’s filesize – and the more cores that will get added, the bigger a problem that will be. Perhaps expansion APKs are a temporary solution but eventually I think we will need to have the equivalent of a ‘package manager’ within the app that can pull in cores remotely. I’m not sure who would have to do the hosting though because we already tried that approach once for the Windows port and it turned out to be both unmaintainable and too expensive – server cost-wise.
When the release gets made, I may do a backlog throughout all the updates that have happened this past half year so people have a better overview of exactly is new. Hopefully that time will be soon. As a post-mortem I will follow up the release (when it happens) with a post that covers all the UI improvements (and other improvements) that have been made.