I have an HTC EVO 3D phone running Android IceCream. I have tried a Gensoid, NESOID, Snesoid and a couple other dedicated android emulators, and they ran a bit slow. But then I tried RetroArch and it runs much faster on this phone. I was a bit surprised by this. Why does the android version of this multiplatform emu run games faster than some of the dedicated android emus? Snes9xNext vs Snesoid for example.
SNESoid is just a rebranded version of SNES9x 1.43. This is pre-blargg APU and so sound will be vastly worse than SNES9x Next (which is 1.52 territory).
Really, most of these ‘dedicated emulators’ are just basic rebrands of open source emulators. FPSe is cobbled together from bits and pieces of pre-existing emulator codebases as well. It’s a pretty slimy business this whole payware Android emulator market.
Your runtime performance with RetroArch on Android is based on a lot of factors - from the device itself to the screen refresh rate to the additional Java services running in the background. RetroArch uses static audio/video sync which means that it synchronizes against a fixed refresh rate - it does this because it tries to deliver zero frameskip, low-latency gameplay at all costs that is mostly accurate to the real system.
On Android this can cause problems because there is always a garbage collector running and whenever the garbage collector ‘cleans up’ it can cause a stall - and this can in turn ruin the framerate for a brief second or so. You will hear this reflected in a slight audio crack or so. Note that I am telling you this just because of the potential that it might happen - there are devices on which this is not so apparent but it’s a fact of life on Android.
iOS is not running inside a VM and does not have a garbage collector so performance is much more consistent there (read: way better). Blackberry is in the same boat but it has other things weighing against it (OpenAL being a crap audio API for one, Playbook being dead and having no gamepad support). Windows RT I have yet to really base an opinion on - I’ll be trying it later in August. That being said, it already has a couple of big downsides such as no JIT/dynarec support (same as iOS except you can jailbreak that and not have to deal with these limitations).
Our only hope really is that Android keeps improving and that eventually the developer of an app can have more control over the garbage collector and at what fixed intervals it runs - that and that they start chewing most of the fat away from the audio/video latency (audio latency is still very high compared to iOS). Android is too big to ignore but the sad reality is that it is not the best OS for emulation purposes (far from it) and unfortunately there are a lot of people who proceed to blame RetroArch itself for some of these performance issues manifesting when either their device is lacking, they are running way too many stupid Java services in the background OR the garbage collector just happened to be going to town while they were playing their game (and the services running can have an effect on the GC’s cleanup routines as well of course).
Anyway, we try to do the best job imaginable on Android. We aim for frameskip 0 - not auto frameskip like every guy and his dog just settles for on Android.
Much appreciate the prompt and detailed answer Square. That certainly explains a lot. I want to thank you and the rest of your dev team for bringing us this fantastic emulator. I can’t wait til I get my hands on the NV Shield. From what I’ve read It’s supposed to come without all that bloatware and other crap that runs in the background.
And yes, I agree 0 frameskip and some sort of vsync is always the best option if your machine can handle it.