[illuminerdi]

Too expensive for too little, IMO. Sure it’s nice and the form factor is small, but it’s barely less expensive than some of the lower end Intel NUC models.

While a unit like this might be powerful enough to emulate just about everything up through the Dreamcast, the price point doesn’t justify what amounts to the ability to play a few more N64 games. PSX is almost 100% solid on the RPi 2, and this thing is not remotely powerful enough to emulate any/many PS2 or GCN games, so you end up paying $60 USD for a minor increase in the overall supported games list.

Not trying to rain on anyone’s parade. If you like this then by all means, back it – the more maker boards out there, the more makers and the more community we have, I just personally don’t see the benefits here.

IMO a better option would be for RetroPie to add support for something like the Odroid C1+. This is a Quad-Core 1.5ghz ARMv7 board with the exact RPi form factor and a Mali 450 graphics chip (which is probably at least on part with VC IV, if not better).

In fact, I’ve been thinking about getting one of these just to see if I could hack RetroPie into working on it. I can’t see it being that difficult to accomplish – mostly I’d just need to alter Retropie’s boot config to load the Mali 450 module instead of Videocore IV.

[illuminerdi]

While Retroarch does support rewinding, I could not get it to work for me for SegaCD games.

I have a Raspberry Pi 2 running Retropie 3.2.1, and enabling rewind would cause the emulator to instantly quit (crash?) after trying to load a game. The strange part was that it was not logging errors or crashes.

I turned on the most verbose logging options possible and the log files would indicate that it was preparing the rewind buffer, and that was it – that was the last log entry. No crash message, no further log entries, and nothing in dmesg either. There might be a separate log file somewhere (system log file? The logs for “runcommand”?) that detail the crash, but retroarch’s own log files weren’t outputting anything to indicate the root of the problem.

I tried tweaking the buffer sizes down to 20MB and still nothing. I need to experiment more, but in my current experience rewinding is not functional, and may never be functional given the lower amount of RAM that the RPi has compared to something like a desktop or HTPC.

[illuminerdi]

So I have at least some inkling of what’s going on here now. After lots of poking around I have what I believe is a firm grasp of at least how the system here works:

First you have the config in /opt/retropie/configs/all/retroarch.cfg – I will refer to this as the “baseconfig”.

Then you have your controller configs located in /opt/retropie/configs/all/retroarch-joypads – I will refer to these as “stickconfigs”.

Lastly you have configurations located in /opt/retropie/configs/emulators/{system name here}/retroarch.cfg

Here is where it gets tricky. Each of these files is mostly empty and the last line is #include /opt/retropie/configs/all/retroarch.cfg

So when you boot up an emulator it looks at its configuration, and (as far as I can tell), it then parses custom configs, THEN it grabs a copy of the baseconfig, and includes it for configuration, before (possibly?) grabbing the stickconfigs and including those.

So I’m pretty sure there’s a bug here, because making per-emulator changes to /opt/retropie/configs/{emulatedsystem}/retroarch.cfg was not working for me, I believe because the baseconfig file is being loaded after the file that’s supposed be be containing “overrides”.

So even if I put “blah_thing_btn = x” in /opt/retropie/configs/{system}/retroarch.cfg, it would just immediately get stomped over by the baseconfig (and/or the stickconfig) getting included as a later part of the config loading chain.

Maybe I never correctly set a necessary flag, or this is a bug; I haven’t experimented enough to find out which, and I don’t really have the time to :( – sorry! I’m just documenting this in case it helps others or helps the devs bugfix.

So my solution for emulators where I want to alter the “stock” config: rename /opt/retropie/configs/{system}/retroarch.cfg to something else, and then copy the baseconfig file to that same directory and make necessary modifications there. Without the #include taking place you don’t have to worry about your per core changes getting stomped over!

It’s a brute force way to solve the problem, but as I said, I wasn’t really interested in putting in a ton of time into tracing the config hierarchy and determining what was *actually* taking precedence and being loaded in what order and then working around that. I can confirm this method does work for me, and I’m happy with it, so I don’t intend to do a lot of global tweaks from here on out.

I hope this helps anyone interested! Feel free to use this information anywhere helpful (wiki, etc) if someone wants to write up a summary/guide on the basic flow for loading configs, since I couldn’t find it documented clearly on the Wiki (though it may be there and I just never found or understood it)…

[illuminerdi]

For those interested, I managed to work around this but it’s not the cleanest solution.

So here’s what I did:

1) I made a directory: /opt/retropie/configs/custom

2) I copied the contents of /opt/retropie/configs/all/joypad-config to the directory in step 1

3) I edited /opt/retropie/configs/all/retroarch.cfg and changed joypad_autoconfig_dir to point to the directory in step 2

This now causes Retroarch to load up my custom controller binds every time.

Though ironically in my last edits I somehow managed to break something because now retroarch crashes/instantly exits whenever I try to load up a SegaCD game (which I was using to test this), the same game that was previously working. I think I know what I changed to break this, but it’s still annoying that something as simple as trying to change controller configurations turns out to be so difficult.

This would be completely irrelevant if the system would save config changes made through RGUI by default, but for whatever reason creating config binds/changes through RGUI does NOT save properly, either due to a bug or just plain obtuse implementation, but either way this whole process has been way more difficult than it should be.

I’m not blaming anyone – I’m sure there are good reasons why this is the way it is (dev time is valuable and they are not paid, these things are bugs, etc), this is just turning out to be a major frustration for what should have been a non-issue…

[illuminerdi]

I’m still having no luck on this. I tried enabling per-core overrides in the retroarch config file to see if that worked, and even that failed – despite putting custom entries in my picodrive config it would still default to the same controls every time.

I’m starting to think that the ONLY place I can change the controller config is in the retroarch.cfg file somewhere, but even this is confusing: there are at least 2 or 3 copies of this file scattered about various locations…

I’m going to turn on debugging/logging for retroarch and see what the actual log files have to say about exactly WHICH config file is being loaded and from where, maybe that will help, but I’m still in over my depth here so any suggestions would be appreciated.

[Author]

Posts