Accéder au contenu principal

Games 3.30: Features Overload

With a new version of GNOME always comes a new version of Games, and this new version comes packed with new features, bug fixes and developer experience improvements.

Platforms View and Developers View

As part of his GSoC project, Saurabh implemented two new views of your games collection: one filtering games by their developers and another one filtering them by their platforms.

To know more, read Saurabh's Segregating views and Description view articles on his blog.

To implement this he needed to work a lot on the Grilo front, check his explanations in his Adding self registering keys to lua-factory article.

He also started to work on a new page displaying many details about a game like the number of players and a description, it was unfortunately not ready on time for this release but will hopefully land in 3.32.

Gamepad Navigation

You can now navigate the UI with your gamepads! Select your collection view with the shoulder buttons, browse your games with the analog stick or the directional pad, enter the game with your A or cross button, and go back to your game collection with the home button.

This makes Games even more suitable for a gaming console setup like a HTPC or a handheld like the GPD Win, and even more comfortable to use on your desktop or laptop.

libmanette Event Deferring

Notes this is a small technical aparté, if you are only interested about what is new in Games you can skip it.

I implemented a prototype of gamepad navigation during the 3.28 development cycle but it has not been merged before because of a strange bug: when entring a game with the gamepad it was not possible to choose to resume it or not with the gamepad, but when entering it with the pointer or the keyboard it was possible to resume it or not with the gamepad.

Here is what happened:

  • libmanette was looking for input on an the gamepad's event file via g_io_add_watch(), polling the events, parsing the events and sending the corresponding signals,
  • Games was listening to these signals, triggering the game and triggering the resume dialog which was then waiting for a response from the user.
The execution line from the input channel watch source's callback to the dialog waiting for a response was direct: we never finished polling the ongoing events, we never returned the source's callback, the source callback was never added back in the main loop, so we couldn't receive more events from that gamepad!

The solution I choose is to queue a source on the main loop for each gamepad event, so we are sure we finished polling them all before they are treated, and so if an event is blocked it is not going to block other events!

Keyboard-as-Gamepad Mappings

Abhinav implemented a way to set which keyboard keys are mapped to a mock-gamepad used by retro games. Thanks to him you won't have to guess which keys we choose by default: just set yours!

He started working on it during his GSoC 2017 but I have been pretty bad at reviewing it, so it waited on Bugzilla and then GitLab for more than a full development cycle, woops. 😶

Polishing the UI

Alexander brought a few minor corrections to the UI, like fixing the size of the icons used in the media selector button (it was too large) or dropping a box shadow surrounding the collection view.

I took care of migrating the app menu into the window and to add a help button and a shortcuts window. I also made the thumbnails shrink to a smaller size if the widow is narrow, So you can have more than a column or two of games visible in these extreme cases.

Running from Flatpak

Running native games from a flatpaked version of Games finally works thanks to Alexander! That means you can now run desktop games, Steam games and LÖVE games from the version of Games we recommend you to use. Unfortunately Games when flatpaked still can't list desktop games from your system, but it can list the ones from your home like your GOG games so you can run these.

New Platforms

Alexander implemented support for the Flathub version of Steam: its games can now be listed and ran alongside the ones from the native installation! Also, Steam games using the new Proton Windows compatibility layer work out of the box.

He also worked a lot on adding Nintendo DS and Virtual Boy support as well as making sure Libretro cores for these new platforms work well in Games. Dont expect special features like making one screen of the Nintendo DS fullscreen or selecting the anaglyph mode of the Virtual boy yet, but at least the games are playable and you can use your mouse pointer to interact with the Nintendo DS touch screen!

On my side I found a well working free software Libretro core supporting Game Gear and Master System games, which allows you to finally play games for these platforms.

Tests, Options and CI

In a previous article I told you about how having tests and CI would allow us to have more feature. Well, we now have a new feature thanks to that. 😁

We now run reftests on many Libretro cores we ship, we are not testing everything we would like to yet but it's already way better than not tests at all! As part of our reftests, we also check the options that the Libretro cores offer are as expected.

Options are a way for a Libretro core to offer a custom (and usually domain-specific) API, an option (or variable as it is called in Libretro) being a key which can take only one value from a specific set of values. Given that options are "runtime" APIs and given that we don't control the cores offering them, we couldn't trust them to be stable and hence we couldn't use them.

Thanks to the reftests and the CI, we can be warned of any change of these runtime APIs, so we can react to their changes, so them not being reliable isn't a problem anymore, so we can use them! I implemented options accessors in retro-gtk and Alexander used them in Games to set a core's options at boot time. Distributors can change these options easly as they are .options keyfiles installed in /usr/share/gnome-games/options.

This combination of tests and CI directly led to new features as we are now able to ask the Nintendo DS Libretro core DeSmuME to use the pointer instead of an emulated mouse, making is usable and shipable with our stable Flatpak!

A big thanks to Jordan Petridis for helping with the GitLab CI for Games and retro-gtk! 😄

Meson

Thanks to Alexander, Games now uses Meson instead of the Autotools, making it simpler to maintain and faster to build. My coffee breaks are ruined!

Lesser retro-gtk Improvements

Aside the aforementioned focus on testing, enabling access to a core's options, enabling configuration of the core view's mock-gamepad and the various bug fixes, retro-gtk received some smaller but notable improvements: retro-gtk now handles the RETRO_ENVIRONMENT_GET_LANGUAGE and RETRO_ENVIRONMENT_SET_GEOMETRY Libretro environment commands, allowing the cores respectively to know the current language and to notify changes to their video output's geometry.

Leaks fixes

Some reference leaks in retro-gtk and Games were caused by dependency cycles between a core and its view, preventing them to be freed. The links are now unset before releasing the references to the objects. Similarly, if a main loop was dropped while running then a reference to it was dropped and this is now fixed.

Thank You

I would like to give a huge thank you to the many contributors to this version:

  • Mathieu Bridon for keeping an eye on our Flatpak builds and for helping fixing them for ARM,
  • Jordan Petridis for helping a lot with our CI infrastructure,
  • Saurabh Singh for doing great on his GSoC project,
  • Abhinav Singh for mentoring Saurabh and for his many contributions,
  • and Alexander Mikhaylenko for basically taking over my role as a maintainer during this whole development cycle, ensuring the application was in a constant good shape, fixing bugs tiny or big, reviewing merge requests… the list is too long!

Stepping Down

I have been working on Games, its companion libraries and their prototypes since some time in 2013, and Laurent Pointecouteau and I were discussing and designing the application a year prior to that. It has been many fun years but I am now a bit tired and need to move on to other projects, so as Alexander is stepping up as a new maintainer of the project I am stepping down: I am no longer maintaining Games.

Abhinav and Alexander have proven they can make the project shine better than I can, so I am sure they are going to do great things with it! Anyway, I am not disappearing as I am still maintaining the two libraries that spun out of Games: retro-gtk and libmanette.

Commentaires

  1. I will recommend your website to everyone. You have a very good gloss. Write more high-quality articles. I support you.
    바카라사이트

    RépondreSupprimer
  2. Casino in the city of St. Louis | Dr.MD
    The 평택 출장마사지 city's Casino 삼척 출장샵 is on the 안산 출장마사지 edge of things to come in St. Louis, and 광명 출장마사지 it will also be where you'll find some of the best slots, table games, 스포츠 토토 사이트 and

    RépondreSupprimer

Enregistrer un commentaire

Posts les plus consultés de ce blog

GTK+ Apps on Phones

As some of you may already know, I recently joined Purism to help developing GTK+ apps for the upcoming Librem 5 phone . Purism and GNOME share a lot of ideas and values, so the GNOME HIG and GNOME apps are what we will focus on primarily: we will do all we can to not fork nor to reinvent the wheel but to help allowing existing GTK+ applications to work on phones. How Fit are Existing GTK+ Apps? Phones are very different from laptops and even tablets: their screen is very small and their main input method is a single thumb on a touchscreen. Luckily, many GNOME applications are touch-friendly and are fit for small screens. Many applications present you a tree of information you can browse and I see two main layouts used by for GNOME applications to let you navigate it. A first kind of layout is found in applications like Documents, I'll call it stack UI : it uses all the available space to display the collection of information sources (in that case, documents), clicking a

libhandy 0.0.10

libhandy 0.0.10 just got released, and it comes with a few new adaptive widgets for your GTK app. You can get this new version here . The View Switcher GNOME applications typically use a GtkStackSwitcher to switch between their views. This design works fine on a desktop, but not so well on really narrow devices like mobile phones, so Tobias Bernard designed a more modern and adaptive replacement — now available in libhandy as the HdyViewSwitcher . In many ways, the HdyViewSwitcher functions very similarly to a GtkStackSwitcher : you assign it a GtkStack containing your application's pages, and it will display a row of side-by-side, homogeneously-sized buttons, each representing a page. It differs in that it can display both the title and the icon of your pages, and that the layout of the buttons automatically adapts to a narrower version, depending on the available width. We have also added a view switcher bar, designed to be used at he bottom of the window: HdyView

Boxes' hardening sprint: two weeks in

Finishing my 4th year of CS studies I spent the last two weeks working hard on the report and the presentation of the project my colleagues and I worked on all the semester long: creating the Stibbons multi-agent system programming language and development environment. I am very proud of what we accomplished and I’ll probably present it to you in the upcoming weeks. =) Planning the port of Boxes' installation wizard to GtkAssistant All this work unfortunately let me little time to work on Boxes, but I nonetheless took some time to look at how its installation wizard is implemented and planned how to port it to GtkAssistant. Boxes' installation wizard Currently, the wizard is ordered that way: WizardWindow WizardToolbar: the toolbar containing the navigation buttons Wizard: the stack of pages Most of the wizard’s intelligence seems to lie in Wizard and its pages, I’ll have to dig further into Boxes' code in order to fully understand how th