This week will be all about a dripfeed of new cores along with a version bump of RetroArch, which will be needed for some of the new cores that will be arriving this week.
This is an up-and-coming Nintendo DS emulator by StapleButter, and it now has a libretro port. Some of the things that are still not properly implemented is touchscreen/mouse support and multithreading for the software 3D rasterizer, but we will take care of that soon. This emulator might not yet be a replacement for DesMuMe, but it’s quickly progressing so definitely keep your eyes on it, as DesMuMe certainly needs some competition.
You can get this new core on our buildbot. Start up RetroArch, go to ‘Online Updater’, and check for ‘MelonDS’.
For more information on MelonDS, check out its official homepage here.
The MelonDS core is currently available for:
BIOS instructions, etc. (required)
MelonDS requires a real BIOS file in order to work. These need to be placed inside your System directory. If you don’t know where your System directory is, inside RetroArch, go to Settings -> Directories and read where your System Directory is located.
The following three files are all required:
SameBoy is an accuracy-focused Game Boy/Game Boy Color emulator in the vein of Gambatte. We now have a libretro core of it and its author has also helped us earlier with some implementation details, so that is very much appreciated!
Some features that are still missing is savestate support, but we intend to get that done soon.
For more information on SameBoy, check out its official homepage here.
The SameBoy core is currently available for:
BIOS instructions, etc. (optional)
Here is a tiny convenience feature you added – normally SameBoy relies on reverse engineered Game Boy/Game Boy Color boot ROMs in order to load. You can load these instead of the real BIOS file. For this libretro core, instead of requiring you to put these homebrew boot roms somewhere so that the emulator can read them, we have baked these into the core itself. So you don’t even need to put them somewhere in your system directory.
However, if you’d like to override these, you can do that too. Go to your system directory (if you don’t know what this is, inside RetroArch, go to Settings -> Directories and read where your System Directory is located) and put these files there:
Game Boy boot ROM – ‘dmg_boot.bin’
Game Boy Color boot ROM – ‘cgb_boot.bin’
ARM Linux cores!
Our buildbot is now providing fresh new ARM Linux cores for hardfloat configurations! These cores could be used for instance on Lakka-based devices as well as the NES Mini!
Disclaimer: This article was written by Tatsuya79, who has also contributed many improvements to the X-68K core. Developer r-type is the one who made the port
The Sharp X68000 was a home computer released exclusively in Japan in 1987. It was a powerful machine for its time and saw a great number of arcade ports, exclusive titles and doujin (indie) games developed for it, even years after the last model was launched in 1993.
Until now the only way to run Sharp X68000 games in RetroArch was with MAME. Its driver isn’t really the most advanced one and it is quite demanding, excluding many platforms such as smartphones.
Outside Retroarch, PX68k was aimed to be fast enough for that usage. Based on Winx68k, targeting the PSP and ported to iOS and Android by its Japanese developer Hissorii, it was possibly the only X68000 emulator on those platforms. As its development stopped some years ago, compatibility issues due to OS upgrades made its usage rather complicated.
Developer R-Type decided to port it to RetroArch, replacing its old 32 bits based CPU emulation by a 64 bits one from Yabause core. There is also a back end for the cyclone cpu on arm/android but surprisingly it didn’t give any speed enhancement and had more problems than the previously mentioned c68k.
After a common effort to fix various issues resulting from this change (thanks Retro-Wertz), it should now be at the same level of compatibility as the original emulator.
Running some tests on an old Samsung Galaxy S3, where we could barely emulate a 16MHz CPU before with PX68k stand-alone, we now achieve smooth results with a 66MHz setting. This makes it 4 to 5 times faster than before, and the libretro port is probably now the best performing Sharp X68000 emulator you can get for various cheap or old devices.
Testing on an [email protected] with “Akazukin Cha Cha Cha” achieved upwards of 1000fps on the default 10MHz emulated CPU. The same test gives 136fps in RetroArch using the Mame core.
The PX68k-libretro core still keeps the same main limitation of the original: no MIDI emulation. We also need to bring a virtual keyboard back, you can only use real ones at the moment. However, we did make some improvements:
1.) You don’t need to load a particular utility to define the amount of RAM the machine uses any more, there’s now a core option for that.
2.) You can change the CPU speed in real time.
If, like some old DOS games behaved, you encounter one that runs too fast (ex. Arkanoid), you can directly slow down your CPU from a fast 25MHz to the 10MHz clock speed it was programmed for.
We also added some overclock steps as high as 200MHz. High frequencies have the side effect of speeding up the floppy loading time, which is a much welcomed accident on this machine. (100MHz is already a lot faster for that.)
-We made some 8 buttons gamepad profiles which weren’t used that much on the system, but are great for the various Street Fighters II iterations.
You’ll need the bios files, which have been made publicly available by Sharp. Place them in your system/BIOS directory, in a subdirectory named “keropi”. The iplrom.dat and cgrom.dat are necessary, but you do not need the sram.dat. See the core information for a complete list.
L2 button or F12 key brings up the original px68k menu where you can change the inserted disks. They have to be unzipped to be accessible from this menu but can be zipped/archived when launching directly from RetroArch.
After the first boot a “config” file will be generated in the “keropi” folder. You can enter your rom folder into the “StartDir” line to make it accessible from the PX68k-libretro core’s in-game menu.
Sony might have just ended production of the PlayStation3 in Japan as of two days ago, but we are still supporting it for RetroArch regardless! The last stable release for RA PS3 was back in 1.3.6 days, so the remaining diehard PS3 jailbroken users will be glad to hear that 1.6.0 is available for PS3 right now!
We are only supplying the DEX version. We will assume PS3 repackers will be able to make a CEX version out of this.
PowerPC OSX port
It’s also been a long time since we released a new build of the PowerPC OSX port. We have bundled the cores that have been ported to PowerPC inside the main app bundle. To use this version, you need at least MacOS X version 10.5 (Leopard) and a PowerPC Mac.
The Wii port has received stability fixes amongst other things.
Each and every RetroArch release is always a community effort. FIX94 and aliaspider have made numerous improvements to the WiiU version of RetroArch. For one, it has HID controller support now, which means you can use gamepads other than the default Wii U gamepads on it. There is also support for the XMB and MaterialUI menu drivers. There are some graphical touches missing from it such as shader effects though, so don’t expect to see the fancy ribbon animating on the WiiU yet.
Overall, it is a big improvement on what went before. Netplay should also start to work on WiiU.
PS Vita port
Frangarcj has provided patches which fixes the slow file I/O speeds for the Vita port, an issue which afflicts a lot of homebrew on the Vita actually. Menu performance regressions should also be fixed. For instance, the menu was previously erroneously running at 30fps.
Windows version improvements
Windows users now can use the WASAPI audio driver for the first time, which should allow for lower-latency audio. And if that isn’t enough, there is another successfully completed bounty, a RawInput input driver, which should allow for lower-latency low-level input.
The Vulkan renderer has received some improvements. It should now support Unicode font rendering and render certain accented French characters correctly.
There have been several localization improvements. The German and Japanese translations have been updated, and Korean text should finally display properly.
Now here is a real standout feature courtesy of leiradel we are excited to tell you about! RetroArch now has a built-in audio mixer which allows you to mix up to 8 separate audio streams and splice them together with the game’s audio. To put it more simply, this means custom soundtrack support from inside RetroArch!
Currently, there are a couple of limitations here –
1 – The only supported audio files so far are Ogg Vorbis files (.ogg) and regular Wave files (.wav). Over time, there will be more audio codecs supported.
2 – The audio mixer tracks will only play when the game is running. They will not play while inside the menu, unless you turn off ‘Pause when menu activated’ (Settings -> User Interface -> Menu).
3 – You can only mix up to 8 simultaneous audio streams so far. Looping is not yet available, neither is pausing an audio stream or changing a stream’s volume. All of these might be added in later versions of RetroArch though.
Here is a quick demonstration of how you use it:
Here is a changelog of most of the things that changed:
– AUTOSAVE/SRAM – Fix bug #3829 / #4820 (https://github.com/libretro/RetroArch/issues/3829)
– ENDIANNESS: Fixed database scanning. Should fix scanning on PS3/WiiU/Wii, etc.
– NET: Fix bug #4703 (https://github.com/libretro/RetroArch/issues/4703)
– ANDROID: Runtime permission checking
– ANDROID: Improve autoconf fallback
– ANDROID: Improve shield portable/gamepad device grouping workaround
– ANDROID: Allow remotes to retain OK/Cancel position when menu_swap_ok_cancel is enabled
– LOCALIZATION: Update/finish French translation
– LOCALIZATION: Update German translation
– LOCALIZATION: Update Japanese translation
– LOCALIZATION/GUI: Korean font should display properly now with XMB/MaterialUI’s default font
– MENU: Improved rendering for XMB ribbon; using additive blending (Vulkan/GL)
– OSX/MACOS: Fixes serious memory leak
– WINDOWS: Added WASAPI audio driver for low-latency audio. Both shared and exclusive mode.
– WINDOWS: Added RawInput input driver for low-latency, low-level input.
– WINDOWS: Core mouse input should be relative again in cores
– MISC: Various frontend optimizations.
– VIDEO: Fix threaded video regression; tickering of menu entries would no longer work.
– WII: Fix crashing issues which could occur with the dummy core
– WIIU: HID Controller support
– WIIU: XMB/MaterialUI menu driver support
– WIIU: Initial network/netplay support
– LOBBIES: Fallback to filename based matching if no CRC matches are found (for people making playlists by hand)
– LOBBIES: GUI refinement, show stop hosting when a host has been started, show disconnect when playing as client
– LOBBIES: if the game is already loaded it will try to connect directly instead of re-loading content (non-fullpath cores only)
– LOBBIES: unify both netplay menus
– THUMBNAILS: Thumbnails show up now in Load Content -> Collection, Information -> Database
– VITA: Fix slow I/O
– VITA: Fix 30fps menu (poke into input now instead of reading the entire input buffer which apparently is slow)
– VITA: Fix frame throttle
– VULKAN: Unicode font rendering support. Should fix bad character encoding for French characters, etc.
– VULKAN: Fix some crashes on loading some thumbnails
– AUDIO: Audio mixer support. Mix up to 8 streams with the game’s audio.
New Lakka 2.1 RC release!
A new release candidate of Lakka, our popular set-top box solution powered by RetroArch, was recently released!
Please read hunterk’s extensive article on some organizational changes we are making to our popular shaders collection.
Stay tuned for our first official unveiling of the Dolphin libretro core in the upcoming days, as well as releases of OpenLara, PX-68K, Neko Project II, Redream and other new cores! There will also be a survey/poll which will let you decide which cores we are going to port next!
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.
The larger design goal behind Libretro is to make programs modular. To us, modularity means that a program should run from within the confines of a dynamic library, and that it should be possible for this program to then run inside any of the libretro-compatible players that exist out there.
In order to make a libretro core as it stands right now, you need to be familiar with how the API works. There is some obligatory documentation available for this purpose but we understand that API familiarity is still not where it should be, and that to some developers out there looking to get started with libretro, it might be intimidating to get started.
To that end, we are searching for ways to ease the difficulty and learning curve that comes with getting to grips with Libretro. We know that SDL for instance is already heavily used out there by game developers and emulator creators alike.
SDL and libretro cannot reasonably be compared. The entire purpose behind Libretro is to make a cohesive, consistent ecosystem of modular programs that, like a plugin, can be inserted into any frontend player that supports our API. Something like SDL is more generic in that it doesn’t really care what your program is going to be; it just acts as convenient middleware for your program so that you don’t have to write against a myriad of programming APIs across all the various platforms. And while libretro allows for something of that nature too, it does so with distinct design goals in mind that are more or less forced on you for the purpose of a better play experience.
SDL Libretro is a project that was started out by me half a year ago. Back then it was more or less in an unusable state. To date, I had ported a couple of SDL programs already to libretro (like NXEngine), but previously I always did so by manually baking in parts of SDL and then shoehorning the runloop such that it would fit inside libretro. A libretro core’s runloop consists of a ‘lifebeat’ that lasts for exactly one frame, which can pose a problem for many SDL programs, because how the programmer implements the runloop there is entirely up to the programmer, whereas libretro forces this runloop model on you. It does this for good reasons, so that the frontend can easily do advanced operations like fast forwarding, rewinding, etc. But nevertheless, if you have an existing program, it might take time to whip it into shap such that it fits the confines of a libretro program.
Developer r-type has done an awesome job of making SDL Libretro finally a viable project. Right now it exists as a Proof of Concept that works on both Linux and Windows, and to illustrate that it works, r-type has made available three Proof of Concepts to show off SDL Libretro:
An OpenTyrian SDL port
A Mandelbrot game port (using SDL)
A Tetris game port (using SDL)
Right now, this SDL port is obviously in its infancy, and this might be an area where we could make use of further contributions.
To go over some of these:
Because an SDL program can be implemented any number of ways, right now we have to rely on libco in order to implement the main runloop.
Right now we are targeting SDL 1.2.15. There are currently no plans for SDL 2 support, although if we do, it’s likely it would be a separate project.
Lastly, be cognizant of the fact that when we say ‘Proof of concept’, we really mean it. Things are not perfect yet and it will take some time to iron out all of the bugs.
To use libretro SDL in conjunction with your game program, right now you would first build the SDL libretro part. You run the Makefile and once successful, it will create a statically linked ‘archive’ (such as ‘libSDL_unix.a’ and/or ‘libSDL_win.a’). From there, you would manually link this archive into your libretro core. That way, your libretro program can interface against SDL.
If you want to see some test examples of how this is done in practice, go to the directory ‘tests‘. ‘opentyrian’, ‘sdl-mandelbrot’ and ‘sdl-tetris’ are three current proof of concepts.
What does this mean for endusers?
It means that developers familiar with SDL have an easier time getting themselves acquainted with libretro. It also will mean that we can get SDL ports up and running quicker instead of having to reimplement and rewrite everything from scratch.
Right now, my current plan is to take the quick and dirty OpenTyrian port, and divorce it from most of its SDL idiosynchrasies and turn it into a nice, native, fleshed out libretro core. However, at the same time, I also want to help improve, build and foster further work going into libretro SDL. So if anything, we need to strive for even more well fleshed-out tests at the same time.
Credit to r-type
We want to thank r-type a lot for coming up with this wonderful Proof-of-Concept. Without him, this project would have barely stumbled out of the gates and it would have taken many more months for it to end up running anything. Hopefully we can once return the favor for all the hard work and effort guys like this have provided to our project. It’s the passion and the commitment of most of the followers surrounding this project that keeps us going.
One of our goals with getting on Patreon was to experiment with using a bounty system to encourage contributions from outside of the normal libretro/RetroArch/Lakka team, and we’re finally ready to take a stab at it. This is uncharted territory for us, so some of this framework is bound to change as we move forward, but here’s our initial plan:
The libretro team makes all final decisions on bounty allocations and disbursements. While we intend to listen closely to community input, ultimately we have to be able to make the final decisions.
All contributions must follow coding guidelines and meet approval of the libretro team before disbursements will be awarded. We can’t pay out if the code isn’t usable and/or maintainable by us.
Pursuant to #2, potential contributors should contact the libretro team prior to beginning work to make sure the final product will be acceptable. This is intended to avoid misunderstandings and other conflicts. We don’t want someone to work hard on a fix or feature only to find that it’s not going to be acceptable for whatever reason.
We will try to do as much as we can through Bountysource, where we can link specific issues from our Github repos to bounty values. This is especially applicable to smaller tasks. However, it may not be appropriate for all tasks, and we’ll decide how to deal with those that don’t exactly fit on a task-by-task basis.
Pursuant to #4, potential contributors should contact the libretro team and determine an actual disbursement value based on the magnitude and difficulty of the task. We may need to negotiate up or down to find a fair value, based on the contributors’ skillset, or the amount of tutoring needed to get contributors up to speed with the codebases/APIs involved, etc.
Disbursements can be made in the form of cash payments, the purchase of hardware for development and/or testing, etc. We want to be able to help developers with whatever they need. Sometimes that will be in direct payments, other times it may be in specialized hardware for porting/maintaining or reverse-engineering or whatever.
Again, this framework is a work-in-progress, so if you have any questions or concerns, feel free to contact us, either on Github or in #retroarch on Freenode IRC.
On Android, you can expect version 1.5.0 to be downloadable on the Google Play Store later today. If you want to install the APK manually, you can do so by downloading it from the URL linked to above.
Changes since last version (1.4.1)
MOBILE: Single-tap for menu entry selection
MOBILE: Long-tap a setting to reset to default
ANDROID: Autoconf fallback
ANDROID: Mouse support / Emulated mouse support
AUTOCONF: Fix partial matches for pad name
CHEEVOS: Fix crashes in the cheevos description menu
CHEEVOS: WIP leaderboards support
COMMON: Threading fixes
COMMON: 9-slice texture drawing support
CORETEXT/APPLE: Ability to load menu display font drivers and loading of custom font.
DOS: Add keyboard driver
DOS: Improve color accuracy and scaling
GUI: Various settings are now only visible when advanced settings is enabled
GUI: Allow changing icon theme on the fly
GUI: Add a symbol page in the OSK (Onscreen Keyboard)
GUI: Better dialogs for XMB
LOCALIZATION: Add/update Korean translation
LOCALIZATION: Rewrite German translation
LOCALIZATION: Update several English sublabels
LOCALIZATION: Update several Japanese labels
NET: Allow manual netplay content loading
NET: Announcing network games to the public lobby is optional now
NET: Bake in miniupnpc
NET: Fix netplay join for contentless cores
NET: LAN games show next to lobbies with (LAN) and connect via the private IP address
NET: Use new lobby system with MITM (Man In The Middle) support
NET: Fix netplay rooms being pushed on the wrong tab
NUKLEAR: Update to current version
SCANNER: Always add 7z & zip to supported extensions
VULKAN: Find supported composite alpha in swapchain
VULKAN: Add snow/bokeh shader pipeline effects – at parity with GL now
WIIU: Keyboard support
WINDOWS: Logging to file no longer spawns an empty window
WINDOWS: Fix loading of core/content via file menu
We’ll go into some of the important features in more detail below.
UPNP support out of the box! (Windows/MacOS/Linux/Android/iOS)
Previously, in order for netplay to work, you as the hoster would need to manually port forward on your router. Starting with version 1.5.0, RetroArch now supports UPNP out of the box! If you have a home network router that supports UPNP, you should now be able to host netplay games without having to manually open ports on your router!
NOTE: The platforms that come with UPNP support out of the box as of this point includes: Android, MacOS, Linux, iOS, and Windows. If you have a version of RetroArch for any other platform, it’s likely it does not have UPNP support, and therefore you would still need to fallback on manual port forwarding if you want to host a game.
An often-heard complaint was that touch navigation on mobile devices was not intuitive enough. You had to double tap in order to select an entry instead of being able to single tap which is the norm for most mobile programs out there.
We have changed this so that you now only have to single tap. Also, you can now ‘long-tap’ a setting in order to ‘reset’ it to default. This is useful in case you are tinkering with some setting using touch and you want to set it back to its default setting.
Other new features – changing the icon theme now works on-the-fly, so you no longer need to restart RetroArch for these changes to take effect.
Android controller detection improvements
If RetroArch cannot find a preconfigured entry for your gamepad on Android, it will now try to use the Android standard default controls for the gamepad instead. This should help with a bunch of gamepads that are lacking a current autoconfiguration file, and should prevent the user from having to manually setup the controls.
Previously, the menu effects ‘Snow’ and ‘Bokeh’ were not available if you were running RetroArch with the Vulkan video driver enabled. Now you can use them with Vulkan as well!
In case you don’t know how to access these, go to Settings -> User Interface -> Menu -> Menu Shader Pipeline.
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 –
RetroArch has now been ported to Windows 98SE/2000 as well as DOS. These are very early work-in-progress ports but in their current state do allow you to start up RetroArch and load a core/game.
For Windows, the current releases and nightly builds do not support XP or below due to changes in the msys2/mingw toolchain. While older Windows versions are indeed supported by the RetroArch codebase, they need to be manually compiled with Visual Studio (Express or Pro) to run properly. For XP and above, Visual Studio 2010 is supported. The solution/project file is located in the pkg/msvc folder of the source along with older msvc solutions. For Windows 98/2000, we support Visual Studio 2005. A DirectX 9.0c SDK is also required, and in order to target 98, a version no newer than December 2006 must be used.
The Windows 98/2000 port may work with our existing OpenGL driver if your graphics card supports a high enough version of OpenGL, but this has not yet been tested. So far 98/2000 has only been tested against a new experimental GDI video driver which does not require hardware acceleration like OpenGL or DirectX (the GDI driver works on newer Windows versions as well). With the GDI driver, the RGUI menu is fully supported and there is also preliminary support for XMB with minimal (text-only) rendering.
For input/joypad and audio support on 98/2000, the DirectX 9.0c runtime should continue to work as it does with newer Windows versions. Windows 98SE requires a DirectX runtime no newer than December 2006, and Windows 2000 can go up to February 2010.
Cores for 98/2000 will also currently need to be compiled manually due to the mingw toolchain used by the buildbot. It’s possible that we may setup a new buildbot target for the older Windows ports at a later date.
The DOS port requires DJGPP to compile (we cross-compile from Linux), and also requires the CWSDPMI server included with that toolchain to access 32-bit protected mode. An experimental “Mode 13h” VGA driver is implemented to provide 320×200 video with 256 colors. Keyboard input support is currently very minimal, only the A/B/X/Y, Start/Select and arrow keys work. There is also no audio support yet.
Cores for DOS will need to be compiled manually, as well as statically linked with RetroArch itself, similar to how our console ports work. This means that a compiled RetroArch EXE file will correspond to just one specific built-in core. FCEUmm and Snes9x2010 are known to work, but due to the default timer tick in DOS being 18hz, gameplay is currently very slow. Work is ongoing to reprogram the interrupt timer which should allow full speed gameplay.
No release yet! You have to compile from source, and things are still very much a Work-In-Progress!
Compilation instructions will be added at a certain point on our Documentation site.