By Squarepusher –
Despite this being a point release, a couple of very important changes have been made regarding the Android port, which made me compelled to make this blog post so that I can explain some of the things that have changed.
New cores added
People always love this part – especially the Xperia Play guys who are ever struggling to hold onto ever-decreasing internal storage on their outdated devices 
.
First up is a new core – Picodrive. This has been closed-source for a fair while because notaz didn’t like guys like certain guys profiting from it through iPhone ports with donation buttons. With libretro and RetroArch now out, there s justifiable reason to open source it again since the payware/donationware guys are going to be on the run from now on.
Picodrive is a Sega Genesis/Sega CD/Sega 32X emulator especially optimized for ARM processors. It is the fastest Mega Drive emulator in existence for ARM-based devices like Android and iOS. Best of all, it comes with a 32X core which should run most games at fullspeed even on a weak ARM Cortex A8 CPU. There is only one game that has somewhat higher system requirements (Virtua Fighter 32X). An iPad Mini/2 runs this game at 56~57fps – about two FPS shy of fullspeed – your mileage may vary on how it performs on [insert your device]. It runs fullspeed on the Nvidia Shield though.
What else is new? A Stella core – this is an Atari 2600 emulator. We already bundled this for the iOS port but I guess we neglected to add it to the Android port up until now. Anyway, here it is.
Anything else besides? SNES9x mainline – ie. not the Next speedhacked version. Use this if you have a beefy device and think you can get away with a non-speedhacked version of SNES9x. It runs at fullspeed with all games on the Nvidia Shield – your mileage may vary on how it performs on your device. This version of SNES9x is more accurate than SNES9x Next- but is also a lot slower.
We also threw in the Desmume core – Nintendo DS emulator – with meancoot’s ARM JIT backend. It runs pretty much the same as the iOS port – no, it’s not going to be giving that payware closed-source emu Drastic any run for its money and it’s just thrown in for the ‘ah what the heck’ factor – its main usefulness as a libretro core is on the PC – but seeing how fast ARM hardware is catching up with even laptop Core processors, perhaps it will only take another year or two until ARM devices are at the level of a Core i5 – so we will keep it on life-support until then.
I felt it was also time to throw in Mednafen PSX – an alternative PlayStation1 emulator. Users of the PC version will know this emulator – it’s one of the most accurate open-source PS1 emus around right now. It’s always been deemed as totally unsuitable for ARM devices since it has such high system requirements – however, the Nvidia Shield is showing that there is reason for optimism. On Shield it hovers right now between 35 and 40fps with occasional spikes to 44fps. Give it some time with stuff like ARM Cortex A57 coming out and who knows if this will be able to run at fullspeed. So – it’s included by default from now in anticipation of that.
For practical purposes – it is recommended you keep using PCSX ReARMed. Don’t complain to me that this core runs too slow.
There is one other core which has been added – Instancing Viewer. This is another GL tech demo that is meant to show off instancing being done in GL. Load it up with any PNG image file and it should be rendered on a bunch of cubes – you can look at them from a firstperson perspective. You can increase the cube amount by going to RGUI->Core Options and increasing cube size. Note that the cube sizes are to the power of two – so 8 is 2 ^ meaing 256 cubes. There is no practical gameplay purpose to this right now – it’s just a Libretro GL tech demo. It might become something more useful later on.
No more static syncing by defaultWe now enable the threaded video option by default. There have been a couple of improvements to it in that it now applies adaptive jittering which should make the jittering less apparent.This option should lead to audio crackle-less gameplay on most devices. Of course, there is still the option to use static syncing and we certainly recommend its use if you know what you are doing and can set the ‘refresh rate’ in the RetroArch app to exactly match that of your display source’s refreshrate. This option just turned out to be too difficult to setup for most users and because any refresh rate mismatch in RetroArch leads to audio/video sync being incorrect, this would manifest itself in audio crackles and lead to a broken user experience.On a platform like iOS, this is simply no issue. On Android unfortunately it is. Therefore, we are playing it safe here. Upon starting up RetroArch Android for the first time, it will ask you whether you want to use threaded video or whether you want to ‘synchronize by refreshrate’. By choosing the latter option you get the old way of how things worked.
NOTE: Static syncing should work fine on nearly all libretro cores. However, there has been one annoying exception, and that is PCSX ReARMed. Certain games (like Chrono Cross, FInal Fantasy VII, Crash Bandicoot 1, and lots more) use variable refresh rates instead of running at a fixed refresh rate. This seems to play havoc with RetroArch Android’s way of doing static syncing right now (it is not a problem on iOS however). Enabling threaded video solves all these problems overnight, so we recommend that if you have your ‘forced refreshrate’ set up right, that you set ‘threaded video’ off for the PS1 fighter games like the Tekken games, Tobal games, Street Fighter games and others – ie. games that are guaranteed to run at 60Hz. For everything else, turn on threaded video for now.
Appeal to low-latency audio in Android 4.1 and up
There have been changes to the OpenSL audio driver to target the new low audio-latency capabilities of Android 4.1 and up. This should lead to much better results where the audio isn’t as hopelessly behind the video like it was in previous releases (which really wasn’t our fault but more due to us having to deal with the awful state of Android’s audio capabilities prior to 4.1 and up).
We are aware that people with sub-Android 4.0 devices (and even 4.0 itself) will likely get regressions because their Android version can’t possibly deal with low-latency audio buffer sizes. Unfortunately, there’s no getting around the fact that Android was really fundamentally broken on many different levels up to maybe 4.1 and 4.2. Things certainly have been improving a lot since then, and it makes no sense for us to keep appealing to the lowest common denominator when those phones/tablets are all going to be replaced in the near foreseeable future anyway (and they should). There’s also no point trying to upgrade most of these outdated devices (like the Xperia Play) to the latest Android version because the system requirements of newer versions of Android won’t allow for it. RAM requirements for instance have gone through the roof since Android 4.0 and up, and so it cuts off all older devices with only 512MB of RAM (and even less).
If the demand is high enough on these old outdated devices, we might introduce back a ‘high-latency audio’ option. For this release, we are trying to cater to the crowd that bought devices this year and one year ago. We believe that is the right strategy here.
NVidia Shield support
So we received an Nvidia Shield from Nvidia (two in fact – one for me, the other for Themaister) and we are certainly walking away with a higher overall impression of Android now. There are still problems, but they seem at least surmountable now. John Carmack in a recent QuakeCon talk has spoken about some of these issues, but really, it doesn’t take a rocket scientist to fire up adb and look at Logcat and see the pages and pages of garbage collector stalls passing by to sense there is something architecturally very wrong going on with this OS from a high-performance games machine perspective. How Google is ever going to fix this and bring it at parity with iOS on most devices is frankly Google’s problem.
Returning back to Shield for a minute – I am pleased to announce I’ve gotten much more consistent runtime performance results on it than any other Android device so far. Regarding the performance of it – it’s insane – I’ve done a lot of performance tests over the past few days and so far it’s definitely the most powerful ARM-based device I’ve used.
http://t.co/nZDSmzpjec
Really, people like to deride the device for the Xbox 1 Duke-esque form factor and the high price, but really, I consider this a much better ‘micro console’ than something like Ouya or GameStick so far. (more on the Ouya stuff later). In fact, I’d say that using it as a RetroArch console alone is worth the cost for $299 – building our own RetroArch console has been a thing on my mind for sometime but really – there’s no way we’d manage to do a better job at that pricepoint than Nvidia themselves and certainly not with such hardware inside it. So let’s hope they are successful. I am certainly a believer so far.
And yeah, GPU-wise it still might not be at parity with a PS3 or 360, but CPU-wise? It slaughters a PS3 or Xbox 360. Really, I’ve been stressing this for years and it seems to have only recently been gaining traction after Mark Cerny and co have started admitting how bad the Cell was (he didn’t say that exactly but it’s fairly obvious that is what they are referring to beyond all the media training) – the per-core performance of a Cell-based CPU (this includes both Xenon CPU in 360 and Cell in PS3 itself) was something like a Pentium 4 2.4GHz CPU. It exhibited most of the same problems – deep pipelines, high penalties (to the tune of 500ms L2 cache misses – goddamn!), and to top it all off, in-order execution (and a bunch of SPUs in PS3 which are useless for general-purpose code and with too little local storage).By comparison, anything based on an ARM Cortex A15 design (like Nvidia Shield) is happily blazing past a Core 2 Duo – which has a level of IPC that a PS3 or 360 could only dream of. So really – if this is about a ‘comparison’ between the current-gen consoles and something like Shield, then the current cream of the crop of micro-consoles already wins out by a fair margin when it comes to CPU power – and then some. I have no doubt that Tegra 5 will exceed PS3 RSX/360 ATI performance levels and from there it’s basically a race to catching up with the next-gen consoles.
Long story short – this is no moneyhats – I consider this the RetroArch handheld games console I wanted to build from the onset and which none of the el-cheapo tablets/phones ever delivered.
Improved input support – analog stick support
Coinciding with the support for the Nvidia Shield gamepad, we have improved input support in a number of big ways –
Analog stick support
Some cores (like TyrQuake, SceneWalker) already have native analog stick controls – however, RetroArch Android never exposed analog stick support – up until version 0.9.9.4 now that is. Devices like the Nvidia Shield, the Xbox 360 gamepad, the Logitech Rumblepad 2 have all been preconfigured to default to ‘Dual Analog mode’ now. Libretro cores which implement ‘RETRO_DEVICE_ANALOG’ will now be able to make use of the analog sticks on an input device.
We will need more trial-and-error testing to add this functionality to more input devices. Users are encouraged to help us out in this endeavor.
ANR issues fixed (Application Not Responding)
So it turns out that the ever-reliable Google had a bug in their native activity glue code input code that was causing the input buffers to become congested and then start issuing ‘Application Not Responding’ events to the application if an input event had failed to be picked up on for over more than 5 seconds.
It seems Nvidia picked up on this issue earlier and made a blog post about it – which is the only reason I have been able to fix it for this release. According to the changelogs, Google has fixed this issue now in their code for the latest NDK version. Unfortunately for them, the latest NDK version seems to be a totally broken regression city fest where at least half of the cores that used to compile fine previously now issue ‘Internal Compiler errors’ – so I was forced to use NDK r8b either way.Speaking of which – to any and all devs reading this stuff – here are the links which hook you up – Google doesn’t seem to provide an archive of their previous NDK versions (even though they should) but luckily Nvidia still has a mirror up for it – so here goes –
https://t.co/P5poAtsS0e (NDK r8b for Linux x86_64)
https://developer.nvidia.com/content/nativeactivity-input-crashes-and-anrs-simple-fix-dangerous-bug (NativeActivity Input Crashes and ANRs: A Simple fix for a Dangerous Bug)
Input devices fixed (Xbox 360, iPega PG-9017)
Thanks to generous gifts, I was able to fix a number of input devices. First and foremost is the Xbox 360 pad – the D-pad hat controls should now be properly working. Analog stick support for DEVICE_RETRO_ANALOG has also been added.
Two modes for the iPega PG-9017 have also been added. Set iCade Profile in Settings->Input to either of the two iPega options to use them with RetroArch.
Ouya Store (??)
Some guy has registered on our forum a few days ago and has been talking about wanting to bring this over to the Ouya Store.
We don’t have an Ouya, are likely not to get one unless somebody gifts it ($99 for an Android-based Tegra 3? no thanks), and the Ouya Store policies are absolutely insane (http://forum.themaister.net/viewtopic.php?id=741&p=2) – a bunch of startup guys thinking they can pull an ‘Apple Store’ in terms of draconian app store policies. So it’s probably a good thing somebody else is going to prostitute themselves before these guys because I quite honestly wouldn’t have the patience for it.
We’ll see what comes out of it.
Anyway, version 0.9.9.4 is out now. Enjoy – we hope that people with more recent Android devices will get a much better experience now with it. The iOS version will come a few days later – most of the work really has been on the Android version for this release.
Download Links
APK (r18) – https://anonfiles.com/file/afb0f033a3f779cb111884400406cd7b
Google Play – https://play.google.com/store/apps/details?id=org.retroarch&hl=en
