My issues with Retroarch

RetroArch Android devices
#1

So, Retroarch is awesome because it comes with cores which you simply can’t find on the play store… BUT… as it seems the online updater only gives you access to cores which are “compatible” with your device or something, the only Sega emulators I can download are crashing when I’m playing Master System games with the FM sound chip ‘On’. So, MD.emu is a must if you want to play those. Mupen 64 is OK but the old N64oid does a much better job. PPSSPP can’t even run the beach tutorial of metal gear smoothly no matter which settings you use, Yabause, 4do and Virtual Jaguar can’t run anything smoothly even with a 2.7ghz CPU so why are they even included? Some of those take you directly to the bios but can’t load games even if you’re using files with the proper extensions but they can’t even run the bios (the system menus smoothly…).

And then, the bios files have to be in a specific folder in the android/data folder if you want them to even boot. The emulator is supposedly set to search for them in the same folder as the ROM you’re loading but it doesn’t.

And then, if you’re using a Bluetooth gamepad and you press the overlay keyboard button to remove the overlay, the back button of the phone becomes inactive. I’ve tried mapping the button but when I do so, I can’t use my gamepad anymore. It’s still mapped but doesn’t work even if I restart retroarch.

And then, there are the menus of the 1.2 version… I understand you’re going to remove the original menus… Fine… but those 8 bit looking menus we have to use now are terrible. A lot of characters overlapping to the point it can become unreadable… And yes, you know there are things to fix but neither your website nor the play store mentioned that you had to actually launch the app a second time within the app in order to get to the settings… and the pictures you’ve added are misleading. It took me about one hour to find a way around all these issues.

In the end, whatever was working before still does but it’s just an awful mess.

Now, just to make it clear, I’m using a galaxy s5 LTE 900f running CM12.1 lollipop 5.1 overclocked at 2.7ghz which I can make stay at 2.7ghz the whole day if I want to for the 4 cores without any thermal throttling or hotplug so none of those issues come from my device being underpowered. My GPU can stay at six hundred something MHz as well so it isn’t the problem.

This is not a rant, only observations.

#2

Performance is more than just clock numbers and often-times reported clock settings are inaccurate. That S5 phone cannot run 2.7Ghz with all four cores maxxed for long before it would burn up. That said, if it WAS running that fast, games should be playing better for you. The 4DO core is playing games perfectly on the Shield ATV and the CPU is only ~2GHz.

#3

While it is true that there are variables, you can trust me when it comes to my device. Considering 4do, I haven’t gone any further than the boot menu with the CD player and the CDs floating in the background but even that was pretty slow. Maybe I’ll try an actual game and report how many frames I get. However, both ‘Virtual Jaguar’ and Yabause are extremely slow and I really don’t understand why they are part of this. Is there anything I missed? Like a plugin or driver which magically make things faster and which are not included or require me recompile the app? But you know, if you know any tips for 4do, I’m all ears.

#4

We haven’t had any time to work on the Yabause core, all our time was spent on RetroArch for at least one entire month.

What the Yabause core right now is missing is a dynarec (because the dynarec is not PIC-compliant which we would need to even be able to use it from within the confines of a dynamic library, so that means more work), and we probably could get a good speed boost by merging the still-not-merged GLES3 renderer, and probably get things to look a bit better.

I’d really wish that you people who make these threads would have any idea about all of the programming and chores involved, because let me tell you, this is a lot of work, sweat and labor put in for next to little to no personal gain at all. So to see these posts then at the end of such a stressful development period is quite honestly dispiriting and demotvating.

#5

The jaguar core options include a fast-blitter feature. With this enabled, many games are enjoyable/playable for me on the Shield ATV. Of the 3 cores you mention, yabause is the slowest. There is a GL-accelerated port in-the-works that is quite a bit faster. An alpha was posted in the Yabause forums a few months ago that shows great promise.

But I really appreciate it when future-looking features are added to the software and games I love. While MAME 2015 core and these cores may be slow today with some games, future hardware is coming that will run them well.

#6

[QUOTE=Reznnate;24631]The jaguar core options include a fast-blitter feature. With this enabled, many games are enjoyable/playable for me on the Shield ATV. Of the 3 cores you mention, yabause is the slowest. There is a GL-accelerated port in-the-works that is quite a bit faster. An alpha was posted in the Yabause forums a few months ago that shows great promise.

But I really appreciate it when future-looking features are added to the software and games I love. While MAME 2015 core and these cores may be slow today with some games, future hardware is coming that will run them well.[/QUOTE]

I made a post about Yabause in another thread. The GLES3 renderer you talked about is not yet merged in upstream, so I want to wait until maybe Friday to see if the upstream guy is finally going to merge it, otherwise I’ll have to merge it myself in my own fork.

Anyway, there is another problem I have with the Yabause core, and that is that the dynarec on x86 is not PIC-compliant. It might be PIC-compliant for ARM (on Android they’d have no choice anyway since they’d need to bake the emulator into a library for use with JNI, so they have to care about PIC-compliancy on Android), so we might be able to use it on ARM-based devices, but we never tested this yet. Anyway, we need PIC compliancy because libretro cores are compiled in dynamic library form, and emulator authors often have the luxury of not caring about this because they just bake their emulator along with a minuscule frontend into an exe with no dynamic linking involved. So there’s additional work for us to make sure things are PIC-compliant.

Falling back on interpreter makes things a LOT slower, software rendering doubly so. So I guess in the short term moving to GLES3 can already help a lot, but the real important thing is getting the dynarec working. It will make things a lot less accurate though and Yabause is already quite inaccurate as-is, but better than nothing I suppose.

#7

[QUOTE=Twinaphex;24632]I made a post about Yabause in another thread. The GLES3 renderer you talked about is not yet merged in upstream, so I want to wait until maybe Friday to see if the upstream guy is finally going to merge it, otherwise I’ll have to merge it myself in my own fork.

Anyway, there is another problem I have with the Yabause core, and that is that the dynarec on x86 is not PIC-compliant. It might be PIC-compliant for ARM (on Android they’d have no choice anyway since they’d need to bake the emulator into a library for use with JNI, so they have to care about PIC-compliancy on Android), so we might be able to use it on ARM-based devices, but we never tested this yet. Anyway, we need PIC compliancy because libretro cores are compiled in dynamic library form, and emulator authors often have the luxury of not caring about this because they just bake their emulator along with a minuscule frontend into an exe with no dynamic linking involved. So there’s additional work for us to make sure things are PIC-compliant.

Falling back on interpreter makes things a LOT slower, software rendering doubly so. So I guess in the short term moving to GLES3 can already help a lot, but the real important thing is getting the dynarec working. It will make things a lot less accurate though and Yabause is already quite inaccurate as-is, but better than nothing I suppose.[/QUOTE]

Thanks for the replies. I started posting here because the play store is extremely inconvenient. As I said, I’m not ranting. I’m only… ‘sharing’. It feels very good to know that improvements are on the way. Most of the games I’m playing on my device are emulated so this is a big deal to me. Talking about mame, the issue is compatibility. Notably Neogeo games. But the main issue with the app right now is the user interface. Nonetheless, thank you so much.

#8

[QUOTE=Reznnate;24631]The jaguar core options include a fast-blitter feature. With this enabled, many games are enjoyable/playable for me on the Shield ATV. Of the 3 cores you mention, yabause is the slowest. There is a GL-accelerated port in-the-works that is quite a bit faster. An alpha was posted in the Yabause forums a few months ago that shows great promise.

But I really appreciate it when future-looking features are added to the software and games I love. While MAME 2015 core and these cores may be slow today with some games, future hardware is coming that will run them well.[/QUOTE]

About the jaguar core, I haven’t seen such option anywhere. It’s definitely not in the core options… Am I missing something? I really would like to play some of that but right now, that one is so slow, even 2D games such as Pinball Fantasies are unplayable even with my CPU clocked at 2.7ghz. I have to admit, 4do can run some Night Trap or Brain Dead but it can’t even run the FMV intro of Killing Time. Maybe it’s extremely case sensitive and I should try more games but even for those, I need to clock my CPU around 2ghz. Also, I’ve read threads from people who were trying to run the games using .cue files when it actually works if you load the ISO directly.

#9

It’s in the core options. You just need to load the core, then load some content, then go back into the menu and edit the core options.

#10

The FBA core can also run the neo geo games and is lighter-weight than the new MAME core.

#11

I don’t know which version of retroarch you’re using but I don’t have such option in the core settings during gameplay. Checked with 4do and Virtual Jaguar cores but no difference and no such option.

#12

The comparison to N64oid is really ridiculous. Youre comparing an absolute garbage outdated copy of Mupen64plus to a latest mainline Mupen64Plus version, really? Please dont make such silly comparisons in the future and recognize that sometimes increased emulation compatibility means system requirements will go up, and mupen64plus upstream certainly does not care about low power ARM.

That being said, we made numerous optimizations to Glide64 that should help out the lower end. Rice is beyond salvaging. GLN64 - well, look at the fork that resulted from it, Gliden64 - it ended up even slower than Glide64 and definitely more buggy to boot too. Youll just have to accept that in the here and now, you need adequate hardware for N64 emulation. Its a matter of both CPU and GPu equally being important.

#13

Regarding PPSSPP being slower than standalone on certain ARM hardware - Im not exactly sure but it might be a bottleneck issue on weak GPUs. The libretro API relies on FBOs to draw stuff from core land into the backbuffer of frontend land, the original emulator would not have to do this.

I would appreciate some real world profiling between standalone and the libretro port in this respect, we want to make libretro GL cores as performant as possible.

#14

Last time I’ve tried Mupen, not only was it a tiny bit more laggy than n64oid during the loadings like when Mario 64 loads levels during the demo; it was also slower in terms of performance at the same resolution and it was a bit more glitchy in Zelda ocarina of time for example. It had those texture popings on the main field.

About PPSSPP, I’m having the same results with the standalone app. Huge slowdowns at the very beginning of the 2nd metal gear game, during the beach tutorial and throughout the game and not only a framerate drop but also sound stuttering.

Maybe you can tell me what you mean by low power ARM. Is an S5 quad core at 2.688 GHz and its GPU at 657Mhz already that much outdated?

Just to make it clear, I’m not trying to criticize you guys. You’re doing an amazing job and I’m extremely grateful but I always try to lower the settings of my phone as much as possible when I’m playing in order to save as much battery life as possible and also avoid overheating which is a complicated issue. I know what my device can do at full speed without overheating and I also know what it can’t.

It may seem like I never stop complaining but if you were to release a paid version of retroarch, I would buy it immediately.

#15

I’ve tried FBA because I was using that one back in the original Xbox days. However, it hasn’t started any of the ROMs I’ve tried even though the bios is together with the other ones. Does it require .FBA roms or a special version of the neogeo bios?

#16

FBA requires its own romset, yeah. There’s a french site that has ones that work, IIRC. The neogeo bios also needs to come from that working set. It took me awhile to find one that worked.

#17

Here are my issues with the Android port, no sodding Wii remote support, forcing me to use crappy touchscreen support and refusal to add Bluetooth back in, that’s nice of them.

#18

Thanks for the info. Much appreciated. I went to … forum and found romsets for FBA updated in 2015, downloaded the m-o set (1.2gb). It had a neogeo.zip. I put it together with the other bios files and tried some ROMs but no difference. None of them would load and the app systematically crashed. Though I’m a French guy myself, I can’t seem to find the site you’re referring to. Would you mind provide me with a link please? Thanks.

#19

The checksum for my working neogeo.zip: md5 cc345d87f576665d1c2a673503c1991b sha1 eb9fed518897dfafb67b4148f0ecfa731f0e3259

We don’t talk directly about romsites here for legal purposes (admittedly, it’s probably more tradition than necessity) but I can tell you: if you google ‘fba roms’, it’s the first hit.

#20

Sure keep going that will make us more interested in your issue