RetroArch next release and more

Libretro Team

By Squarepusher

It’s been a long time since the last release, and it’s been a long time since any news has been posted period.


The relaunch

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 – 4.4.4.2. 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

RetroArch Android – a camera test core that shows a collection of cubes all displaying the camera frame in real-time.
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.

Emulators

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.

RetroArch 0.9.9.7 upcoming + progress

Libretro Team

By Squarepusher

Here is what we have been spending our time on since the last release – and some more project-related progress.

RetroArch 0.9.9.7

Another new version is upcoming.  No, this is not yet the new release with the Nintendo 64 core. No, that won’t be bundled until RetroArch 1.0. In the meantime, there will be a lot more incremental point updates until we arrive at that stage. But there will still be plenty of good stuff in this new release, such as:

  • Dinothawr included (for PC/Android/iOS for now) – see below
  • VBA Next – big performance improvements (see below)
  • VBA-M libretro port (see below)
  • Picodrive updates – improved 32X emulation (see below)
  • Initial per-core config support for Android
  • And more…

Dinothawr – first libretro game built from scratch

Hans-Kristian Arntzen (Themaister) and Agnes Heyer have made a Kickle Kubickle-style game in their spare time that looks a lot like a 16bit Super Nintendo game from the early to mid ’90s.  It has quite simple gameplay mechanics – you control a dinosaur from a top-down perspective that has to free his enfrozen dinosaur friends by pushing them onto lava. It has a rolling soundtrack that is very soothing to the ear and has a definite distinctive style.

Next to the game being nominated at the Norwegian Game Awards 2013, this game is notable in another way – it is perhaps the first example of a game written from scratch for the libretro API. It is written in C++11 and will be ported to all platforms that have a compiler in their toolchain that allows compiling for that standard.

Dinothawr will be bundled with RetroArch Android/iOS starting from version 0.9.9.7. I will have to see how feasible a port to the consoles (and Blackberry) will turn out to be. If C++11 proves to be a problem on those platforms I might have to deprecate the codebase to C++03 or C++98.

 


V

VBA Next performance improvements

VBA Next is a fork of VBA-M with notable improvements in performance. This week it will gain an even bigger performance upgrade thanks to the work of bgK. VBA’s rendering code has always been needlessly inefficient and slow due to its pixel-per-pixel loops. bgK has made a drastic improvement in speed by changing gfxDrawTextScreen to a tile-based rendering approach. This has pushed Final Fantasy 5/6 to fullspeed on PS3/360 and has made many of the games that would not be playable at fullspeed on the Nintendo Wii now run at fullspeed.

Expect similar improvements on other platforms – the iPad Mini/2 can now play games like Sonic Advance 1/2/Mario Advance 1 at fullspeed whereas previously it would be stuck at 52fps or so. Android devices will benefit from the performance improvements across the board too.

VBA-M – libretro port pushed upstream

This is a new libretro port of VBA-M. There have been quite a few improvements made to the codebase since VBA Next was originally forked from VBA-M. This port (which is GBA-only for the time) has been pushed upstream to the official Sourceforge repository. The tiled rendering rewrite of gfxDrawTextScreen (by bgK) has also been pushed upstream – it can be optionally compiled in by defining -DTILED_RENDERING.

There are quite a few changes between VBA-M libretro vs. VBA-M standalone:

  • Built-in vbaover.ini file – vbaover.ini not necessary
  • Savestates/SRAM/battery is memory stream-based instead of file I/O based – this drastically speeds up read/writing. Plus it allows for nice things like real-time rewind.
  • It is GBA-only for now – GB/GBC/SGB support has not been built in (I am unsure if this would even matter).
  • flush_samples has been rewritten to be more optimal – assume that we will always use the length parameter of the audio driver write method instead of catering to old legacy audio drivers – don’t block inside flush_samples
  • SRAM/Battery autodetection/handling was broken by design in Visual Boy Advance/VBA-M – this has been corrected. There is also a way of converting back and forth between ‘fixed’ VBA Next-style saves and VBA-M saves (compile gbaconv.c as a separate program – available in the repository).
  • All the other advantages of a libretro port

MAME 2010 and MAME 2013

R-Type (a fellow contributor to the project) has done some noteworthy stuff as of late. I have worked together with him on libretro ports of MAME 2010 (MAME 0.139) and mainline MAME (0.150). Right now, this libretro port only caters to PC and Android so far – other platforms will have to be looked at in time.

MAME 2013 (MAME 0.150) should be fully playable right now on Linux and Windows. Here are some features:

  • No SDL anywhere. Uses libco for threading.
  • No stupid “web server” baked in for “frontend duties”. Quite easily the most stupid decision in emu land ever this year. I didn’t even want to believe this is what they did but they did (for 0.150). Let’s just hope this won’t become ever harder to “bake out” from 0.150 and up – it is stupid shit like this that leads to projects getting forked, libav/ffmpeg-style.
  • We autoconfigure a great deal of games with ‘proper’ joypad controls. For instance – Killer Instinct 1/2 default to SNES-style layout on the RetroPad, ditto for the Mortal Kombat games. Tekken 1/2/3/Tag/Soul Calibur/Soul Edge all have their controls mapped the same as a default PlayStation-style pad. These are by no means the only games we have autoconfigured, however. If the default preconfigured controls are not to your liking, you can also use MAME’s OSD system (triggered by pressing RetroPad R2) to reconfigure the controls to your liking – it will save the controller changes in a MAME config file and this will be applied at startup when launching the MAME core.
  • OSD is available and fully functional (triggered by RetroPad R2). There is also RetroKeyboard and RetroMouse support.
  • Cave SH3 drivers have been baked in again. In case some kind of shitstorm erupts over this – here is my stance. Cave officially exited the arcade game business – they have no leg to stand on with regard to “demanding this stuff be not included”. Preservation of arcade hardware can not just have arbitrary “end dates” just because certain manufacturers don’t like it. There is no more money to be made in arcades to begin with – find other viable solutions for your ailing business instead of falling back to a scene (arcade scene) that is all but six feet under (and counting). And no, iOS ports don’t count and are a mere shadow of their former arcade selves. Touch controls are a total disgrace to bullet hell shooters.

It should be pretty easy to sync with MAME mainline. A MESS/UME port might also be considered in the future.

Here is a video somebody took of Ridge Racer running nearly at fullspeed on his Core i5 PC with a CRT shader enabled. I assume if he got a somewhat higher-specced PC this game would be plain sailing at fullspeed. System requirements have gone up even further still since 0.139 (MAME 2010) though – so there is no telling if performance will decrease even more over time.

 

Let me just reiterate that these games run like a dream on RetroArch. It is quite something to see Killer Instinct 1/2/Tekken Tag/Soul Calibur and co run on MAME libretro with RetroArch.

Picodrive updates

Picodrive has received numerous improvements to its 32X emulation code since it was first launched earlier sometime ago on iOS/Android.  Lasers should now show up in Star Wars Arcade on ARM-based systems, games like Metal Head should now work, and more besides.

Gifts

Thankfully, gifts are still coming in. For instance, an Xperia Play has arrived – so I can finally develop for this thing. I have found that the thing can be made to run quite well – at least on-par with a Gamecube/Pandora 1GHz model. You just need to set refresh rate to 59.19Hz, disable threaded video, and (most importantly) set audio latency to 128ms. With these settings, you should be able to play most cores at fullspeed except for SNES9x Next/SNES9x and other more demanding cores like VBA Next.

The RetroArch Android port has received some Xperia Play-specific additions – for instance, it now autoconfigures these settings at startup when running RetroArch Android for the first time on the device. There are still some input problems to do with touching certain regions of the gamepad – which for some reason will trigger AKEYCODE_BACK. I think I can overcome these issues by writing a custom Native Activity implementation explicitly for Xperia Play and then just preventing AKEYCODE_BACK from exiting the application altogether.

I was also gifted an Ouya by developer d6s (author of the Nostalgia app on Ouya) and ToadKing was gifted an Ouya by develper littleguy (from the Mupen64 AE project). We should now have the means to develop and publish the RetroArch app inhouse. We will let you know when we are finally at that stage – it involves transferring over some credentials from the previous custodian. I will also implement hooks to the Nostalgia app so that the author of that app (d6s) can have an easier time launching RetroArch games from his frontend.

Other gifts which will be arriving – a Raspberry Pi by libretro forum member Vanfanel for one, and we also got approached by iBen who offered sending an iBen L1. I will inform people when that happens.

All these gifts are for the sole purpose of improving RetroArch hardware/peripheral support and to ensure that these devices are configured properly out of the box (since for most of these Android devices it unfortunately requires tinkering with audio/video settings to get it running just right).

Surface RT – RetroArch RT port

I am also occasionally still taking money out of my own pocket to allow the project to grow. For instance, next week I will be buying one of these Microsoft Surface RT tablets for the sole purpose of bringing RetroArch over to Windows 8/Metro/RT/Phone.  Yes, I know the Surface RT was a big flop, that it only has a puny Tegra 3 SoC, that the successor is already unveiled and that it doesn’t even allow for dynarecs. I am only interested in the device for the sole purpose of adding yet another platform under RetroArch’s belt.

It will also be a good opportunity to try to  use ANGLE as a wrapper for OpenGL ES 2 so that we can bring libretro GL ports over to Surface RT, Phone, Xbox 360 without having to write some kind of Direct 3D 9/11 interface around the libretro API which – really – we really don’t want to do. ANGLE is already used on Windows for translating WebGL calls to Direct 3D 9/11, so it already has been stress-tested well to that degree. Now here is hoping that API overhead is negligible.