Feature Request: one emulator that lets you pick the other emulators

[Dano-omg]

First let me describe the problem (cause you may have already fixed this somewhere). :)

Sometimes when scrolling down through the roms for a given emulator, the user accidentally presses Left or Right and switches to the next emulator, gets all confused, presses Left or Right again, and now they have to start scrolling down again from the top. (Maybe the controller I'm using for this is too finicky -- or maybe they just have fat fingers, whatever.)

Proposed solution: instead of using Left and Right to switch, could you make one emulator to rule them all? On this "main emulator" screen, you could then scroll up and down to pick like NES, SNES, etc... and once you pick one of them, it brings you to the up/down regular emulator page for that one.

Of course, then you'd also need a "back" button... and that sounds like a ton of work (so i totally understand this doesn't get done). But i think it'd make the user experience that much better. Just sayin'. :)

[vidia]

I love the idea. I'd also like to see an option eventually to view all games in one list and then have ES run it in its emulator when selected. This isn't great for people who have a ton of games, but it is nice for those moments when you ask yourself "What do I ant to play today?" and then you can see it all in front of you and not have to navigate everywhere to find games.

David Tschida

On Thu, Aug 8, 2013 at 4:30 PM, Dano-omg notifications@github.com wrote:

First let me describe the problem (cause you may have already fixed this somewhere). :)

Sometimes when scrolling down through the roms for a given emulator, the user accidentally presses Left or Right and switches to the next emulator, gets all confused, presses Left or Right again, and now they have to start scrolling down again from the top. (Maybe the controller I'm using for this is too finicky -- or maybe they just have fat fingers, whatever.)

Proposed solution: instead of using Left and Right to switch, could you make one emulator to rule them all? On this "main emulator" screen, you could then scroll up and down to pick like NES, SNES, etc... and once you pick one of them, it brings you to the up/down regular emulator page for that one.

Of course, then you'd also need a "back" button... and that sounds like a ton of work (so i totally understand this doesn't get done). But i think it'd make the user experience that much better. Just sayin'. :)

— Reply to this email directly or view it on GitHubhttps://github.com/Aloshi/EmulationStation/issues/121 .

[HorstBaerbel]

How about storing the last selected game for every system and re-selecting that one when switching between systems? Doesn't help with the fat fingers though... ;)

[Aloshi]

@HorstBaerbel's solution is a lot easier to implement. I'll give it a shot when I find the time.

[leandromacrini]

i have already done this in my fork of the project. you can see a video of it here: http://www.youtube.com/watch?v=UPPAWz9bEjA

everything is customizable via the es_systems config file (that I've moved to XML).

next step is to make a menu for the consoles to permit the user to add/remove games, updates info, search screens ecc, all insinde the emulation station.

GuiConsoleList.cpp/h

another interesting thing that you can find in my fork is the new animation system. it is now based on milliseconds for the animation duration and most important i have implemented a callback optional paramenter (via lambda function) so you can chain animations and make funny things (or just create a delay of X millis).

all can be found here: https://github.com/leandromacrini/EmulationStation

it would be interesting to merge all this in one project and make a "fixed team" to develope those things.

[HorstBaerbel]

I've seen your pull request for the display sleep. Nice work. Your menu system in the video looks really cool with the system selection, font and all! Like it! Could you make the theme available?! Imo pull requests are ok, I do it the same way and Aloshi usually merges what works and is needed. If we keep merging from origin/master this should pose no problems. Are you proposing a different way collaborating?

[leandromacrini]

yes theme and all can be shared if needed (or as default for the project).

for the collaboration i'm just saying that a "team" organized can work better the a single person project with random contributions.

a team can separate tasks and roles and make things faster than a single person.

another interesting thing is to make a repository for the project so people can download any emulators from there and with the last binary build, and using standard place for configuration etc.

[HorstBaerbel]

I'd have nothing against directly contributing to ES e.g. possibly in an "experimental" branch...

About the emulators: Nice project, but LOTS of work (RPi, Ubuntu, Win, x86, x64). I'd rather not open that can of worms and leave that to other people. The retropie project already does that pretty good for the RPi. I was thinking about converting the script to something like a "retropc" script to at least support debian linuxes, but yeah, that time thing, you know... ;) Plus the libretro-super project for retroarch already has ~80% of your emulation needs covered with one tight package, which compiles out-of-the-box (at least in debians) and can be run by ES very well.

[Aloshi]

Nice work @leandromacrini! I'm really sorry I haven't actually gotten around to integrating your HDMI power off code... :frowning: It's not you, it's me!

This is going to read more like a very technical blog post than a comment, but here goes...

I have a list of things I really want to add to EmulationStation that I mostly keep to myself because it's really hard to find the time to actually deliver on it. It's been very slow getting through it for a couple of reasons: one, I had a full-time job this summer, and two, a significant amount of backend work was required (in my opinion) to cleanly implement a lot of it. This will be changing soon - I'll be leaving my full-time job to return to school next week (which is still time-consuming, but leaves me with a lot more energy after a day's work), and most of that back-end work is done (e.g. the Eigen rewrite, the ComponentList class - I think the only backend work I still need to do is work out scrolling for ComponentList and a RatingComponent). So I should have more time very soon!

So without further ado, here's what I want to do, roughly in the order I plan on doing it.

• Move es_systems.cfg to XML. A built-in legacy -> XML converter will be provided. Documentation will need to be updated and RetroPie will need to be changed. This paves the way for so many more features and fixes a huge inconsistency. I've been kicking ever since for not doing this the first time - it's taken so long because I didn't want to break RetroPie-Setup and ES-scraper, but I think @petrockblog will help update RetroPie.
• Create a generic metadata class. This will be used (in code) by the GameData and SystemData class to keep metadata in an extremely flexible way. It will also support a sort of "metadata template," describing default types and values for metadata, to be used by the frontend in "edit mode." The "template" will likely be described as part of the gamelist.xml, though outside the <gameList> tag.
• Change the current GuiGameList description scrolling panel to read this metadata. I'm not sure if I want to leave this up to the theme.xml or gamelist.xml yet. I think only automatically generating it would be too restrictive. This will definitely support different systems having different metadata.
• Add an "edit mode" to ES. This is an option selected from the menu. Launching games is disabled in this mode. Holding the A button down on a game, folder, or system (if that gets integrated) will bring up a screen to edit that object in detail.
  • Games - edit game metadata. This is where the "metadata template" plays a major roll - the UI will be an automatically generated ComponentList. Using the template types, data entry is intelligent - title shows up as a single-line textbox, descriptions show up as a multiline textbox, images preview based on the entered path, and so on.
• Finally add an integrated scraper. This is a hell of a task, because I want it done right - you should be able to cancel mid-task, which requires using non-blocking network calls. You should be able to run the scraper without initializing the ES renderer, which means a text-based interface mode, for the many folks who can't get their Pi, monitor, and internet together in one place. A networking library needs to be chosen - SDL_net looks like it could work. The already-in-place FreeImage can be used for image resizing. I've got an interface quite different than ES-scraper's in mind - but basically, it'll allow you to manually approve each game's metadata as it's downloaded (since scrapers are pretty inaccurate!) and allow you to leave the network- and processing-intensive tasks to the end (downloading and resizing boxart).

...

• Eventually add proper support for "systems with no games" (e.g. RetroPie's Cave Story and Doom entries), defined with a simple switch in the new es_systems.xml.

You can probably see why I'm waiting until I have spare time for this - most of these are quite coupled together and at the very core of how ES works, and will definitely regress ES while they're work-in-progress. I'm planning on doing the entire thing on another branch at the moment. Also, I have absolutely no promises on the timeframe.

If contributors are interested, we could try and set up some sort of "ES developers communication channel" - GitHub does a great job at a lot of social stuff, but doesn't really provide an avenue for general discussion. I'm not sure what service would work best.

[HorstBaerbel]

There's always the possibility to add an issue and label it as an "enhancement" or "question" and have a discussion about it.

Some of the things I'd like to do in ES when the GUI has stabilized are:

• Convert to GLES2. This opens up possibilities for lots of stuff, including shader effects when systems are changed, items are selected etc.
• Finally implement #66, possibly configurable via themes for every system, but I'll start a discussion when the time comes.

[petrockblog]

@Aloshi Changing es_system.cfg to an XML format is no problem at all!

[leandromacrini]

I agree with @Aloshi. An internal scraper and an edit mode is really needed.

Github is great for personal project with community help but maybe developing organized in a team and using a tasks management tool (like egroupware or trac) and a chat server to comunicate (like irc or skype).

Maybe starting a new project with the people like @petrockblog , @Aloshi , @Bim and any other who can REALLY contribute can be the right way to do this.

For example i have made some changes to the source code of many emulators to support the exit with the "PS" button, having a custom raspian distro connected with an apt repository (called by a graphical action in emulationstation options) can be a good idea.

[Aloshi]

I've been doing some work on that edit mode.

(ignore the framerate, that's been improved since)

There's a lot more going on in the background than is really apparent here. There's behind-the-scenes support for different lists of metadata and different types of metadata (I have everything as just a textbox right now). You can actually enter and delete text in the text boxes and they'll get taller to accommodate. It's still nowhere near functional though.

es_systems.cfg is now in XML, and I also moved to SDL2 for the new text input support (since SDL2 is officially released now). I also removed the old device polling code to use SDL2's JOYDEVICEADDED event and fixed the old InputManager code to use SDL2's concept of JoystickIDs.

You can see my progress on the unstable branch - press F3 to open the not-really-functional metadata editor on the first game for now.

One big problem is that I can't get SDL2's video to initialize on the Pi. I'm expecting that to be fixed with time. As far as I can tell, it has to do with the directfb SDL video driver reporting it's unavailable.

[HorstBaerbel]

I salute you, dear Sir. Marvelous work! ;)

[Aloshi]

Some more of my progress.

Metadata editor looks a bit nicer than it did before. As shown by the buttons, the old GuiBox class has been completely removed in favor of a simple nine patch implementation - images look like this (hardcoded to 16x16px patches at the moment) and are automatically scaled like you'd expect (corners stay the same, sides stretch on one axis, and the center stretch to fill). The fast select box uses the new format as well. Text boxes are also nicer to use than before (there's a proper cursor).

First iteration of the scraper UI. You can use the search box to modify the search name and pick from the top 5 results. Fetching is asynchronous (through Boost.Asio) so you can cancel it/it doesn't freeze until the request is done. Thumbnail images are also fetch asynchronously. The code's not all there yet, but it's almost usable (still need to come up with a way to identify platforms in a scraper-independent way, resolve image URLs when saving, and make UI for system-wide scrapes, both manual and automatic). All should be resolved with more time. :smile:

[Dano-omg]

Having a search screen would be way better than what I was originally asking for. :)

Couple questions:

(1) do you need a keyboard to search? (or is there a way to pop up letters so you can cursor through them w/ the controller?) (ya know, like how netflix does it) :)

(2) is there a separate search screen for each emulator? (cause ideally, i'm picturing one search screen somewhere that would check the rom names for all of them @ once, and by selecting it, it would load in the appropriate emulator) (then again, that might be asking way too much way too soon). :D

(3) let me know when you have a stable version (it looks pretty sweet as is)!

[Aloshi]

The search shown in that picture is for the scraper, not your games. It's for downloading metadata (box art, descriptions, etc.) from the Internet. An actual search function is a lot more feasible now that I've got some of the text entry backend work done. Building a search function into the fast select UI would need some more thought (only two buttons, and right now the GUI is designed to close when you let go of the fast select button).

You do need a keyboard for text entry right now, but the code is structured in such a way that an on-screen keyboard is possible.

I haven't actually gotten to working on this particular request. I'm just posting my progress here because this is where I started. Since I'm almost done with that list I posted a month ago, I can hopefully get to a system select screen next (though I still have a ways to go with the scraper). I have a design in mind involving psuedo-3D.

[billipo]

Super cool, man! Keep it up!

[Aloshi]

This has been implemented ("system select" screen).