Games received a non-negligible amount of changes that you will find in 3.26. These changes can be big as much small, and more are to come!
Building the Games Collection
Games presents your games collection and if everything goes as expected, it does so without the need of any input from you. From an implementation point of view it sounds simple to do, just ask Tracker “Hey, gimme all the games” and it’s done. If only it was that simple! 😃 The system has no idea which files represent games and which doesn’t, but it can associate a MIME type to each file thanks to shared-mime-info. shared-mime-info already had a few video game related MIME types and we added a lot more such as application/x-genesis-rom.
That done, we can query Tracker for files having specific MIME types that we know to often represent video game files. Unfortunately, each of these files doesn’t necessarily represent a game and a game isn’t necessarily represented by a single file: some files may be invalid and hence represent no games and some games may require multiple files, a typical case of multi-resources game is a multi-disc PlayStation games. Depending on the files and the kind of games they may represent, we may have to reject them, parse them, store them and gather them into a single game.
We also have to be particularly careful when games are represented by files with a generic MIME type such as application/zip — i.e. MAME games — or application/x-cue as most of the search results for these will probably be invalid.
To these are added more exotic game sources such a Steam games or so called desktop games — the games from your applications menu and represented by .desktop files. These add another layer of complexity as gathering the resources representing these games has to be done in a slightly different way than for your typical game files. For example, Steam is a video game store and launcher giving a unique ID it each of its games: a number starting from 10 with Counter Strike.
How Games 3.24 Builds your Collection
Games 3.24 handles no game types directly, it relies on plugins for that. Plugins are providing a GameSource, these game sources are iterable and produce Game objects in the way they please. Most of them find the game resources by querying Tracker for URIs of files of specific MIME types and by parsing these files to build the Game objects; others handle the resulting URIs in a more complex way to support multi-disc games, while others are querying the URIs of the .desktop files of the registered applications or are parsing the Steam library.
This works well but it led to some code duplication and adding support for a simple type was done by copying some other plugin and tweaking one or two strings. Copying the plugin is fastidious for an actually very small change. Some refactoring is needed.
How Games 3.26 Will Do It
For Games 3.26 the way the games collection is built has been completely refactored, GameSource’s role has been split into several parts: UriSource objects output URIs from whichever way they want, UriGameFactory objects take URIs and output games in an asynchronous way — giving them URIs may result or not in the creation of a Game object or in the improvement of an existing one — and GameCollection act as a glue in-between them. A UriGameFactory declares the URI schemes it can handle and the MIME types of the files it can handle — the file URI scheme is implicit —, allowing GameCollection to send URIs only to the relevant UriGameFactory objects.
Plugins don’t declare GameSource objects anymore but instead UriSource and UriGameFactory ones. An interesting new change is that plugins now also declare MIME types of files to search, avoiding the need to declare a UriSource for a very common search case: they all will be given to a specific UriSource which will perform the corresponding Tracker queries; this also solves the problem of searching multiple times for the same MIME type in different plugins. It doesn’t make sense to declared MIME types to search that are not handled by an UriGameFactory, but it can make sense not to search for all the handled MIME types, more on that later.
Many very simple types have been reduced to the RetroSimpleType type: a simple declaration of the MIME type corresponding to the simple game type, whether this game type should be searched and the name of the corresponding gaming platform.
{ "application/x-gameboy-rom", true, "GameBoy", "game-boy" }
Example of a SimpleType declaration.
All the supported game types were successfully ported to this mechanism and it is expected to support any future game type.
Adding More Games
Thanks to all these changes, it is now possible to give any URI to GameCollection and it will handle it properly, which means we can now have external game URI sources and properly use their results! This allows us to handle opening files with Games: the users can double click on their game file and if all goes well, Games will automatically run them! Another source of games that has been added is a “Add game files” button on the games collection view: the user can select game files to be added to the collection, given they are valid.
Opening a game file with Games.
All the game resources you added to Games are saved and will be loaded when starting the application again: if for some reason searching game files doesn’t work, you will still be able to use Games. This also allows you to manually add games that can be handled by Games but which it doesn’t know how to search for right now, either because of the lack of a clear MIME type representing the game type or for the lack of ability to know if a URI represents a game or something else.
Games Support
Games 3.26 will list Atari Lynx, MS-DOS, WonderSwan and WonderSwan Color games and, given you have the corresponding Libretro core installed properly, you will be able to run them too. Unfortunately as it can’t make a difference between regular MS-DOS executables and MS-DOS games, Games can’t automatically look for your MS-DOS games and you will have to manually add them to your collection. Games doesn’t support the mouse for Libretro cores right now, so you won’t be able to run MD-DOS games requiring one right now.
The detection of PlayStation discs has been reworked and the disc images are now parsed properly, which should greatly expand the number of detected discs and games. If you still have PlayStation games not showing up in your games collection or if games used to show up but don’t anymore, please file a bug!
Games was displaying desktop games that were asking not to be displayed or to be hidden, this is now fixed.
Gamepad Support
The gamepad handling has been ported from Vala to C. This change is a solution to the problem of our usage of the Vala preprocessor which was poorly handled by the Autotools, resulting in broken tarballs. Another solution would have been to not use make dist.
It has been refactored a bit to make Gamepad objects emit events very similar to GdkEvent, using Linux event codes instead of custom gamepad event types. This makes the gamepad support simpler and more flexible by improving the definition of events and by avoiding a layer of conversion for what is our only gamepad backend anyway.
UI Improvements
The GtkDialog objects used when resuming or quitting a game are replaced by GtkMessageDialog ones, as this type is more fitted to the messages they convey.
The look of the media selector has been improved, using checkmarks to denote the currently used media.
MediaSelector in 3.24…
…and what will become 3.26
The games collection now use theme relative colors instead of ones set by the application, making it work better with any theme or with the light theme variant.
A useless sorting invalidation in CollectionIconView has been dropped, making the games collection load a bit faster.
Thanks to changes in retro-gtk, the logging of messages from Libretro cores has been improved: their log domain is now the core’s name instead of Games’ one, which should greatly help debugging.
Evolution of retro-gtk
retro-gtk is an important dependency of Games as it allows it to use Libretro cores. In what will become retro-gtk 0.12 a demo application has been added, it should help to develop and test retro-gtk without relying on Games.
So far, to load the games to use with a Core object, Core.load_game() or Core.prepare() had to be called just after Core.init() and the complex disk interface may had to be used if the Libretro core required it. Now the users of retro-gtk just have to use Core.set_medias() before calling Core.init() if any game has to be passed to the core, the games will then be loaded during the call to Core.init() and the user doesn’t have to take care of the disk interface. If multiple medias were passed to the Core, they can be changed with a call to Core.set_current_media().
As previously said, logging has been improved.
The CoreView widget has been added, it can handle the video output and some inputs — like keyboard and mouse inputs — for the core. It is still in an early stage and its design is expected to evolve, its goal is to be the simplest way possible to handle a Core. It is used by the demo application.
retro-gtk is slowly being ported to C and its API is being simplified in the hope to make the library as simple to use and as stable as possible.
Other Ongoing Works
Other works are ongoing too! Abhinav is working on allowing you to configure your gamepads in case Games doesn’t support them yet and Yasitha is working on supporting the multiple features of the Nintendo DS so you can run its games perfectly!