Questions about core locations, config loading etc

RetroArch Android devices
#1

I have a few questions:

How can I get the certain config files made and saved to automatically come up when corresponding core is loaded? For example If I have a config for Lynx (Handy_android.cfg or whatever it makes) loaded but then switch to Picodrive core it still has the handy config loaded. I then need to manually go through menus to load the picodrive.cfg. It is a lot of extra steps and faffing about. Can I have it so cores will have their own configs and autoload them?

Can each core have it’s own ROM directory come up automatically when core is loaded?

When I load a core I get this annoying on screen controls overlay every time even though device has physical controller connected. I need to hit the keyboard icon every time, then hit the icon that looks like a controller. Is there a way to set it to not get this overlay and just use the physical controller as default?

Where are cores saved? I would like to backup cores that I like and work well on my particular device/android version. Using online updater is not always practical (no connection) and the new version I get may not work well with my setup. I would like the option to keep what works well for me.

How can unwanted cores be removed after loading? I tried a few and they didn’t work well so I want to nix them.

Would it be possible to get a stand alone version of each emu? As in if I just want Picodrive just an icon for picodrive and that is it for example. That would solve alot of the above issues.

Thanks

#2

There are two ways to do your first scenario. Enabling per-core configs will make and load configs based on which core is loaded. It can be finicky and unpredictable sometimes, though, so many people have switched to the config override system, which takes a little more work upfront but is more consistent in behavior.

No, just put your browser directory to your top-level ‘roms’ directory and navigate down into the specific directory as needed.

Go into settings > onscreen overlay and set ‘display overlay’ to OFF

By default, they go into the retroarch application directory in /data/data/com.retroarch/cores(?). You’ll need root to mess with it. However, you can go to settings > directories and change your core directory to whatever directory you want. Do note that various Android versions handle directory permissions differently and RetroArch may or many not be able to write to certain places. Also, you can’t load dynamic libraries (which the cores are) from external storage (i.e., SD).

Go into the core directory and delete them. This requires root unless you’ve changed your core directory to somewhere user-writeable.

It’s potentially possible to statically link the core libraries instead of loading them dynamically, as is currently done on the console platforms (Wii, PS3, etc.) but it would take a lot of work to extend that to Android. It might happen at some point but it may not be free like the main app.

#3

I do have per core configs enabled but it doesn’t work for me. I still need to manually load configs.

Each core should be able to have a default directory set. If I load SNES emulator I am going to load SNES ROMs not anything else. This should have an option for per core directories, that would be much nicer.

All in one emus require more to get to a particular system and get it going. So for example if I want to play SNES I can load a SNES emu select game easily as it automatically sends me to my SNES rom dir, and start playing, or I can load retroarch, pick the menu option to load core, then pick core from list then select and load config, finally go back and load a game which means more tree navigation because it doesn’t allow per core directories, then finally pick the game, then I have to pick from open with core or folder whatever that means. That is allot more messing around and honestly this means I don’t use RA as much as other emus, it is too much faffing about. I am just being honest.

It would be nice to just pick the system (core) then the game, then go. When you pick the system any settings you do with that core loaded will pertain to that core and auto load when you select that system the next time. That means controller options/mapping/ shader settings, rom paths etc. If you want to set global settings then with no core loaded make your settings. Any core loaded afterwards will have those as default then unless you change them with the core loaded which will then over ride the global setting (if have per core settings enabled).

I would also prefer everything be put where I can see it and not have to root the device. That makes things easier for managing and backups. When I get everything set up I can back up as is so I don’t have to keep re doing everything it when I upgrade devices etc. It makes the setup easily portable between your devices.

#4

What you described is basically a mixture between per-core configs and overrides, which isn’t really possible with how things work under the hood. With the override system, you set your basic settings in the normal retroarch.cfg and then you just make text files that supersede the handful of settings that need to change (different shader, etc.).

Anyway, try this workflow: load content (detect core), navigate to the game, pick the core from the short list that pops up. Assuming your content directory is arranged like this (and your browser directory is set to this hypothetical ‘roms’ directory): roms …snes …nes …sms …genesis …etc. you’ll only ever be one directory up from the game you want to play.

You can also scan your content directory to create playlists for a given core. Using the XMB menu, this puts all of your games separated by core right at the top level and you don’t need to navigate to them at all.

You can set your directories (content browser starting dir, config dir, etc.) wherever you want them in the settings > directories menu. We try to set it somewhere useful/sane but some devices seem to drop it all the way back to root-only directories, despite several layers of fallbacks. Android is also an ever-changing shit-show when it comes to permissions, so if we support more than the latest Android version (and we do), there’s no telling what’s going to work on a given device.