I wanted to start this blog post with “It’s that time of year again”, but looks like Michael beat me to it. So, let’s take a look at some of the changes in GNOME Games 3.38:
The library Games uses to implement Libretro frontend, retro-gtk, has been overhauled this cycle. I’ve already covered the major changes in previous blog post, but to recap:
- Cores now run in a separate process. This provides a better isolation: a crashing core will display an error screen instead of crashing the whole app. This can also improve performance in case the window takes a long time to redraw, for example with fractional scaling.
- Libretro cores that require OpenGL should now work correctly.
- The core timing should now be more accurate.
- Fast-forwarding should actually work, although we don’t make use of it in Games at the moment.
Finally, retro-gtk now has proper docs, published here to go along with the stable API.
Nintendo 64 support
This was on the radar for a while, but wasn’t possible because all available Nintendo 64 cores use hardware acceleration. Now that retro-gtk supports OpenGL, we can ship ParaLLEl N64 core, and it just works. There’s even a menu to switch between Controller Pak and Rumble Pak.
Unfortunately, retro-gtk still doesn’t support Vulkan rendering, so we can’t enable the fast and accurate ParaLLEl RDP renderer yet.
Neville Antony has been working on implementing collections as part of his GSoC project. So far we have favorites, recently played games and user-created collections.
You can read more about the project in Neville’s blog
In my previous blog post I already mentioned some improvements to the app startup time, but a noticeable progress was made since then. Newly added aggressive caching allows the app to show the collection almost instantly after the first run, and then it can scan and update the collection in background.
Having a complete cache of the collection also allowed to easily implement a fast search provider, so the collection can now be searched directly from GNOME Shell search.
Nintendo DS screen gap
Nintendo DS has two screens. Most games use one of the screens to display the game itself, and the other one for status or map. However, some games use both screens and rely on the fact they are arranged vertically with a gap between them.
If the two screens are shown immediately adjacent to each other, these games look confusing, so in 3.38 a screen gap will be automatically added when using vertical mode.
The size of the screen gap is optimized for a few known games, such as Contra 4, Sonic Colors or Yoshi’s Island DS, other games use a generic value of 80 pixels.
If you know another game that needs to use a specific gap size, please mention it in the comments or open an issue on GitLab.
Gamepad hot plugging in Flatpak
Previously, a major limitation of Flatpak version was that gamepads had to be plugged in before starting the app. Thanks to a change in libmanette 0.2.4, this has been fixed and gamepads can be connected or disconnected at any time now.
Technically, this isn’t a 3.38 addition, and in fact the 3.36.1 build on Flathub already supports it. Nevertheless, it was done since my last blog post and so here we are. :)
Game covers now look prettier thanks to Neville: they are now rounded and have a blurred version of the cover as background.
The preferences window has been overhauled to be more similar to the libhandy preferences; unfortunately we can’t use
HdyPreferencesWindow yet because of some missing functionality.
When testing or re-mapping a controller, analog stick indicators now show the stick’s precise position instead of just highlighting one of the edges.
Veerasamy Sevagen implemented an empty state screen for the collection search.
Swipe gestures to go back are now supported throughout the app. The only place that lacks the gesture now is exiting from a running game, because the game may require pointer input, and having a swipe there may cause conflicts.
As always, the latest version of the app is available on Flathub.