Announcing Pegasus Frontend

[fluffypillow]

@geekob yeah I really should add support for that. It's a pain opening directories with several thousand assets...

There's one corner case I'm afraid of is how should assets be recognized for games in subdirectories. Like, let's say I have /game.rom and /subdir/game.rom. Then, when checking for assets and there's a /media/game.png and /media/subdir/game.png, it's clear which asset belongs to which game. With subfolder support for media, there could be files like /media/whatever/something/game.png -- to which of the games should this asset belong then?

Of course, there's also the choice of making some drastic changes like replacing the whole logic with something entirely different/new. I'm open to ideas/comments about this topic too.

[GeekOB]

@fluffypillow I understand your concern, I'm not sure if that is the case with Skraper though.
EmulationStation displays the assets correctly, I don't see why Pegasus wouldn't?

Skraper defaults to <gamedir> then creates a media folder with subfolders for the different types of media, all the files within those folders have the same name as the rom file.
For example:

arcade/
├─ game1.rom
├─ game2.rom
├─ game3.rom
└─ media/
.....└─ images/ (this folder content is actually being recognized by Pegasus)
.........├─game1.jpg
.........├─ game2.jpg
.........└─ game3.jpg
.....└─ wheel/
..........├─game1.jpg
..........├─ game2.jpg
..........└─ game3.jpg

Would this pattern match all games/platforms in your experience?

[fluffypillow]

@geekob So I was thinking a bit more about this issue...

The way asset searching implemented currently is to go trough the files in media and decide the asset's type based on the additional suffix, and the game it belongs to based on the hierarchy of the files, which matches the game dir's.

The way you propose is to have a layer or directories for each asset type under media, decide the assets's type based on which of these "main directories" the file is, and the game based on the hierarchy inside each of these main directories.

Both ways are fine on their own, with different pros and cons. Mixing them will likely not end up well though, in my opinion, as well as being error prone and way too many corner cases to take care of. So we should choose one then; I think

• The first one is easier to manage per-game, as all the assets for an game are in the same directory, so you can select/move/edit them together. It is plain simple to use (ie. drop into media and done) and the files usually clearly match exactly one game. On the other hand, the suffixes can be annoying/ugly and not always clearly decideable (eg. things like when a game is called as a suffix). The media dir is also unorganized and can end up with a large amount of files (also taking more time to open).
• The second one is better organized, with the asset subdirs and the hierarchy in them looking up games is also easy and always clear. The suffixes don't clutter the file names, so loading times could be a tiny amount faster (the suffix guesswork can be removed). On the other hand if I want to modify all files for a game (eg. because I renamed the rom), I have to visit each asset dir one by one. The files also have the same name in the different directories so they can't be just copied directly into a common folder.

Based on this I'm actually leaning towards option #2 (less code + performance yay!), but I'd be happy to hear the opinion of others.

Also, just a crazy late night idea, but another option could be to have a directory for each game, which would then contain the different kind of assets. It would provide fast lookup for games, readable file names and easy editing. It'd be totally incompatible with the current scrapers though, but that wouldn't be hard to fix with a script. Well, at least this is just an idea.

On another topic, the keyboard layout changing might be simpler than I thought, it might come in the next update.

(sorry for the long post, it's late and I should probably sleep already)

[GeekOB]

@fluffypillow thanks, I wish I could take credit for option #2 but it's the way that Skraper organizes all the media, I "migrated" from the suffix-naming method because I liked the former better.
Pegasus looks amazing and I can see it can only get better. Once again, thank you for your disposition to receive feedback and the attention to detail.

[EctoOne]

@fluffypillow said in Announcing Pegasus Frontend:

Also, just a crazy late night idea, but another option could be to have a directory for each game, which would then contain the different kind of assets. It would provide fast lookup for games, readable file names and easy editing. It'd be totally incompatible with the current scrapers though, but that wouldn't be hard to fix with a script. Well, at least this is just an idea.

I was hoping that ES would adapt that for a while now. It would be the same method that Kodi uses for movies. The folder has the same name as the movie, same name also for the nfo file with all the metadata. The images are named after what they are (poster.jpg, fanart.jpg, thumb.jpg etc.). It would make adding/removing games so much cleaner, but I guess as long as we don't use some sort of internal database, that can be filled with data from several files, it won't happen.

On another topic, the keyboard layout changing might be simpler than I thought, it might come in the next update.

Awesome.

[Darksavior]

@fluffypillow Are custom sections themes in the works? I'd just about given up setting up the arcade section with the default "cart" layout. Flyer art makes it difficult to recognize a game and I can't find marquee art for every game. I'd like to have ONLY the arcade section like this:

[fluffypillow]

@darksavior each theme is standalone, with their own looks, logic and data handling, so they can't be mixed together in a general way. However, it is entirely possible to create a theme that does provide a different style for a particular collection.

[tronkyfran]

@fluffypillow In fact, if you are more or less comfortable programming you can do almost anything with QT and Pegasus, damn, I can do only trial&error and can get things done!!!!

[GeekOB]

Hey there @tronkyfran do you have any themes available for Pegasus? I'd love to try it/them out!

[tronkyfran]

@geekob Sadly, not yet, I have one "test drive" with an amstrad only theme but its not really ready for release. Im kind of slow making my art and, on top of that, I have to fight with my inability programming, hehe!!

[GeekOB]

@tronkyfran

[fluffypillow]

The good news: keyboard layout changing is almost done, I'll still need to fix some UI issues and make tests. The keys can also be queried in the themes, so it's no longer necessary to hardcode certain combinations.

The bad news: it is not possible at the moment to use keys other than the arrows for navigation. They're hardcoded in some lower level code and would require digging deeper to fix that.

[Newellj79]

@fluffypillow
Changing the keyboard keys was all I've been waiting on to make the switch. Can't wait!

[AndersHP]

@tronkyfran how about a teaser shot of how your upcoming theme will look like? :) Loved your ES theme and I'm still using your art as launch images for every system I use.

[dirty_monkee]

I didn't even know I needed this in my life. Really like the "Netflix" Style theme from way early on in post.

[EctoOne]

@andershp there was a preview in the theme thread although maybe @tronkyfran is working on something different.

[tronkyfran]

@ectoone Well, Im changing the background(wasnt very good) and remaking some cover art, at the end its a lot of work, but when its finished I suppose the rest of the systems will be easier.

[fluffypillow]

All right, the controls configuration is now online!

• It is now possible to change which keyboard keys do what (see Settings → Controls)
• Furthermore, it is also possible to change what the gamepad buttons do (ie. you can swap A/B now)
• The registered keys can now be queried in themes using api.keys (documentation later), so it's no longer necessary to hardcode the defaults
• As mentioned previously, the default keys for opening the details and filters panel have been changed to I and F (but now they can be changed). Navigation is fixed to the arrow keys/dpad due to technical reasons.
• The the gamepad layout screen have been moved under Settings. (In turn, the theme selector will likely move out to a full menu in the future.)
• The settings file have been slightly changed, data source settings will reset (sorry!)
• Updated the key handling in every part of the code. If something doesn't work as intended, please report!
• Minor menu improvements, fixes and memory optimizations

[halfmanhalfcake]

Keep up the good work. Glad to see the custom key binding options :)

[fluffypillow]

Ok, the new theme Api functions are now documented on the reference page.

As for the next week(s), the plan is to change the asset searching to option #3 as discussed previously (unless there's a strong argument against that) and make some scripts to help with the conversion. Then finally start making themes.