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

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

MelonDS

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

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

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

Available for

The MelonDS core is currently available for:

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

BIOS instructions, etc. (required)

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

The following three files are all required:

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

 

SameBoy

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

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

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

Available for

The SameBoy core is currently available for:

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

BIOS instructions, etc. (optional)

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

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

Game Boy boot ROM – ‘dmg_boot.bin’

Game Boy Color boot ROM – ‘cgb_boot.bin’

ARM Linux cores!

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

You can grab them here:

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

Miscellaneous updates

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

What’s still coming up this week?

In no particular order:

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

New Core: PX68k (Android/iOS/Windows/Linux/Mac)

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.

SDL Libretro Proof of Concept

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

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

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

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

SDL Libretro

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

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

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

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

To go over some of these:

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

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

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

What does this mean for endusers?

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

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

Credit to r-type

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

Introducing the Bounty System

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:

  1.  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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

RetroArch 1.5.0 – Released!

RetroArch 1.5.0 has just been released!

Where to get it?

You can get the latest version here.

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

Changes since last version (1.4.1)

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

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

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

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

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

Menu improvements

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

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

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

Android controller detection improvements

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

Vulkan improvements

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

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

Happy New Year!

We at Libretro wish you all a happy New Year! 2016 has been quite the year for Libretro as a project, so let’s briefly recap where we stand at the end of this year and what we managed to do in 2016 –

First with Vulkan

We were one of the first programs to ride the Vulkan wave, and we managed to add Vulkan support to RetroArch since Day One of the new graphics API’s release.

Continue reading “Happy New Year!”

We are now on Patreon!

unnamed

The Libretro Project (comprised of Libretro, Lakka, and RetroArch) is now on Patreon! We hope this Patreon will enable us to accelerate development and be able to serve users in lots of benevolent ways!

Visit us here: https://www.patreon.com/libretro

This Patreon covers the Libretro, Lakka, RetroArch projects. And another, soon to be disclosed project as well.

Right now we are at $230 as of this minute. We thank every Patron so far that has helped us get to this stage in such short time, suffice to say you won’t be let down! Let’s go over some of the goals as they stand!

$150 – Bounty for core work every month! Reached!

Already the $150 goal has been reached which will allow us to place bounties for core work to be done! We allocate a total of $50 / month that will go towards bounties.

$200 – ProjectFuture Greenlight! Reached!

I will be revealing soon what this project is about. Let’s just state it’s going to be an even bigger and more expansive project than RetroArch has been so far, and it’s one of the main reasons why we finally went ‘why not?’ with regards to the Patreon. Stay tuned!

This is going to take months and months of work, and will take other considerable resources in order for us to be able to see it to completion, and it’s definitely one of those ‘flying very close to the sun’-type endeavors, but as with everything with this project, ‘dreaming big’ and ‘foolhardy’ are comfortable bedfellows.

$400 – Netplay/matchmaking server!

We want RetroArch users to be able to play online multiplayer games with each other through the RetroArch interface. We are going to allow for PSN/XBLA-like features, except free of charge! The prospect of true crossplatform free netplay from an easy and console UI-style interface is soon to be within reach once we hit this target!

The aim is that every user will be able to quickly and easily setup a netplay game from within RetroArch without the need of a keyboard/mouse! We want console-style netplay ease of use !

$500 – Stability checks, Quality Assurance, etc!.

It’s no secret that for years we have relied on volunteer work in order to get where we are. This entire project entails a maddening amount of work that we have to put in on a daily basis to keep the entire show up and running, and the amount of work keeps growing every time we add another platform port or add a new core.

Once we hit our $500 target, we are going to be paying a couple of developers whom have been loyal towards the project to keep tabs and checkups on RetroArch and various libretro-related cores on a bi-monthly basis. This way, bugs and regressions are easily spotted and we can instantly fix them.

$600 – Development bounties!

We are going to be posting bounties for various remaining issues (whether it be RetroArch or cores), and any developer will be able to fix these issues and claim the reward!

Finally we can start claiming bounties for some of the things that RetroArch and Lakka might still be missing! Good developers don’t grow on trees, neither do contributors. We hope that through these bounties we will be able to significantly improve the software and get to our goals much quicker!

NOTE: The amount of money that will be allocated for this is variable and decided at our own discretion.

A RetroArch retrospective and what to look forward to

I have been following the events on a few libretro related threads in reddit and I find it quite disappointing to see the amount of hatred directed to a project that has done nothing but do what end-users wanted for more than three years now. I also find it terrible (but interesting none the less) that the social media post is more active than the actual highlight.

Disclaimer: this represents my own experiences and my points of view with regard of the situations that surround our project.

Anyway…

A bit of my personal history with the project:

Let’s look back all the way to 2013. RetroArch was still called SSNES, a fairly small commandline program with just a few cores, a launcher that could be used to adjust options and that’s it. No bells or whistles, just a few nice cores implemented under one frontend with a common feature set. I hadn’t really been using emulators since the zSnes days other than a few tries with mobile emulators on my WinCE device.

I just had built a game-room / tv-room. So I setup XBMC and loved it. Soon I started looking for emulators that would work nicely with my setup. I installed Nestopia and some XBMC plugin that acted as a launcher with worked mostly fine. I liked the emulation but I also like the fact that I could set hotkeys to save, load, and it presented nice OSD messages on non-game actions and I could drive the whole thing with my gamepad only. I hoped other emulators would have the same features but I was let down almost instantly. Regardless I pursued my objective with a miriad of tools (Pinnacle Game Profiler, Xpadder, Joy2Key, batch files, Daemon Tools to name a few).

Continue reading “A RetroArch retrospective and what to look forward to”

RetroArch 1.3.6+ beta release for PlayStation3!


The PlayStation 3 port is back after it was decommissioned for a long time. Consider this a beta version in anticipation of the upcoming 1.3.7 version which will be further fleshed out.

Also check out our concurrent release for the PS Vita:

RetroArch 1.3.6+ beta released for PS Vita (HENkaku-ready)!

Thanks to PSGL, the PlayStation3 driver can use the XMB menu driver using the OpenGL rendering backend. The simplified ribbon should be running properly in the background too.
Thanks to PSGL, the PlayStation3 driver can use the XMB menu driver using the OpenGL rendering backend. The simplified ribbon should be running properly in the background too.

Continue reading “RetroArch 1.3.6+ beta release for PlayStation3!”

Mednafen/Beetle PSX HW – Alpha test version

Parasite Eve with the experimental GL renderer. Note the screen residue glitches at the bottom.
Parasite Eve with the experimental GL renderer. Note the screen residue glitches at the bottom.

Here is the first release of Mednafen/Beetle PSX HW. You can download this core right now for Windows, Linux, and OSX.

NOTE: THIS IS AN ALPHA VERSION AND IT IS NOT REPRESENTATIVE OF THE UPCOMING BETA VERSION. PERFORMANCE RIGHT NOW IS A LOT LOWER THAN WHAT IT WILL BE FOR THE BETA VERSION. EXPECT BUGS TOO.

See a complete screenshot gallery here.

Where to get it?

Rage Racer using experimental GL renderer
Rage Racer using experimental GL renderer
Final Fantasy VII using experimental GL renderer
Final Fantasy VII using experimental GL renderer

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

Continue reading “Mednafen/Beetle PSX HW – Alpha test version”