GNOME Games 3.24

GNOME 3.24 will be out in a few weeks and with it will come Games 3.24. This new version will offer a few new features and many refinements, some of which have been implemented by new contributors theawless and Radhika Dua, kudos to them!

Find how to get the latest nightly and (soon) stable Flatpak versions of Games on its web page.

A Libretro Core Descriptor Specification

In its version 3.22, Games stopped using a hardcoded list of well known Libretro cores and instead looked for the right one to run a game by parsing files describing their corresponding Libretro core’s capabilities. These files came from the libretro-super repository and were slightly modified to better suit Games’ needs.

The concept was great but the format of these files proved to be not very well suited for the job: many information were not useful to Games, some information it needed were lacking, the syntax wasn’t specified, complex cases like firmwares were implemented in a messy way, some useful information were present as comments and hence were not reliable… a better designed format fixing these problems was needed. Taking the desktop entry specification as a model, the Libretro core descriptor specification was born.

In order to use them, Games requires cores to come with a descriptor valid according to this specification — packagers, please remember to ship the needed .libretro files with your Libretro cores, you can find the ones used with the Flatpak version here.

Smooth and Sharp Video Output

So far, the video output of retro games in Games was smoothed out using bilinear filtering. It’s a safe default, but you may prefer to see your retro games in all their pixely glory; head over to Games’ preferences and you’ll find the Filter option in the new Video page, letting you to choose between the familliar smooth video output and a new sharp one!

Collection Loading Indicator

So far you had no way to know when Games finished loading the games collection. In 3.24, a small popup will appear while the games list is being loaded, letting you know when all the games are found.

Smooth Collection Alignment

The game thumbnails spread evenly horizontally instead of packing themselves at the beginning of the line, making the games collection look more elegant.

Remembering the Window’s State

Games remembers the size of your window and whether it is maximized or not, and restore the window’s state when you start the application. Not only that, it also remembers whether your games should be displayed in fullscreen!

Improved Error Messages

Should a game fail to run, starting from 3.24 Games displays an error message in the error page explaining the failure in a non-technical way.

Supporting More Games

Famicom Disk System games are listed, and with the right firmware (see later) Games is even capable of running them!

Games is also capable of listing and running standalone Libretro games — games distributed as Libretro cores — provided they ship a correct Libretro core descriptor. Notable examples are 2048, Dinothawr and Mr. Boom.

The Flatpak Version

The Flapak version of Games already shipped Libretro cores allowing you to play Super NES, Super Famicom, Game Boy, Game Boy Color and PlayStation games; Games comes with a few more Libretro cores:

• Beetle NeoPop, allowing you to play Neo Geo Pocket and Neo Geo Pocket Color games;
• Beetle PCE Fast, allowing you to play TurboGrafx-16/PC-Engine and TurboGrafx-CD/CD-ROM² games; and
• Nestopia UE, allowing you to play NES, Famicom and Famicom Disk System games.

If you want to install the latest nightly — and soon the latest stable — Flatpak version of Games, head over to the documentation.

Firmwares

In most of the situations, no external firmware (BIOS) file is required to play retro games, but some Libretro cores may require an external firmware file to do so; these firmwares are described in the .libretro descriptor of the core. Usually, neither the Libretro cores nor Games can ship these firmwares for copyright reasons, so the user have to provide them in order to run these games.

Games 3.24 lets the Libretro cores look for external firmwares in the ~/.config/gnome-games/platforms/PLATFORM/system directory, where PLATFORM is the platform of the game as defined in the .libretro descriptor and in the known platforms of the Libretro core descriptor specification.

Games checks whether the required firmware files with the expected fingerprints are present and will fail to run the game otherwise.

For example, in order to run Famicom Disk System games in Games with the Nestopia UE Libretro core, you will need the ~/.config/gnome-games/platforms/FamicomDiskSystem/system/disksys.rom file with the right fingerprint, and in order to run TurboGrafx-CD and CD-ROM² games with the Beetle PCE Fast Libretro core, you will need the ~/.config/gnome-games/platforms/TurboGrafxCD/system/syscard3.pce file with the right fingerprint.

This is obviously not desirable to rely on such proprietary and globally illegal to distribute firmwares; become a video game preservation hero by writing a free implementation of these!

Various Fixes

In Games 3.24, all of the following bugs are fixed:

• if the configuration move the application menu into the application’s header bar, a menu bar was present in addition to the appmenu button;
• an empty button was sometime present on the error page’s headerbar;
• keyboard shortcuts to make the game fullscreen made the application fullscreen even when the games doesn’t support it;
• keyboard navigation in the games collection was buggy.

Refactoring retro-gtk

retro-gtk is the library allowing Games to handle libretro cores, so it’s one of its most important foundations. Unfortunately, the library’s design has been rushed out in the first versions of Games which resulted in an overly complex library: it was harder to use than it should and making it evolve wasn’t easy either.

A big refactoring of retro-gtk started this cycle: the retro-gobject and retro-gtk libraries were merged into retro-gtk; the Retro and RetroGtk namespaces were merged into Retro; many unused types where removed — they can be added back when they will actually be needed; and some parts of the code like the video and audio outputs have been simplified.

All of these simplifications will allow us to refactor the library even more, for example it would help us decoupling the process running the Libretro cores from the one running the UI, in a similar fashion to what WebKitGTK+ does with web pages; this would help resolving several problems with Libretro core support and would prevent the application from crashing because of a Libretro core.

As a reminder, retro-gtk’s API is still extremely unstable.