Announcing Pegasus Frontend

[StephanePare]

Just for the grid view I'd give your front end a try once it's out of alpha/beta :)

[AndersHP]

@stephanepare I can recommend this front end. I was a bit reluctant to try it already, because it's in "Alpha" only, since I'm no coder and just wants something that works and looks good.

I'm experiencing very few bugs and I'm only using Pegasus by now.

After I scraped with Universal XML scraper with box art, video and logos, I think this looks super awesome, I really love the speed it runs with, and the grid view is so neat.

I'm emulating NES, SNES, MAME, NeoGeo and Master System, so cannot tell how it works with other consoles, but my recommendation is that you give it a whirl.

[fluffypillow]

Yeah, there are still some features I'd like to implement before calling this a beta, but the development is going ok, and it shouldn't be that far now :)

As for the weekly changelog,

• Fixed asset loading on Windows
• Fixed theme loading on Windows

which might not sound much, however, in the "background" I was also quite busy working on a stable interface for theming, configuration and making tests for them. This should be done by next week. As a side effect, it's very likely that one of the next releases will have custom categories support, instant theme reloading and faster startup. I'll also post a proposal for the configuration files in the next few days. After we have a stable interface and config file format, I'll start writing some proper documentation.

[halfmanhalfcake]

@fluffypillow look forward to the update next week for custom categories.

Will the proposal for config files include config for games without ES? Would be great to use this frontend independently, without ES, (and with, of course).

Request from me :)
Is it possible to create a 'foundation/beginner' theme as a starter theme for theme creators learning the code? I've played around with flixnet and the default theme, but would love a simple, plain theme, just a title and gridview?

[fluffypillow]

@halfmanhalfcake Yes and yes :)

The proposal will be about Pegagasus' own config files, exactly for the reason you've mentioned. I'd also like to see if someone finds any issue with the format before I start coding/using it.

I'd like to have at least 2-3 example themes built from scratch in the documentation/guide. The default theme is a bit hack-ish due to the variable column count of the grid and the animations of the top bar, but I could imagine building the Flixnet theme or eg. the PlayStation XMB UI as a tutorial (after the plain title+grid).

[AndersHP]

A plee to all future theme makers: please remember us with 4:3 and 5:4 monitors! :)

[halfmanhalfcake]

@fluffypillow great, look forward to it
The more basic the better the foundation theme, for beginners like me :)

[fluffypillow]

A huge set of internal changes has just landed: custom categories are now technically possible (except they aren't read from any config file yet), the available data structures available for the themes have been reorganized, and a lot of new automatic tests have been added for them. The Flixnet theme has also been updated. These changes don't have visible effect yet, they are the preparation for a stable interface. As always, feel free to report if you notice any issues.

[lilbud]

@fluffypillow I'll test tomorrow afternoon and let you know of any issues.

Sadly have no time tonight

[fluffypillow]

Ok, here is the current concept for Pegasus' own config and metadata files. This is something I wouldn't want to change once it's implemented so feel free to share your opinions. There's also a GitHub issue here.

How it works

Pegasus will store a list of directories that will be checked for games/roms. In every of such directory, there should be a file that describes (one or more) collections, and another that describes metadata for each game. The proposed name for them is collections.pegasus.txt and metadata.pegasus.txt.

File format

As a user (of my own program in this case), I want a simple text file in simple, readable format, that I can edit on any platform with any (minimally competent) text editor. I don't want to care about implementation details: I'm not going to hunt missing XML-tags, curly braces, semicolons or tabs/spaces. However, it must support Unicode text, multiline values and simple lists. It should be easy to edit and extend, yet something that doesn't take forever to read by the program.

Here's a more technical definition of the format, with examples for both the collections and metadata file further below. It was mainly inspired by the INI, Debian-control and nodejs-ini/npmrc formats, so some things might be familiar:

• the files are in Unicode (UTF-8 encoded without BOM)
• both the Unix and Windows-style line endings are supported, with Unix being preferred
• the file is processed line by line
• lines starting with # or ; are comments, and empty lines are ignored
• a file contains one or more sections, and sections are defined as [sectionname]
• sections contain settings, which are in option = value form
• lines starting with spaces or tabs are concatenated to the previous option's value
• if an option name ends with [] (ie. option[] = value), then option will be treated as a list, and value will be added to it as an element

Ok, let's see how that applies to the two files:

Collections file

The collection file defines one or more collections. You can select which files belong to a collection either by filtering for file extension (extensions), listing the file names (files[]), or using regular expressions (regex). Removing files from the collection can be done similarly, but with the ignore- prefix. If a collection is defined in multiple directories (with the same section name), the separate collections are merged into one (eg. a collection for all Zelda games but on different platforms).

explanation	line #	file contents
define a new collection called nes	1	[nes]
collections can have a proper name	2	name = Nintendo Entertainment System
I want it to include all .nes files	3	extensions = nes
except the following games	4	ignored-files[] = mybuggygame.nes
and	5	ignored-files[] = myduplicategame.nes
the launch command	6	launch = myemulator ${FILEPATH}
empty line to look fancy	7
define a new collection called mario	8	[mario]
with a name	9	name = Mario games
I want it to contain these files	10	files[] = Super Mario Bros.nes
and	10	files[] = Super Mario Bros 2.nes
and also	10	files[] = Super Mario Bros 3.nes
if the launch command was already defined for a file by a previous collection, I don't need to repeat it, so I'm commenting this line out	11	# launch = myemulator ${FILEPATH}
optional empty line	12
let's say I'm interested in having a collection of multi-game pirate cartridges	13	[pirate-multigame]
in case you forgot or don't want to name the collection, the section name will be used	14	name = Multi-game Pirate Carts
I want to include all files whose name contain "<somenumbers>-in-1"; regular expressions can be used if you're familiar with them (you can find tutorials on the net)	15	regex = \d+.in.1

So that was the collections file; let's see the metadata now.

Metadata file

Every file can have its own section where the metadata is defined.

explanation	line #	file contents
section names are the file names	1	[Super Mario Bros.nes]
some metadata	2	title = Super Mario Bros.
	3	developer = Nintendo
	4	publisher = Nintendo
	5	genres[] = platformer
	6	players = 1-2
a multiline text example	7	description = This is a really really long,
lines starting with spacing will get appended to description	8	multiline description, in fact it's so long
	9	it spans three lines!
a short summary of (one paragraph or about 3-4 sentences)	10	summary = Hello, I'm a short summary,
	11	I'll just stop at being two lines long.
	12	# cloneof = filename.nes
year(-month(-date)) (lexical order)	13	release = 1985-09-13
	14	rating = 86%
custom launch command to override the one set by a collection	15	# launch = myemulator -someflag ${FILEPATH}
the format can be extended with additional fields, prefixed with x-; they may not be used by Pegasus, but other tools can add additional informations with it	16	x-scraper-source = somescraper.com
	17	x-retroarchievements-id = 123456

Aand that's the metadata file.

So this is roughly the format I'm planning. What do you think?

(this post got a bit long, sorry about that)

PS. Example files without comments

[nes]
name = Nintendo Entertainment System
extensions = nes
ignored-files[] = mybuggygame.nes
ignored-files[] = myduplicategame.nes
launch = myemulator ${FILEPATH}

[mario]
name = Mario games
files[] = Super Mario Bros.nes
files[] = Super Mario Bros 2.nes
files[] = Super Mario Bros 3.nes

[pirate-multigame]
name = Multi-game
regex = \d+.in.1

[Super Mario Bros.nes]
title = Super Mario Bros.
developer = Nintendo
publisher = Nintendo
genres[] = platformer
players = 1-2
description = This is a really really long,
    multiline description, in fact it's so long
    it spans three lines!
summary = Hello, I'm a short summary,
    I'll just stop at being two lines long.
release = 1985-09-13
rating = 86%
x-scraper-source = somescraper.com
x-retroarchievements-id = 123456

[halfmanhalfcake]

Great work. A couple of questions...

1. Is there a requirement to state the images in the metadata file? or can we continue to use the .../media folder as we do currently?

2. I assume this method of config files can be used to open windows (.exe) games?

3. How will pegasus know what directories to look for?

[fluffypillow]

@halfmanhalfcake

• The media directory will continue to work, there are no fixed asset fields in the metadata format at the moment. I could imagine some extended asset support in the future though.
• Yes, you can either set the launch command for each game separately, or list the path to the game exes in a collection, then use ${FILEPATH} as the launch command. You probably don't want to use exe as an extension due to some games have multiple of them.
• There'll be an option for that in Pegasus (eventually), and the search directories will be stored in the program's settings file. Other sources like the ES2 systems.cfg could also be used.

[hi-ban]

@fluffypillow if i was the one developing pegasus, i'd make it use the exact same format as emulationstation. That would ensure perfect compatibility, and it would be much easier for everyone to switch between ES and pegasus with no need to manually add thousands of games to a gamelist or create a custom scraper just for pegasus.

[AndersHP]

I was also thinking; what happens to us with perfect scraped and described games now, after this is implemented? Do we have to start all over again?

[fluffypillow]

@hi-ban personally I don't like XML as a user-side data format, and I'm willing to differ in that. The ES2 compatibility will still be available though (that is, this config file style is optional), and I'm also planning to create conversion tools between the two formats.

@AndersHP not at all, I'd like to create some tools for conversion between the two formats, like scripts for on-device conversion and also a webpage for when you're scraping on PC. My scraped data is in the ES2 files too, after all :)

[AndersHP]

Am I the only one, who cannot get the runcommand menu to work from Pegasus? Game just boots. I have to goto Emulationstation to switch settings for roms, then return to Pegasus afterwards...

[Darksavior]

@andershp I never had an issue. I did have an issue now that I can't run pegasus at all if it's transferred from pc to pi. It warns me about some security hole ueid or something..

Installing pegasus from retropie-setup works. I just had to point autostart to the pegasus location.

[fluffypillow]

@AndersHP seems to work fine for me, on a Pi 3 running an older RetroPie install. I'll check if it happens with the latest version. Do you see anything weird in the logs of Pegasus or runcommand?

@Darksavior interesting, can you check the exact warning message? There was also a Permission denied error report some time ago, and it turned out users cannot launch executables on NTFS file systems by default.

[fluffypillow]

@AndersHP also works fine on an updated RetroPie, hmm.

[fluffypillow]

Also the weekly changelog (or rather, a summary):

• large number of internal changes, as a base for future updates (post)
• new config file proposal (post)

In addition, I've just added theme reloading support (with F5); will likely come handy in the future. And since we've also reached alpha4+100, I've reset the counter, we're now in the alpha 5 phase (yay!).