I didn't blog about Games since quite some time and the app changed a lot since 3.18. 3.20 was quite a small update featurewise: it added support for MAME and Neo Geo Pocket games, added the About dialog, allowed l10n of the application, added a Preferences window listing the available plugins and fixed other small bugs, but this release mainly saw refactoring work with the introduction of the plugins system where plugins allow to list games: the Steam plugin lists Steam games and the SNES plugin lists SNES games.
So with 3.20, Games was ready to be improved upon and improvement there was! 3.22 is the first properly usable version of Games
The biggest change this cycle is the number of contributors to Games' codebase, first of all with two GSoC interns working on it: Megh Parikh and Ricard Gascons did a great job as I will detail it later. But Games didn't gain contributors only via GSoC: Bastien Nocera has been helping on the project since a year or so and got even more involved recently, and Mathieu Bridon implemented several new features and helped a lot working on Flatpak integration as well as on shipping the Libretro cores.
Supported Game Types
We disambiguated several games related MIME types in shared-mime-info:
- SG-1000 and Game Gear games got disambiguated from the Master System ones;
- Mega-CD, 32X and Sega Pico games got disambiguated from the Mega Drive ones;
- Game Boy Color games got disambiguated from the Game Boy ones.
This disambiguation done, Games wouldn't be able to detect these games as it was only looking for Master System, Mega Drive and Game Boy games, hence we now suport them explicitly. Games also gained support for new systems, here are the newly supported systems in 3.22:
- Atari 2600;
- Atari 7800;
- Game Boy Color;
- Game Gear;
- Mega-CD — a.k.a. Sega CD;
- Mega-CD 32X — a.k.a. Sega CD 32X;
- Mega Drive 32X — a.k.a. Genesis 32X, Super 32X and Mega 32X;
- PC-Engine CD-ROM² and its variants — a.k.a. TurboGrafx-CD;
- Sega Pico — a.k.a. Kids Computer Pico;
Keep in mind that what we mean by support is that Games can list the games for this system, it doesn't mean it can run them — this ability depends on other factors such as whether a Libretro core able to run the game is installed — nor that it will run properly — for example, games requiring a mouse aren't supported yet.
Covers and Icons
Batien Nocera wrote a Grilo plugin retrieving info from TheGamesDB.net and I made most game types use this in Games. The previously discussed new MIME types have been added to shared-mime-info to allow us to support more game types but also to discriminate properly the different types in this plugin: before that we had no proper way to know if a Game Boy game was a Game Boy one or a Game Boy Color one.
Games can automatically fetch covers from TheGamesDB.net.
Maybe TheGamesDB.net doesn't have a cover for your game, but that's not a problem: this website is crowdsourced, contribute a cover and it will appear in Games!
What if you simply don't like the cover the website returned for any reason: no problem, if you have a game located at /path/to/mario.nes, an image file will be used as the game's cover if it's named like:
- /path/to/cover.* or
where * is any extension.
If you have cover image files alongside your game files…
…Games will use them for the games' thumbnails.
Headers of Steam games are downloaded from the Steam store's website and used as the game's cover.
With pretty covers to show, we decided to double the size of the game thumbnails (from 128 pixels to 256 pixels) to better appreciate them! If your game still has no cover to display, it may have an icon: desktop and Steam games already displayed their icon, but now icons are also extracted from LÖVE packages and Nintendo DS games.
I finally found some time to work on the fullscreen mode! It is available to Libretro based games: on the game display page at the top right corner you will find a Fullscreen button allowing you to switch to the fullscreen mode; in this mode the headerbar and the pointer will be hidden after 2 seconds of pointer inactivity, just move the pointer to reveal them.
Megh Parikh added support for gamepads to play Libretro based games; the gamepads are discovered with udev and are read with libevdev.
He implemented support for the format used by SDL2 to map the input events sent by the gamepad into meaningful gamepad events: with that, Games can know for any mapped gamepad that the Start button got pressed rather than the 10th button. Games comes with a large database of gamepad mappings.
Linux's input system has proper gamepad inputs (buttons, etc.), even though only a few gamepads send these proper events we should support them even if Games doesn't have a mapping for them: we already can know which button is which one! Hence I added support for these: to work with Games, your gamepad need to send proper gamepad events or to have a mapping available. If your gamepad doesn't work with the application, consider it a bug!
Games doesn't have a user interface to handle the gamepads — yet? — but it doesn't need it to be usable! Megh implemented an automatic way to assign a controller to a player, here is how it works:
- when a gamepad is plugged in, it is assigned to the first player with no gamepad;
- when a gamepad is plugged out, the player which had it have no gamepad instead and any other player keep its controller;
- the keyboard is assigned to the first player with no controller after reassigning the gamepads.
If your gamepad doesn't work with games, consider it a bug too!
PlayStation support has been a big focus for Ricard Gascons and to a lesser extend for myself. Ricard added multi disc support for PlayStation games: if the game you are playing has multiple discs then the header bar will contain a button with a CD icon, pressing it will reveal a list of the discs of the game, selecting one will switch the disc in use for this game, allowing you to keep progressing almost seamlessly.
Some discs have a title, if it's the case it will be displayed rather than Disc n as the disc's title.
The DualShock controller for the PlayStation which has been introduced after the launch of the console has two analog thumbsticks and several games take advantage of it. These controllers feature a button allowing to present the gamepad as a DualShock controller or as a classic controller, this was a workaround for compatibility purpose as earlier games wouldn't work with a DualShock. For gamepads to work seamlessly with any games in Games we needed to automatically select the correct gamepad type: if your game doesn't support DualShock, we present the gamepads as classic ones, otherwise we present them as DualShocks.
To achieve grouping several discs into a single game, knowing a disc's title and knowing the supported gamepad types, Games ship a database containing these informations so it can work out of the box; this also allow Games to display a good title for any known game .This database is built by dumping the PlayStation DataCenter website, if you find an oddity, it's either a bug in our dumper or in the website!
Pause on Focus-Out
You probably don't want to lose the control of the game because the window loses its focus and when playing you'll likely have the window focused, so I made Games pause a running game when the main window loses the focus and resume the game when it gains it back. If the window loses its focus to the Shell, the pause is delayed by half a second, allowing to pause when the shell takes the focus while avoiding annoying micropauses when a short notification appears on screen.
To avoid the screen to go black when playing a game, Mathieu added a screensaver inhibitor; and to avoid to loose a running game he also added a session inhibitor: when trying to close your session you'll be warned if a game is running.
Resume and Quit Dialogs
Unfortunately some integrated games can't be saved and resumed, hence quitting such a game implies you will lose your progress. To be sure you know that, I added a dialog letting you to quit the game and to lose your progress or to keep playing.
The dialog proposing you to resume the game or to start it over has been overhauled: it used to allow you to:
- resume the game with a Resume button;
- restart the game with a Main Menu button;
- go back to the games list with a Cancel button.
This was confusing: Main Menu took you back to the game's title screen while many thought it moved you to the games list; also the Cancel button wasn't really useful as you could as well choose to resume the game and then quit it. So Mathieu refactored it by renaming the Main Menu button into Restart and by removing the Cancel button.
Mathieu then added a new dialog letting you to choose what to do in case resuming the game failed for any reason: you can reset the game with a Reset button or choose to do nothing and go back to the games list with a Cancel button.
There was an annoying bug which made the sound stop working after playing a game for some time, it was caused mainly by a poor usage of PulseAudio in retro-gtk, it has been fixed by using the PulseAudio Simple API instead. Another problem was that an error made any game run at 60 frames per second rather than the rate needed by the game's system. I fixed both problems into retro-gtk so sound and game speed should work as expected.
Running a Game Failed
When Games failed to run a game it used to display a message in an infobox at the top of the collection view, this didn't work well so I replaced this by the following page.
Bastien and Mathieu worked a lot to make Games work better with Flatpak: they found missing functionalities in Flatpak which are now shipped, they made gamepads work in the sandbox, they helped making the nightly flatpak build, they added some Libretro cores to Games' nightly Flatpak… so many things I probably forgot some.
Speaking of Libretro cores, this is the biggest problem when distributing Games. We are currently relying on retro-plugins to distribute a curated set of Libretro cores but it doesn't work well:
- it isn't very useful as it simply ships the content of other projects;
- it limits Games to the cores shipped in it and there aren't many;
- Games contains hardcoded information we need about these cores, which is terrible;
- it gives us the burden to maintain this module when we have many more important things to work on.
retro-plugins was good when the project was young but now it needs a better way to ship Libretro cores. The libretro-super project seems to be the de facto standard way to install Libretro cores, it installs them in the $(libdir)/libretro directory with info files for each core. We started working on extending these info files to make them include the information we need: a way to pick the best core to run the games we want and whether the core supports resuming the games. We will help hardening this solution so we can deprecate retro-plugins and use this instead.
We started testing this solution in the Flatpak version of games: it doesn't depends on retro-plugins, instead we directly ship some Libretro cores with an extended info file.
Despite remaining rough edges and lacking features, I'm extremely proud of this release as it marks the first really usable version of Games!