ES developers UNITE!

Zigurana

More and more people have been doing some great and exciting work on EmulationStation lately, showing that there might be a future for ES after all!

I would like to reserve this spot as a place for (future) ES developers to come together, share tips and tricks, and how to's. ES can be a beast to work with, and having someone to share and discuss code with can be a tremendous help. (If only to share frustrations and commiserate each other).

Over time, I would like this topic to grow up to be a starting point for people who want to take a stab at hacking their favorite feature into ES.

Currently, much of the information on ES is scattered over a collection of github repositories, and it would be worthwhile to consolidate that into a single location.

Let's get coding!

What is EmulationStation?

Please have a look at the ES wiki on RetroPie.

Github repositories:

Aloshi's original repo (now dormant, but folks still post the occasional PR)
The official RetroPie Fork
Herdingers attempt to consolidate the repos

Who is who

Currently active developers (in A-Z order):
@Arcuza
@ben_thatmustbeme
@fieldofcows
@fluffypillow
@jacobfk20
@jdoolin (?)
@pcal
@suprjami (?)
@Zigurana
..

Forum Member Repositories

@fieldofcows

https://github.com/fieldofcows/EmulationStation

Supported platforms

All (Windows, Linux, Raspbetry Pi)

Features

New Video Gamelist View that supports video preview of the selected game
marquee display

@fluffypillow

https://github.com/mmatyas/EmulationStation

Supported platforms

?

Features

GamesDB / SQLite db for gamelists (via Aloshi/unstable)
Custom Config location (via Herdinger)

@jacobfk20

https://github.com/jacobfk20/EmulationStation-RPiE

Supported platforms:

?

Features

OSK (On Screen Keyboard)
Gamelist Gridview. (Gamelists views can now be manually changed in gamelist menu)
Wifi Scanning / connecting from within ES. (tied with OSK you can connect to a network without a keyboard)
Other network settings to view IP/MAC address of both eth0 and wlan0
View Storage from within ES
Toggle Systems to show or be hidden from the System View.
And a couple other small things such as Progressbars or see savegame count per system

@Zigurana

https://github.com/zigurana/EmulationStation/tree/UI_modes_Kiosk_Kid_Full
https://github.com/retropie/retropie-setup/wiki/Child-friendly-EmulationStation

Supported Systems

All

Features

Kiosk UI mode to hide specific games / configuration menu items
Kid UI mode to show only whitelistes items
Favorites for games, and filtering to show only favorites
Surprise me! (goto random system+game)

If anyone has additions or suggestions, let me know, and I will update this post.

fieldofcows

@Zigurana What a great post! As one of the 'active' developers I would love to be involved in the future of a consolidated ES.

At this stage, what would be really useful to see is a list of ES forks with the features they currently implement on top of Aloshi's original repo. And also what platforms they support.

For example, my fork:
Supported platforms: All (Windows, Linux, Raspberry Pi)
Additional features: New Video Gamelist View that supports video preview of the selected game and marquee display

Maybe this could be put into a table format and updated as the information is discovered.

This would be really helpful when deciding what to cherry-pick in order to make a combined fork.

Zigurana

@fieldofcows : great idea! But alas not something I am willing to do while on my phone.
My work blocks access to the retropie website (on grounds it being 'games' related, sheesh), so I will try and build a table once I get some time tonight.

dankcushions

9th time lucky, huh? ;)

dankcushions

in all seriousness, IMO we have a single location - https://github.com/RetroPie/EmulationStation

i think changes would be accepted here if they were singular and tested. i think if all these various es forks are merged into some other ES 2.0 fork then they'll never get integrated.

for me the key is gradually rolling in these great new features as i think a 'big-bang' approach is unlikely to be accepted.

(all my unqualified observations)

fieldofcows

@dankcushions Hmm... See here: https://retropie.org.uk/forum/topic/2250/emulationstation-fork/31. This seems to imply that the RetroPie fork is not for development. Is that not the case?

dankcushions

@fieldofcows said in ES developers UNITE!:

@dankcushions Hmm... See here: https://retropie.org.uk/forum/topic/2250/emulationstation-fork/31. This seems to imply that the RetroPie fork is not for development. Is that not the case?

but then also https://retropie.org.uk/forum/topic/3121/emulationstation-mod/24 :)

i think we'd have to ask @BuZz what his intention is with the retropie ES fork, but perhaps a lot of these features that people have developed might be acceptable if they were isolated into single PRs and introduced slowly.

Zigurana

I think it's reasonable to continue thinking about how to consolidate all the forks into a single repository, but really, that was not my intention for this topic.

My main goal here is to capture information as well as enthusiasm for working on ES.
If that leads to a single repository that takes on features once they become mature enough, all the better.
What I am missing at this point is some people to discuss the code with. Normally this conversation would take place at the main repository, lacking that, I though we could bring people together here.

Zigurana

In any case, I believe that ES development as such should not depend on BuZz's willingness to maintain ES as an developing project. That would be completely unreasonable to ask of him given his current workload for the Retropie project (and he must have_some_ kind of private life as well, right?).
For any addition to ES, it should be thoroughly tested and otherwise de-risked before even be considered for merging into the stable stream. I believe that my hacking around should not bring additional support burden to the Retropie team.

lilbud

@Zigurana You didn't hear it from me, but you can use Google translate to access any website, even if that site is banned.

BuZz

@dankcushions said in ES developers UNITE!:

i think we'd have to ask @BuZz what his intention is with the retropie ES fork, but perhaps a lot of these features that people have developed might be acceptable if they were isolated into single PRs and introduced slowly.

I am happy to consider well written, well tested changes that add useful functionality.

Nismo

@Zigurana Thank you very much, great topic, but i have to say i'm not a developer, I only try to help with my little knoweledge.

About the @fieldofcows fork, i think it should be in first post too.

I have posted some impressions testing fieldocows windows build in the old topic, so i'll copy here (i'm not sure what's the right place):

I've found whats wrong with relative paths for marquees and video. You need to disable option "save metadata on exit" (enabled by default) in "other settings" menu to keep relative paths untouched. So that's the option that overwrite the relative paths.

In other hand now i can redefine more buttons than before on "input config" but now i can't use L shoulder and R shoulder to go fast up and down on the gamelist, simply doesn't do nothing.

About the video, it may stop when you lauch a game but still playing 10 or 15 seconds after the game is launched (I can hear the sound).

If you are in gamelist with video, and then go back to another system without videos, video's sound of the last system still playing until you join a game, and when you leave the game, video's sound come back, so whould be good to make the code only play video when game is focused on gamelist or stop when you change system.

It works ok when you are inside a system that some games have videos and other games not, works like expected, if you focus another game in the list without video, the video's sound stop, but doesn't happen if you change system. Maybe is because the other system doesn't have any videos and doesn't use video view and use detailed view, i need to test this later.

I'm working in a simple video theme to contribute a bit with his project, i hope to finish soon.

Thanks to all people helping emulationstation.

fluffypillow

Some months ago I started working on ES, and also collecting features from the different forks and unlanded PRs, but then I got distracted by other projects. At the moment I'm not working on it actively, but you can find my repo here, and a detailed changelog compared to the original ES here. The individual changes are mostly self-contained, so they could be applied on RetroPie/other fork as well.

Zigurana

@Nismo: Thats ok, i've removed you from the list. Feedback for specific forks / features/ items is better given in their original thread, no need to repeat it here.

robertybob

Just my two cents:

I'm desperate to see more features being implemented for Emulationstation, as it's such a great front end.

In an ideal world I'd love to see ES development the take a much higher priority and, while I'd never think of jumping ship to Recalbox, I do have a lot of respect for their fork of ES in terms of added features. Mehstation and RetroFE seem to have stalled so really there's only ES and Attract Mode having any kind of development.

Personally I think one person should take the reins and pull all the changes by users here into one fork for everyone to test via the RetroPie Setup script :)

Hex

Hex's Builds :

https://github.com/hex007/EmulationStation

Features :

Optimized for Pi 1 and Zero/W (Low processing on idle)
Integrated Audio Player (Starts shuffled with ES + Backend)
Easier access to shutdown/quit/reboot

Todo :

Incorporate features from RecalBox-ES and various forks of ES

Zigurana

@Hex. Hey that's very cool!
You are focusing on ES performance, for use with the Pi zero, right? Did you do any profiling to see what the real bottlenecks alare with stock ES?

Also, would you consider creating a PR for the
Retropie branch with the audioplayer functionality? Pretty please?

herb_fargus

Background music eh? Seems that's been a perpetual request ever since retropie has been a thing.

Hex

@Zigurana @herb_fargus Would you be interested in testing it?

The bottleneck is basically constant render of views. It is small enough on modern PCs but a hefty 60% constant processing doing nothing on Pi 1/Zero. The downside of this is video previews dont work nicely

AlexMurphy

@herb_fargus bgm works with the mpg123 setup. It works really well.