RetroFE forums

I don't have any specific testing needs if you've been able to validate that RetroFE is behaving similar to how it does on other platforms.  However, I'd be interested in any feedback on the usability / setup process.  I tried to keep the RetroFE configuration requirements minimal while integrating as seamlessly into RetroPie as possible.  If there is anything that could be improved, please let me know.

I set things up so that the ROMs stay in the standard RetroPie location, but all of the RetroFE collection assets (artwork, videos, metadata) remain separate from the rest of RetroPie in their own collection directories.  So if you want to use RetroPie artwork assets, you would need to change the collection settings.conf file to point to the right EmulationStation media directories.  That choice was intentional - the ES scraped artwork assets tend to be garbage.  With this setup, you can download the preconfigured RetroFE collection assets from EmuMovies, copy them into the RetroFE collection folders, and just rename the collections to match the RetroPie system naming standard.  You may need to make some tweaks to the collection settings files though, to point to the right system metadata.  You can refer back to the 'genesis' collection that is created during the install process for a configuration example.

Here are the places to look at for setting things up...

If you enable the Samba shares via retropie-setup, then you can use the following shares over the network:
ROMs: roms/<system name>
Collections: configs/all/retrofe/collections/<system name>

The corresponding local paths are:
ROMs: ~/RetroPie/roms/<system name>
Collections: /opt/retropie/supplementary/retrofe/collections/<system name>

Yes, you should be able to launch it from anywhere after installing with my script.  If you want RetroPie to automatically boot into it, you can edit the configs/all/autostart.sh script from the Samba share and replace 'emulationstation' with 'retrofe'.

The log file you attached looks good.  No indications that the install failed.

Can you run which retrofe from the command line?
Output should be /usr/bin/retrofe

You can also look for that file directly and try to run it.  Let me know what you find.

Well this is a little frustrating since the package that is causing the error (libmagickcore-extra) is a total nice-to-have.  It just converts the SVG logo file that EmulationStation uses for the RetroPie 'collection' into a PNG that RetroFE can display for its RetroPie collection.  Apparently I am trying to install a virtual package, rather than a specific version, and the RetroPie installer doesn't like that.

Not sure how I missed this previously.

You can replace the package in line 338 directly (change to libmagickcore-6.q16-2-extra), or just download an updated copy of the script (updating the original post w/ the source code now).

Quote from: Pieter Hulshoff on July 15, 2017, 09:17:36 AM

The script needs updating for sure, and the new RetroPie release should have 2.0.5 installed by default.

Sent from my SM-G920F using Tapatalk

The RetroPie 4.2 image doesn't have SDL2 2.0.5. It may come if you update RetroPie to 4.2.10 but I'm using a scratch disk because I'm porting the binary to "my build" so I didn't update RetroPie before building RetroFE. If I have time maybe I'll try.

Update - You must be right about the latest RetroPie including SDL2 2.0.5 because it works on "my build" without additional dependencies and the control works after exiting a game. Again, great job!

In addition to the RetroPie module, I am also working on an updated general install script for the RPi that uses SDL2.0.5 on a vanilla Jessie/Stretch image.  As part of that, I've tried to distill the build & runtime dependencies to the bare minimum, and understand which components require them.  I hope to share the working script soon, but figured I'd share those dependencies now, so other can review, test, and provide feedback.

BUILD_DEPEND="build-essential"
SDLRELEASE_BUILD_DEPEND="libasound2-dev libdbus-1-dev libudev-dev"
SDLIMAGE_BUILD_DEPEND="libjpeg62-turbo-dev libpng-dev libtiff5-dev libwebp-dev"
SDLMIXER_BUILD_DEPEND="libflac-dev libfluidsynth-dev libmad0-dev libmodplug-dev libvorbis-dev"
SDLTTF_BUILD_DEPEND="libfreetype6-dev libgl1-mesa-dev"
RETROFE_BUILD_DEPEND="tortoisehg cmake zlib1g-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libglib2.0-dev"
RETROFE_RUNTIME_DEPEND="gstreamer1.0-plugins-good gstreamer1.0-libav gstreamer1.0-alsa"

Getting back to the script development... I want to make the RetroFE integration into RetroPie as seamless as possible, and I feel like the biggest challenge is the naming convention.  RetroPie has this concept of "short" platform names and a corresponding full name, which are defined in the platforms.cfg files (~/RetroPie-Setup/platforms.cfg and /opt/retropie/configs/all/platforms.cfg).  I think it would be easiest and most "native" to RP if this naming convention was carried over to the RFE collections.  My concern is that  the metadata for RFE is coming from the HyperSpin XML files, which follow a different system naming format.  The mismatch between the metadata system names and the RP-native platform names means that we won't pull back any metadata for the games.

So I guess I have 2 questions....

- Do folks agree that it would be easier for users if the RetroFE collections on a RetroPie setup were following the RP "short name" convention?  Personally, I like the idea of consistency between the names shown in the RP "roms" directory, and the RFE collection names.  Paths can then be standardized.  This can simplify the collection configs, and probably also simplifies the sharing of artwork assets between RP FE's as we move forward as well.

- If we can agree on the above, should we consider a config option in the collection's settings.conf that explicitly defines the collection's metadata source name, optionally overriding the use of the collection's directory name?

Thank you for your consideration....

I guess I'm still a little confused about what everyone is trying to accomplish with the RetroPie integration. I agree that hosting a separately hosted RetroFE-based image is undesirable, but it's also unnecessary - that's where I was hoping my module/script would help out.  The intention is submit it for formal incorporation into RetroPie, so that anyone could go into RetroPie-Setup and 'turn it on' - just the AttractMode, MehStation, and ES-Kids.

Progets - If you haven't tried it or looked at the source, running the install/update script will compile and install the latest RFE from BitBucket.  The steps mimic what is in the old RPi script, plus more auto configuration to make RFE work well in a RetroPie environment.  Are there other specific steps you believe the script should make?  I guess I'm curious about the concerns you have with AttractMode being installed in via the RetroPie-Setup.

Pieter - With regards to your concerns about changing the video driver for the emulators, that could be inserted in the script as well - probably not the most elegant solution if you can prevent the need in the first place.  But especially considering the majority of RetroPie pushes folks to RetroArch for emulation, that's a single config change that I could automate.  Additionally, I could modify the autoboot settings as well - however, the RetroPie admins might not look kindly on that.  That's a case where it might be netter to let people know that they should use the autobot config setting that is built into the setup tool.

At the end of the day, I think I've got things pretty close to usable and can script in any gaps.  If you guys can provide some requirements for improving usability, I'd like to help.