Oh, re: the system.config I was thinking rather, if you used any specific parameters or arguments. I personally found that using the -F to run it in full screen (before -L) had more success with getting retroarch to run.
Also, sound doesn’t appear to be working for the menus the way it’s expected.
The one that I have written out has all the associations for the pre installed on an up to date 0.5, favouring retroarch, since returning to ES after using a standalone, eg gpsp+, PocketSnes crashes the app. It’s basically a mirror of each of the action.config files.
The other problem I have is how it handles *.zip files. It doesn’t handle it the same way the stock launcher does, instead initially decompressing, and leaving the extracted files from the archive in the same directory. Not the most ideal scenario, especially if you’re space limited. I’ve left it in my script, just for convenience.
Here’s the log readout for an emulator using retroarch. It works, but as you can see, the attempts to load the sounds for the ES launcher aren’t behaving.
lvl2: Parsing XML file "/home/cpi/.emulationstation/gamelists/psx/gamelist.xml"...
lvl2: req sound [basic.launch]
lvl2: (missing)
lvl2: Attempting to launch game...
lvl2: retroarch -L ~/.config/retroarch/cores/pcsx_rearmed_libretro.so /home/cpi/games/PSX/Castlevania\ -\ Symphony\ of\ the\ Night.bin
lvl2: Creating window...
lvl2: Created window successfully.
lvl2: GL vendor: lima
lvl2: GL renderer: Mali400
lvl2: GL version: 2.1 Mesa 20.0.0-devel (git-2d971cc1ca)
lvl2: Checking available OpenGL extensions...
lvl2: ARB_texture_non_power_of_two: ok
lvl2: req sound [basic.launch]
lvl2: (missing)
On the other hand, this is how it behaves trying to load a standalone emulator. I have chosen Mupen64plus, with specific arguments defining that it is to be run in full screen, with a specified plugin etc. overriding whatever it is that gets put in a config; since I believe that ES doesn’t seem to obey directory heirachy/structure. As you can see, it crashes.
lvl2: Attempting to launch game...
lvl2: ~/apps/emulators/mupen64plus --plugindir /usr/local/lib/mupen64plus/ --gfx mupen64plus-video-rice.so --fullscreen /home/cpi/games/N64/Banjo-Kazooie\ \(U\)\ \(V1.0\)\ \[\!\].z64
lvl1: ...launch terminated with nonzero exit code 32256!
lvl2: Creating window...
lvl2: Created window successfully.
lvl2: GL vendor: lima
lvl2: GL renderer: Mali400
lvl2: GL version: 2.1 Mesa 20.0.0-devel (git-2d971cc1ca)
lvl2: Checking available OpenGL extensions...
lvl2: ARB_texture_non_power_of_two: ok
Now here’s the funny thing. If I load up a standalone without ES via the standard launcher, I get the reverse happening, with retroarch based games not working, but standalone being fine. Judging by the logs, and the fact that you have it working in 0.3 fine, my guess is that this is something related to OpenGL extensions that have been introduced in 0.5, and the compatibility thereof.
I may have jumped the gun little bit, saying that it’s 100% ready fro prime time. I would say it is, if you have a very specific es_system.cfg file that:
a) Doesn’t read compressed archives
b) only uses either retroarch OR standalone emulators
Edit: I just checked out that script in your last post! That is amazing, how it handles the compressed files! that should hopefully solve that problem re: how stock ES handles things. I’m definitely going to use it!