Announcing Pegasus Frontend
PlayingKarrde last edited by PlayingKarrde
The game score corruption could happen for similar reasons too, it's possible that something in the ColorOverlay doesn't work properly with Mali 4xx chips, but replacing the shader with a colored variant of the image could be a workaround.
Yep you were right. Have fixed and pushed the update. Good to know.
Have also switched to using FastBlur instead of GaussianBlur. Seems to be a lot better performance wise. I originally didn't use it as it makes text look sort of ghostly (rather than blurred) but since I turned it off for GaussianBlur anyway (didn't look great there either), FastBlur seems fine.
EctoOne last edited by EctoOne
Heya @fluffypillow I just want to reopen the media location discussion.
I know that I was the one that suggested to use folders with the game name and the assets inside. And this still is my preferred way to do it, but the problem is that creating such layout is very annoying because there is no easy way to scrape files and automatically apply that layout. At least not one that I know of and is also available on windows.
So for now I would suggest to use the layout that Skraper creates.
./media /box2dfront /gamename1.png /....... /gamename100.png /screenshot /gamename1.png /....... /gamename100.png /wheel /gamename1.png /....... /gamename100.png /whatever else skraper can do (haven't checked all media types) /gamename1.png /....... /gamename100.png
As an addition to that, it would be great if we could set the RetroArch thumbnail folders as location. There is a positive and a negative side to that option that i can currently think of.
Plus: We could use the asset downloader from RetroArch to get box art, screenshots and title screens without the need to scrape them manually.
Negative: The roms must have the same names as the images.
But for someone like me, who spend the last 4 days manually creating that RetroArch system, it would be a nice option and I don't have to maintain two separate locations.
On the other hand, if we could get that Skraper layout I mentioned, it would be also easier to duplicate that by just copying/renaming the folders.
Maybe it would be possible to have two locations that Pegasus could check.
box2dfront(skraper) = Named_Boxarts(RetroArch),
screenshot(skraper) = Named_Snaps(RetroArch)and
wheel(skraper) = Named_Titles(RetroArch).
Then we could just copy the system folder from the RetroArch thumbnail folder to the rom folder and rename it to
@EctoOne My preference is also the Skraper layout but you can just use the tool I made (it's included with my theme above, check the link) to auto-organise them into the format Pegasus reads. This works fine for me, however the big downside is if you want to add games, Skraper will download everything again since they've been moved from where it looks.
Short term though, my tool will save you a lot of time.
EctoOne last edited by EctoOne
@PlayingKarrde I might take a look at but for now I'm actually fine with the Retroarch xmb design with box art and logos (I replaced the title screens with logos).
But still, it shouldn't be necessary to use multiple programs for images. My initial suggestion to use the folder layout came from that I'm using that method on movies for Kodi and because I was thinking of Rom management first. Having one folder for each game makes it easy to add/remove games.
Also, I'm probably spoiled by tinymediamanager which is such an amazing tool for movie/tv show management. I really wish there was something like that for games. It's more of a database editor and not just a scraper. Maybe the upcoming Kodi version with libretro support will encourage someone to create such tool.
fluffypillow last edited by fluffypillow
@EctoOne Actually Pegasus is flexible enough to add support for both Skraper and RetroArch thumbnails and keeping the current
medialayout. (Never used RetroArch's dowloader though, will need to look into that first.) There could also be some cross-platform program or script that converts from one format to another and back.
Yes, a proper metadata and asset editor would certainly come handy. Might as well take a look into that after the metadata format changes :)
EctoOne last edited by
@fluffypillow Awesome. Oh and RetroArchs just downloads pre-made packages for the available systems. Can't find the actual package links right now but the github page is here: https://github.com/libretro/libretro-thumbnails
[Weekly update] This week was a bit busy for me, so there are only just a few bugfixes:
- Fixed Android navigation issues
- Increased the delay before the videos load in the main theme, hopefully this fixes the Steam issues on Windows
- Updated the Flixnet theme
As for other issues:
@SephirothX2004 about the WikiPad issue from a few days ago, could you send me the log file of a failing launch? The full file, and if possible also your collection files, eg. zipped together uploaded somewhere?
@EctoOne @Purg-Derren I've confirmed the ES, Flixnet and 9999999 themes should show the correct system names. Could you check if the issues still happen after updating them? If yes, could you also zip+upload your log and collection files (that cause the issue)?
some of the logos are appearing black, can you show me a fixed one? I'd be interested what exactly causes the issue (eg. it's something in the file or a bug in the renderer).
@fluffypillow >some of the logos are appearing black,
I'm almost positive it's a rendering thing. The megadrive logo is one of the worst offenders, probably due to the gradient on it. Because emulation station used an older renderer people drew the svgs in a particular way to get them to render properly.
@herb_fargus it is a rendering thing for sure but I think it's a Qt issue. When I get back to my PC I'll share a before and after svg.
Ok so here are the metadata/theme-api breaking changes I'm planning.
First, the metadata format:
- The format of
metadata.txtwould be united, so only one of them will be enough.
- The relevant part of the documentation would be replaced with this draft.
- The two major points are:
- A clean difference between text values and file lists in the format
- Games can consist of more than one file, and as such game entries are defined by their title (
game:), and not a filename.
- Individual files can have custom properties, like name or special launch command, if needed. On the UI side, this would mean you could select the file to launch when starting a game with multiple files. The dialog would be themeable.
As for themes, this is a bit more experimental, as I'll need to do some implementation tests first. Plans are:
- The game- and collection list will be optimized so it could appear in multiple locations at the same time. For example, a recently played list and a regular game list on the same screen.
- An interface for getting the list of all available games (independent of collections) will be added.
- The shortcuts
api.currentGamewill be removed
- Due to technical reasons,
<game>.play()will likely be removed. Instead, games will likely have an
idfield, and there would be something like
api.launchGame(gameId)to use. [This part still needs some experimenting]
api.launchGame(gameId)would open a file launch dialog mentioned at the metadata part (if needed for the game). There would be something like
api.launchGameFile(...)in case you want to implement your own launch dialog.
- For sorting and filtering, you could expect something like this (well, if everything works fine, exactly that).
As for theme options, that's even more experimental. I'm torn between two options, the "let you save anything but require you to write a GUI panel" and the "define the possible options and let Pegasus show them in a common menu". The second option would be more themer friendly I think, but of course that's more work for me :)
If that wins though, the options would be defined in the
theme.cfg, something like this:
option: Toggle Gadget X type: switch default: off option: Alignment of That type: select options: Left Right Center default: Left option: UI Color type: color default: #abc
Well at least these are the plans. As always, comments are welcome!
- The format of
Purg.Derren last edited by
could you also zip+upload your log and collection files (that cause the issue)?
That was a hint! ^^ ... i had a (copy pasted) typo in the psx collections.txt (and psp one) -.-"
The new build of pegasus i can't really test yet ...my anti virus (it periodically do it, with some of your builds) blocks the alpha 10-3 ...even if i put it to exception, it really lags as hell (and i think thats why the anti virus sees a malware there) ...video playback seems not to start at all etc.
Purg.Derren last edited by
@fluffypillow that sounds really great! :)
Theme options and unified "gamelist"-file (and multi-disc/multiple-files - yay!)
Some thoughts after using it extensively for a few weeks now and in multiple different scenarios:
While I like the changes to collections and gamelists, I am not convinced this is the necessary step to take. Right now I would say the number one issue that's holding the launcher back from being open the a mass audience is adding games. Currently, my flow to add a game is add the rom file to my folder, scrape the entire folder again (which takes sometimes as long as 45 minutes on large collections - it has to scrape everything each time due to Pegasus using it's own media file structure), run a script I had to write to organize the media, take the gamelist file the scraper made and drop it in the conversion tool, then replace the metadata.txt with this new info (and if I've made any changes to specific games those will get overwritten unless I'm very careful). This is just to add one game.
The only reason willing to do all that work is because I really see the potential in the launcher and think it will be the best launcher hands down when all said and done.
So combining the collection and metadata sounds good when looking at it in a bubble, but if anything it will make it more difficult with the current workflow. The same goes for multi-disc games - fantastic addition but unless the workflow is made more streamlined it will potentially get in the way more than it currently does (if it were to read .m3u files that might be more convenient).
I guess what I'm getting at is if you have a roadmap for features, working on how users add games should be a top priority. If these changes are necessary in order to reach that goal then great, but ultimately having users manually edit text files should be an absolute last resort for any usable piece of software in my opinion.
@fluffypillow regarding theme options, I don't mind either way to be honest. I think if there was a template example then many theme creators could just hack that together to create something pretty easily. Having a unified one might be nicer for the launcher overall, but I think if theme makers are able to learn qml (which isn't that hard) they can put together a settings screen fairly easily. My comment about usability doesn't apply so much to theme creators as much really.
I think everyone will have their own opinion on how to organise things. Personally I'm all for simplicity so if things can be consolidated the more the better. I've personally never cared for collections so it's not as much of a priority for me.
@herb_fargus simplicity is king. But the concept of collections are necessary otherwise how would you know if you are selecting a snes game vs a mame game for example.
otherwise how would you know if you are selecting a snes game vs a mame game for example
I sort by console. Not Mario games.
@herb_fargus Right, and in this case that's what collections do.
@PlayingKarrde I agree the workflow being less than optimal at the moment. However, the reason I prioritize format updates is exactly because it'd be more difficult to add changes after people start making tools, videos or guides that would depend on some stability. I can also start making, say, a metadata editor program more easily when the planned changes don't loom over my head.
As for what Skraper does and supports, that's not something I can control. When I run on just ~600 NES games and said over 5 hours left, you bet that really made me want to write a scraper too. That said, support for its assets can be added, and will likely come this week. Also looks like it can export metadata in a frontend-independent way too, which might be usable. But if a use case requires you to convert between different file formats of incompatible programs, you'll always need some manual interaction.
@fluffypillow Yep, totally understand. I think maybe my comment came off a bit more confrontational than I intended. I think I'm just trying to explain the potential I see but the main thing still holding it back. Long term if it was as easy to use as, say Plex, it could potentially be the most popular launcher out there.
But it sounds like you are thinking long term so I'm on board with the changes you mentioned. I agree with everything else you say.