Starting EmulationStation from /usr/share/retropie/

[petrockblog]

Hi Aloshi,

the file organization of RetroPie is currently re-organized. A central part of that reorganization is that the binaries and default config files are located in standard Linux folders. I am currently looking into the approach where all RetroPie (sub-)folders reside in /usr/share/retropie/. According to that EmulationStation would then be located in /usr/share/retropie/supplementary/emulationstation/emulationstation.

When I move the binary into that directory and try to start ES, I only the the white dot on a black screen (as user "pi" as well as super-user). Do you have an idea what could cause this problem? If this would work, high steps towards a package repository could be done from my side :-)

[Aloshi]

Hmm, that's strange. ES shouldn't care where you run it any more - no resources are loaded from the current directory, everything is packed into the executable.

Does it work if ES is put anywhere else? Is enough memory allocated to the GPU?

The renderer initialization code has changed significantly in the unstable branch (since it uses SDL 2). Could you give that branch a try? There's a fork on my GitHub page that installs it, here are the steps. The es_systems.cfg file format has changed to XML, so you'll also need to do part of this routine to get ES to start. The format is:

<systemList>
    <!-- Here's an example system to get you started. -->
    <system>

        <!-- A short name, used internally. -->
        <name>snes</name>

        <!-- A "pretty" name, displayed in the header and such. -->
        <fullname>Super Nintendo Entertainment System</fullname>

        <!-- The path to start searching for ROMs in. '~' will be expanded to $HOME or $HOMEPATH, depending on platform. -->
        <path>~/fakeroms/snes</path>

        <!-- A list of extensions to search for, delimited by a space. You MUST include the period! It's also case sensitive. -->
        <extension>.sfc</extension>

        <!-- The shell command executed when a game is selected. A few special tags are replaced if found in a command:
        %ROM% is replaced by a bash-special-character-escaped absolute path to the ROM.
        %BASENAME% is replaced by the "base" name of the ROM.  For example, "/foo/bar.rom" would have a basename of "bar". Useful for MAME.
        %ROM_RAW% is the raw, unescaped path to the ROM. -->
        <command>echo "%ROM_RAW%"</command>

        <platformid>42</platformid>
    </system>
</systemList>

Just add one to get ES to start, make sure it points to a directory with at least one game in it as usual. It will look ugly without a theme, but should work. I have had some reports about keyboards not working, though I can't seem to reproduce this.

EDIT: Just tried a fresh install on Raspbian, there definitely is a keyboard issue. I'll let you know when I fix it.

EDIT 2: Should be fixed now, needed the package libudev-dev installed before building SDL2.

[petrockblog]

Thanks! I will have a look into that!

I have also another question: With ES being located in a subfolder of /usr/share, is it possible to have default configuration files in the directory /etc/emulationstation/? This would be needed if a user does not have any custom configurations in $HOME/.emulationstation/.

[Aloshi]

The keyboard should be fixed for the unstable branch (RetroPie-Setup was missing a necessary package before building SDL2, this is now fixed in my fork), it's probably safe to give it a try now.

As for using /etc/emulationstation for default config files...I think that would be OK for the es_systems.cfg file, but I would leave es_input.cfg out of that, since it doesn't really have a sensible default. es_settings.cfg only has a few values in it, but it wouldn't be hard to add support there. I've added it to my todo list.

[petrockblog]

I agree that es_input.cfg and es_settings.cfg are only user-dependent files. Also, besides the config file es_systems.cfg also default theme files would be located there. Otherwise, ES could not be used by users, who do not have any theme files in their home folders. I forgot to mention the theme files in the post above, sorry.

The motivation for all this relocating of the binary and config/theme files is to have a user-independent default installation of ES which follows Linux standards. The default installation can be customized by config files within the home directories of the users (just as it is already done by ES today). When this is possible, ES could be installed with the APT package system. I am currently working on the repository setup.

[Aloshi]

I worked on this tonight, along with a new "theme set" feature that allows multiple themes to be installed simultaneously and switched out inside of EmulationStation (no restarting required!). I rearranged the ~/.emulationstation folder in the process.

Lots of changes, best illustrated through file tree examples:

/home/pi/.emulationstation/
   es_settings.cfg
   es_systems.cfg
   es_input.cfg
   es_log.txt
   themes/
      my_theme_set/
         snes/
            theme.xml
            my_cool_background.jpg
         nes/
            theme.xml
            my_other_super_cool_background.jpg
         common_resources/
            scroll_sound.wav
      another_theme_set/
         snes/
            theme.xml
            some_resource.svg
   gamelists/
      snes/
         gamelist.xml
      nes/
         gamelist.xml

The exact same tree is also valid in /etc/emulationstation/..., sans the es_settings.cfg, es_input.cfg, and es_log.txt files. ES will never write to /etc/emulationstation (at least, that's the intent).

And systems can still have their own individual overrides in the ROM folder:

/home/pi/roms/
   snes/
      theme.xml
      gamelist.xml
   nes/
      theme.xml
      gamelist.xml

ES will look for files in this order:

1. [SYSTEM_PATH]/... (theme.xml and gamelist.xml only)
2. $HOME/.emulationstation/...
3. /etc/emulationstation/... (ES will read from here, but never write here)

I haven't tested the /etc/emulationstation/ stuff yet (not on a Linux box), but it should work. I'll try and test tomorrow.

The docs in the unstable branch have been updated to reflect the changes and should hopefully answer any questions. That reminds me, I'd like to add proper man pages for ES some day. :smile:

[petrockblog]

That looks great! And is exactly what I also had in mind ... With that feature in place, I can continue to work on the reorganization of the RetroPie components as individual packages :smile: