Please Test: Adding support for "All", "Favorites" and "Last Played" systems

[lilbud]

@pjft I have updated the dark theme to support this custom build. There are 2 extra backgrounds which add the screensaver prompt (bg-pjft.png) and Options + Favorite prompts (systembg-pjft.png) Both have been added to the Switch-Dark repository

[ohmycommodore]

A great, functional idea! Looking forward to using this!

[cyperghost]

IO theme was pushed to Virtual Systems runlevel :)
https://retropie.org.uk/forum/topic/3853/io-new-theme/41
also available on Github

[pjft]

@cyperghost Sorry, I missed answering this earlier! Thanks for the work here and for the suggestions.

Don't take any of what I'm saying the wrong way, as the internet can lead to wrong interpretations, so bear that in mind when reading this :)

I briefly considered it but I decided not to translate the code to C++. It's not because it isn't good code, but because I don't think it's the right approach here, as well as that porting code is in my opinion a lot more effort than writing it from scratch. :) That's also the same reason I don't think I'll be implementing the "Y-button" to call a bash-file either.

My belief is that ES should be kept simple and accessible for all users, and most of these developments, while great for the community, realistically are only accessible to people who are a bit more advanced in their technical abilities than needed to enjoy RetroPie.

• In the current case, we don't need a FAV file as ES knows how to execute any game it has loaded. We only need to store a ROM path, and rely on es_systems.cfg to know, based on the file's path, how to execute it.
• The user should also be able to create collections of games without having to resort to manually creating text files in the command-line or an editor, or creating symbolic links in separate folders, or duplicating ROMs in their system.

I know we do it because we enjoy the challenge and tinkering :) But in doing so we are restricting the appeal and openness of RetroPie as a platform to a smaller audience.

My goal - after this is eventually merged - is to continue developing it to allow users to manage game collections (that's likely the external final name for "virtual systems" :) ) inside ES.

They will be based on unused existing folders in the user's theme, as ES has a 1:1 relationship to "system-level entries" and "theme folders". And I don't want users to shoot themselves in the foot by creating collections that will not be themed and look ugly as hell. This will address most of the use cases people have been playing with, when creating a "megaman" theme folder or something, and then packing it with megaman games, or "fighting", "sports" or whatever.

Creating custom collections (without an existing theme folder) is out of scope, as there are too many sub-optimally defined user flows, and the end user experience will always be less than desirable.

Hope this clarifies the roadmap and scope I have in mind for these developments in general.

If there's any critical use case I'm missing, please anyone let me know, and I'll take it into consideration!

Thanks.

[cyperghost]

@pjft I totally agree with you.
One usecase is left - if you use no XML file and disabled parsing of them ;)
That's an easy option to speed up the whole ES booting and shutdown process....

But as you said and I already understand... The usecase of the usual user and the user who wants to look what all can be done stands in no relation. Maybe 99:1 and if in future version it is possible to just add new system the relation changes maybe from 99:1 to 999:1.

So thanks for your and @meleu words.

[pjft]

@cyperghost

What I said earlier is that if you don't use gamelists, you can't really benefit from Favorites (as favorites relies on the metadata) and last played (as it relies on the "last played" date).

That being said, you'll be able to add any game to any custom system, and nobody forbids from creating your own custom collection of "favorites", based on a separate theme folder.

That will not be in any way related to gamelist data - we'll store those separately, in files with only the file paths.

Sorry that that wasn't clear :)

[cyperghost]

@pjft Take it easy.... it's clear enough for me
So how does this files look like (filename) and what is the content of these? Just the file path? How can runcommand to be used to load the correct system?
As you see I was in the same situation ;)

[pjft]

@cyperghost Just the file path.

As I stated, ES has the system settings in es_systems.cfg for the respective folders where the source roms are. No new folders need to be created. No files need to be moved around.

I don't plan on creating yet another file type that's redundant.

[cyperghost]

@pjft Man it's so easy... you are so genious ;)
Shame on me..... The solution is so brilliant!

You just compare the file path related to the rom ;)

So a Gameboy file is stored to ~/RetroPie/roms/gb/
You save the ROM Tetris (UE) 1.1.gb into a annother file Tetris (UE) 1.1.gb for ex. as gamelist???
In the Tetris (UE) 1.1.gbis just the filepath+romname stored ~/RetroPie/roms/gb/Tetris (UE) 1.1.gb

We "launch" that file and now you compare the filestring after the last / with the es_system.cfg credentials ... Voila you know that must be a GBfile

Ahhhhhhhhhhhhhhhh... Easy, effictive, brilliant
Congrats @pjft

Hope I got that now ;)

[pjft]

That is indeed the gist of it, but since it all happens inside ES, it's all much simpler - no need for string parsing and all that.

The changes I've made in this PR make the system execution data (i.e. knowing it's a GB rom) be tied to the actual game entry in ES, rather than to the "system" entry. As such, regardless of how many collections a game it belongs to, it always knows what to run it in.

For the case you're describing, it will run it as if you had clicked the Tetris entry in the GB list - which is what currently happens, regardless of whether you're clicking it in "All Games", "Favorites" or "Last Played".

We'll store

/home/pi/RetroPie/roms/arcade/ffight.zip
/home/pi/RetroPie/roms/gb/gargoylesquest.zip
/home/pi/RetroPie/roms/nes/ducktales.zip
/home/pi/RetroPie/roms/fba/sf2.zip

for a Capcom system, for instance.

At least that's how I envision it. Whether that will work - and whether I have the ability to pull it off - remains to be seen. But I'm confident - the hardest part seems to have been done.

[cyperghost]

@pjft Whatever ... But I agree that those system hacks may be abolished in future or are just useable in a rare rare cases.
The FAV description got one advantage :) You can use it for system calls like the retropie menu :)
Thanks for the long and deep solid explanation

[cyperghost]

@pjft
About coding style ... nice description of crap

It's not because it isn't good code, but because I don't think it's the right approach here, as well as that porting code is in my opinion a lot more effort than writing it from scratch. :)

1. There are the same routines used for 4 or 5 times in that code. That would be better outsourced by an easy include or function call to strip down that source code.
2. The variables are not well definated and missused for other values (not good coding style)
3. I oversized the include by making file access compatible to VB an INCLUDE of only file.bi would be better and reduce footprint size.
4. The comments ... are there but ... rare - better than nothing ;)
5. Who needs taps and spaces? It looks like a mess

The only good style (imho) is the use of while-loops with definated ends and case selections! And no goto :) A good goto is allowed!

---

But back to topic. I'm looking forward that is branch is the next breakthrough in RetroPie. It's really a pitty that it tooks several years to include a milestone like this. Thank you very much :)

btw. Hope that the PR of IO will be accepted

[mattrixk]

@cyperghost said in Please Test: Adding support for "All", "Favorites" and "Last Played" systems:

Hope that the PR of IO will be accepted

Your wish has been granted.

Seriously though, I'm looking forward to this all being finalised. I've been trying to follow meleu's and TMNTturtlguy's virtual systems stuff, but I've been getting confused. I've been getting confused reading this thread too, but maybe that's just because it's too early in the morning for my brain to work properly. I'm just going to wait until it becomes part of core so I don't have to resort to hacks.

[meleu]

@mattrixk said in Please Test: Adding support for "All", "Favorites" and "Last Played" systems:

I'm just going to wait until it becomes part of core so I don't have to resort to hacks.

It's a wise decision. The @pjft work on this stuff is very well done and much more user-friendly than those hacks.

By the way, I composed a couplet in @pjft honor:

Paulo's code is great and can't be beat
If I coded like him that would be neat

[lilbud]

@meleu

[jdrassa]

@pjft said in Please Test: Adding support for "All", "Favorites" and "Last Played" systems:

They will be based on unused existing folders in the user's theme, as ES has a 1:1 relationship to "system-level entries" and "theme folders". And I don't want users to shoot themselves in the foot by creating collections that will not be themed and look ugly as hell. This will address most of the use cases people have been playing with, when creating a "megaman" theme folder or something, and then packing it with megaman games, or "fighting", "sports" or whatever.

Creating custom collections (without an existing theme folder) is out of scope, as there are too many sub-optimally defined user flows, and the end user experience will always be less than desirable.

I really need to get back around to finishing up the work I was doing on theme variables. Part of that also included the concept of a default theme that would be applied if there was not a theme for the selected "system".

[pjft]

@jdrassa I think that would be fantastic. I toyed with the idea of giving the option of reusing the first entry in the theme, but without the items that are usually very system specific (name, logo) but it felt quite hacky and not like something that would really produce good results.

It was going to be a "compatibility mode". Geez. The workarounds we consider.

[pjft]

@meleu @lilbud Thanks for the couplet and for the image!

If some people have a full-fledged robot @meleu printed out, so can I have this :)

[pjft]

Hi all.

This weekend was spent cleaning up the current PR thanks to @zigurana's very timely and relevant comments on it!

As such, I'd appreciate it if anyone would have the availability and patience to recompile the latest build and test it/use it the same way as before.

Functionality-wise it should be equivalent, just more compliant with proper coding guidelines :)

If nobody runs into any trouble, that's one step closer to getting this approved - and one step closer to me starting to work on the custom collections piece.

Thanks in advance for your time as usual, and hope you have a great week!

[cyperghost]

Can anyone provide the binary please?

@pjft Thank you for your effort in making good things better. But do you see a chance to implent @hex 's power saving mod? Can a pull request to your mod be made to implent this?