Accéder au contenu principal

Retro 0.1 RC

During last GUADEC, I had a chance to briefly present my project of having a powerful yet simple video game manager and player for GNOME. To make it a reality, a lot of work was needed on the backend side.

This article present the release of the first version of this backend, in its release candidate form.

Libretro

Libretro is a C/C++ API used mainly by retro video game console emulators and game engines. Writing an emulator and writing a GUI application require very different skills, using Libretro allows to isolate the backends (often called modules or cores) implementing the API from the frontends using the API to manipulate them, easying the port of the emulators or engines and offering a multiplicity of cores to choose from to application developers.

The main frontend of Libretro is RetroArch and it have been ported across multiple systems.

Retro

Retro (or retro-gobject) is a GObject based Libretro wrapping library written in Vala. It eases the creation of Libretro frontends by using OOP and automatic memory management (thanks to Vala and GObject); it allows the creation of Libretro frontends in other languages than C/C++ via GObject Introspection; and it allows to have multiple Libretro cores loaded at the  same time, through the use of a global variable to store the calling core's identity, and through file copy to avoid global variable collision in already used modules). Retro's API is not to be considered stable yet, but it is very close to be and shouldn't change much. Some objects are marked with a temporary internal visibility until they are tested and polished and can be part of the public API.

But most importantly, what Retro isn't is a fork of Libretro. All it does is to wrap it in a nice object-oriented layer and it is fully compatible with modules implementing Libretro.

Retro's git repository can be found here: https://github.com/Kekun/retro-gobject

Retro version 0.1 RC can be found here: https://github.com/Kekun/retro-gobject/releases/tag/v0.1-rc

Core

Core is the most important class of Retro. It represents the functionalities associated to a Libretro module and allow you to run it. A Core allows you to get information about its module, to set interfaces to handle the module's callbacks, and most importantly, to run it.

Video

The Video interface is use by a Core to ask the frontend to render video and to set details about how the video must be rendered, such as the source video's pixel format.

Audio

The Audio interface is used by a Core to ask the frontend to play audio.

Input

The Input interface is used by a Core to ask the frontend about the state of the input devices, such as gamepads, keyboards and mice.

Other interfaces

Lots of other interfaces can be set by the frontend or by the Core to communicate. Some examples are the Log interface, to let the Core write log messages, to the standard output or a file by example; the DiskControl interface, to let the frontend control a Core's virtual disk drive (for example, to swap disks on a CD based game console emulator); or the Variables interface to allow the frontend to know about the Core's special options and to set them.

RetroGtk

RetroGtk is a library written in Vala which links Retro, in order to run Libretro modules, and Gtk. It offers Gtk widgets implementing various Retro interfaces, allowing to easily display a Core's video, to forward keyboard and mouse events to it, and to mimick gamepads with a keyboard.

RetroGtk also contains non-Gtk related objects, like loops to help running a Core, an interface to forward a Core's log to a FileStream, and an interface to help manage a Core's variables.

You can use Clutter and ClutterGtk or Cairo to render the video, and I hope that the inclusion of a Gl widget in Gtk+ 3.16 will allow to get rid the dependency on Clutter. It currently can also play a Core's audio via PulseAudio, but it may be moved to some "RetroPa" library. Proper joystick support is still to come, certainly in a separate library (RetroJs?). RetroGtk's git repository can be found here: https://github.com/Kekun/retro-gtk

Libretro module collection

Being able to run, control and render Libretro implementations is of no use if you have no such implementation to run, control and render. To help solving this, I started collecting GPL compatible implementation in a git repository, adding a makefile to ease the compiling and installing them. It is still in its infancy but it already helped me quite a lot.

The machines currently emulated by the collection are:

  • Nintendo Entertainment System
  • Super Nintendo Entertainment System
  • Game Boy Advance
  • Saturn 
  • PC Engine
  • DOS

PlayStation support is to come, but an annoying bug in the emulator have to be solved first.

You can find this collection here: https://github.com/Kekun/libretro-free

Applications

Demo

To test all of this, I wrote a demo application, which uses Retro, RetroGtk and the module collection to run games. It allows you to open several game files (see the modules in the collection to know what can be run), to set the Core's options, and it supports inputs such as the keyboard, the mouse, and can use the keyboard as a virtual gamepad. You can set the virtual gamepad's configuration via a button.

Theme Park running in DOSBox
Virtual gamepad configuration when running PC Genjin 2 in Mednafen
Nestopia's options
bSNES running Yoshi's Island, showing the "ungrab the pointer" message

Here is the demo's git repository: https://github.com/Kekun/retro-gtk-demo

GNOME Games

The ultimate goal of this project is to write a video game manager and player for GNOME, with a user interface similar to GNOME Music or GNOME Video. This project is similar to OpenEmu for MacOS X systems.

Commentaires

  1. Great news, congrats! Good to see libretro getting a bit of gtk love, this will surely help me run my favourite games better integrated than I currently do (DosBox - and most emulators - looks a bit alien by default)

    RépondreSupprimer
  2. The libraries just need a little bit of gtk-doc love :)

    RépondreSupprimer
    Réponses
    1. I'll try to add it for the final 0.1 release! Too bad I can't manage to get Valadoc working.

      Supprimer
  3. Nice, maybe you should think about porting these project to autotools, so, for example, they can be easily compiled/run in jhbuild (Ive just added them to gnome-world moduleset but they fail to install as they try to install in a system directory)

    RépondreSupprimer
    Réponses
    1. I spent some time to port the building system from my makefiles to the autotools (via Anjuta, as I don't know how to use the autotools _yet_), here is the result: https://github.com/Kekun/retro-gobject/tree/automake
      I managed to make the autotools build and install most of what is needed, but it still lacks a way to generate documentation (I would love to have C documentation via Gtk-doc and Vala documentation via Valadoc).

      I'm not willing to merge this branch to master and publish the final 0.1 version until I can generate some form of documentation, maybe you could help me to achieve it?

      Supprimer
  4. Réponses
    1. Thanks, at least you now know part of why I didn't work more on the Python app. ;)

      Supprimer

Enregistrer un commentaire

Posts les plus consultés de ce blog

Librem 5 ❤️ GNOME 3.32

I am glad to announce that the tooling I am working on since the beginning of the year is ready to be used!Thanks to new features introduced into libhandy 0.0.3 and 0.0.4 and thanks to a few fixes to Adwaita in GTK+ 3.24.1, you can make GTK+ 3 apps adaptive to work both on the desktop and on the upcoming GNOME-based Librem 5 phone.We are early in the GNOME 3.32 release schedule and the Librem 5 will be released a bit after it, so if you want your apps to work on the Librem 5, now is the best time: use libhandy 0.0.4 and up, use GTK+ 3.24.1 and up and target GNOME 3.32! A few apps like Fractal, Podcasts, Calls and Chatty are already using libhandy's adaptive capabilities, and other apps are working on their adaptive transition like Contacts, Games, Geary and Settings (all are works in progress). libhandy is available in Debian Unstable and Arch's AUR repository, and I wish it would be in Fedora already to let GNOME Settings' CI pass.For the moment, libhandy is a GTK+ 3 widg…

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 an element from t…

One Widget to Adapt Them All and to The Librem 5 Port Them

In my previous article I shared my plans to help porting existing GTK+ applications to Purism's upcoming Librem 5 phone without having to fork them. This article will present the GTK+ widget I developed for Purism to make this happen.For more information on what Purism is working on for the Librem 5, please check Nicole Faerber's latest article.C'est pas sorcierThe underlying idea is to allow applications to dynamically switch between the two main GNOME application layouts: a row of panels — each panel being the view of an element from the previous one — and a stack of panels. The goal isn't to changes applications using the stack paradigm but the ones using the row one, allowing them to reach smaller sizes and to be usable on constrained sizes while keeping their initial paradigm and design when the screen space is sufficient. The development cost to port the applications to this adaptive design should be as low as possible.To achieve that, I wrote a GTK+ widget which…