Mednafen/Beetle PSX has made another significant stride forward! iCatButler has contributed a working backport of PGXP for Mednafen/Beetle PSX.
PlayStation rasterization issues
Several issues can be noticed in most PlayStation games’ graphics.
Mednafen/Beetle PSX has made another significant stride forward! iCatButler has contributed a working backport of PGXP for Mednafen/Beetle PSX.
Several issues can be noticed in most PlayStation games’ graphics.
RetroArch keeps moving forward, being the reference frontend for libretro and all. Here comes version 1.3.6, and once again we have a lot to talk about.
Windows/Mac/iOS (build only)/Nintendo/PlayStation – Get it here.
Android: You can either get it from F-Droid or from Google Play Store.
Linux: Since RetroArch is included now on most mainline Linux distributions’ package management repository systems, we expect their versions to be updated to 1.3.6 shortly.
I will release versions for MacOSX PowerPC (10.5 Leopard) and 32-bit Intel MacOS X 10.6 (Snow Leopard) later on, maybe today or tomorrow.
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.
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.
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.
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.
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.
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.
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).
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.
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).
User leileilol contributed a very cool feature to TyrQuake, Quake 64-style RGB colored lighting, except done in software.
To be able to use this feature, you need to create a subdir in your Quake data directory called ‘maps’, and you need to move ‘.lit’ files to this directory. These are the lighting map files that the Tyrquake core will use in order to determine how light should be positioned.
From there on out, you load up the Tyrquake core, you go to Quick Menu -> Options, you enable Colored Lighting. Restart the core and if your files are placed correctly, you should now see the difference.
Be aware that in order to do this, the game renderer shifts to 24bit color RGB rendering, and this in turn makes things significantly slower, although it should still be fairly playable even at higher resolutions.
View the image gallery here.
To download this, go to ‘Add Content’ -> ‘Download Content’. Go to ‘Tyrquake’, and download ‘quake-colored-lighting-pack.zip’. This should extract this zip to your Downloads dir, and inside the Quake directory. From there, you can just load Quake and the colored lighting maps should be found providing the ‘Colored Lighting’ option has been enabled.
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.
There is now a separate version for iOS 10 users. Apple once again changed a lot of things which makes it even more difficult for us to distribute RetroArch the regular way.
Dynamic libraries cores cannot be opened from the Documents directory of the app anymore in iOS 10. They can be opened from the app bundle, as long as they are code-signed. This reverts back to the previous behavior of RetroArch, where the cores need to be in the modules directory of the app bundle.
Go to this directory:
and open RetroArch_iOS10.xcodeproj inside Xcode.
Note – you will need to manually compile the cores, sign them, and drag them over to the modules directory inside Xcode.
1. You’d download a core with libretro-super.
A quick example (type this inside the commandline)
git clone https://github.com/libretro/libretro-super.git
This will compile the 2048 core inside
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.
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.
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.
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?
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’.
Version 1.3.4 has just been released.
Builds can be found here.
Old MacOS X builds (PowerPC and 32bit Intel) will be retroactively added soon, since these builds can’t be automated.
This is the simplified ribbon animation shown here. The more advanced one should be fullspeed on any GPU from 2008 and later.
RetroArch 1.3 was just released for iOS, OSX, Windows, Linux, Android, Wii, Gamecube, PS3, PSP, PlayStation Vita and 3DS.
You can get them from this page:
Once again the changelist is huge but we will run down some of the more important things we should mention:
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 –
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.
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.
This core isn’t particularly new – maister has been dabbling on/off with a libretro ffmpeg port for a good two years now. The problem was that up until now it was never really particularly useful except for morbid curiosity.
The main achilles heel has always been that video rendering was software-based through libretro. Software-rendered video is still awfully slow compared to hardware-accelerated rendering, and launching a movie player with no hardware acceleration would definitely not compare favorably to pre-existing media players.
Now that it has made the leap to libretro GL, its usefulness has increased by a lot. The most noteworthy aspect of this core is that there is a core option enabling/disabling temporal interpolation. Through motion blur it will ‘fake’ a higher framerate in movies (fake 60fps).
Another very appealing aspect of the ffmpeg libretro core is (of course) the mere virtue of it running inside RetroArch, which means for ports that have shader support, shader passes can be applied ontop of the image. We’re pretty confident no other movie player right now is offering 8-pass shader stacking right now – never mind it being dynamically configurable from a built-in menu. Also included (an option of most interest to otakus who like to watch anime) is ASS subtitle support.
Despite the very cool nature of this ffmpeg port, it should be noted that this is fundamentally a very backwards way of implementing a movie player. While most movie players are high-latency affairs that depend on buffering and advanced A/V synchronization strategies, this ffmpeg core instead depends on a low-latency frontend (ie. RetroArch in this case) in order to deliver good audio and video. Something which might simply be too tall an order on Android given the high-latency audio/video drivers on that platform.
An attempt will be made by me to get this running on mobiles and anything in fact supporting libretro GL – this might have to involve baking in ffmpeg as a static library since on the mobile platforms ffmpeg is not available or can be installed as a dependency.
All in all, the temporal interpolation option really makes a big difference in the movies I’ve tried it with, and overall it’s an exciting and promising indicator that libretro doesn’t necessarily have to be confined to merely emulators or games.
Here is the second tech demo by maister made to showcase what is possible with libretro GL. SceneWalker is a heavily modified version of ModelViewer.
Instead of loading ‘character models’, its main purpose is to load in ‘scene models’. Once loaded in, you can then walk around these environments from a first-person perspective. It’s possible to move through environments using either the D-pad and/or the analog sticks. Pressing RetroPad B button allows you to jump – this comes in handy with some models where certain obstacles are preventing you from fully traversing the environment.
A great deal of environments already work within this SceneWalker app – the initial ‘placement’ of your starting position is currently a problem in some models since it is possible for you to be ‘dropped’ inside a void space. This happens for instance with the ‘Devil May Cry 4’ street model which makes it impossible to walk around that map.
Other maps (such as Silent Hill 3’s chapel) work fine on the other hand.
Basic collision detection and gravity has been implemented – it mostly works the part for most models.
Below you’ll find some screenshots of some models that we have loaded into this SceneWalker.
Scene Walker right now runs on:
The maximum supported internal resolution at which you can render the models depends on the platform youâ€™re running Scene Walker on. On the mobile platforms we have consciously decided to set the maximum supported resolution at 1024Ã—768 â€“ this should be the native resolution of the iPad 2/iPad Mini and it is doubtful that even on a powerful tablet youâ€™d have much need for 1080p internal resolution anyway.
On PC 1920Ã—1600 is the maximum internal resolution at which you can render these models.
Like all the non-GL based libretro cores, you can apply any amount of shaders that you want.
Scene Model links
Iâ€™m not exactly sure how hard-ball game developers are when it comes to these models â€“ but anyways, there is a lot of source material you can find on the Internet.
Some places that supply them is DeviantArt (search for DeviantArt + XNALara-Â that should show up a bunch).
Another site that Iâ€™ve found includes a lot of useful models is this one (http://thefree3dmodels.com/). Make sure that when downloading a model form there, that it says â€˜OBJâ€™ or something similar. Models that are not in this format canâ€™t be expected to run right now.