mercredi 3 décembre 2014

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 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 (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:

Retro version 0.1 RC can be found here:


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.


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.


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


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 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:

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:



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:


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.

vendredi 25 juillet 2014

GSoC 2014 report 2

What an eventful month! Lots of code have been read, produced, reviewed and refused, several code designs have been proposed, but as everything was work in progress, I didn't fell it was exciting enough to blog about it at that time.

But here it is! The blog post that explains it all.

Multiple displays per machine

I mostly spent the third week trying to have multiple displays for a SPICE machine, which implied reading a lot virt-manager's code and some of spice-gtk's code.

I achieved to get the maximum number of displays available for a machine and, with Christophe Fergeau's help, to get some good results: we were able to have multiple displays each in its own window, but we were not able to open them up from Boxes yet (the session had to have them already opened).

Multiples machines

Jakub Steiner proposed a design focusing mainly on having multiple machines running side by side in different windows:
It settled what idea would be implemented, and a new bug report have been created to reflect that.

The window singleton

The main problem that have been encountered is that Boxes uses a static window instance that is accessed directly by a huge number of classes.

It is very problematic, as if you summon a second instance of this window's class, any action in the second window will have its reactions produced not on itself but on the static window instance, which is conceivably problematic who you want to implement a multi window feature.

Zeeshan proposed not to change the app's design to allow having multiple windows but to have multiple one window instances communicating via D-Bus.
It have its pros, as it would make Boxes more resistant to crashes, to slowdowns and to be be naturally more parallelized, but the design would most certainly have ended up being a gigantic mishmash.

This idea have been abandoned in favor of a code refactoring.

Getting rid of the window singleton

In Boxes' design, the app's controller is scattered over all the classes.
In my opinion it is problematic:
  • you can't use a class in any different way without changing the class' code
  • changing a simple behaviour may require modifying lots of classes
  • you can't have a good overview of the application's behaviour  which may confuse newcomers
I spent several weeks refactoring the app, trying to move the controller closer to the root of the composition tree by using signals to make the leaf classes dumber but more modular.
It worked preety well and Lasse, which reviewed my patches, and I  were preety proud of the newly produced code and design.

At the time when the code started to take shape, unfortunately, Zeeshan had harware failures which made him not able to check out our work.
Because of that, we knew quite lately that he preferred the code to stay as close as possible from the actual design, changing as less code as possible in the process.
It is pretty wise, as he haves to maintain the application, and so I started over with these considerations.

So far the last set of refactoring patches are well received, all they need is a little bit of polish to fully shine!

What's next

It's now the time of GUADEC, here I'll be able to chat with my colleagues and to meet other gnomes!
If everything go as planned, the patches will be merged during this period, and I'll be able to actually implement the multi window feature after that!

jeudi 24 juillet 2014

GUADEC 2014, here I am


I just arrived in Strasbourg where the 2014 edition of the GUADEC will take place.

The city is beautiful and have an interesting architecture full of half-timbered buildings and lush vegetation, which contrasts a lot with my home town of Montpellier.

The GUADEC and my participation to the GSoC for Boxes

During the last weeks, I worked a lot with Christophe Fergeau, Zeeshan Ali and Lasse Schuirmann, this GUADEC will be a great occasion to meet them in person and to enhance our collaboration on Boxes.
The GUADEC will also be a great occasion to work on Boxes by chatting about (and solving?) pending patches and to chat about Boxes' future during a BoF.

I'll also attend Lasse's proposed BoF on pointerless navigation (i.e. keybaord navigation), completing it with my interest on forsaken input devices such as gamepads. Don't hesitate to come and chat with us!

Have a nice trip and see you in Strasbourg!

mercredi 18 juin 2014

GSoC 2014 report 1

Week #1

I started my work on Boxes on June's 2nd. This first week served as a transition from my examinaton period to the GSoC.

I had some unfinished work from my application period: two bugs to solve.

The first one was #726252 - Refactor topbar's children into separate classes/modules

The patches were pretty much finished but they were not perfect, all they required was some love.
It took me time to transition my mind from the student mindset to a more engineering one, but hopefully, the patches were accepted at the end of the week.

The second one was #692383 - Allow editing of box name in the tite

Just as for the first bug, I had patches ready but not perfect, and they were dependent on work done for the first bug.
As it took me time to correct the patches for the first bug, I let this one aside.

My project is to add multi-monitor support to Boxes, so I also took time to read Boxes' code, especially the App, AppWindow, Display and Machine classes as they seem to be the one I'll hack the most, and to think about how I can implement multi-monitor support on top of this.

Week #2

I updated my patches for bug #692383 but let them aside to focus on my project.

While discussing the project with several persons like Zeeshan Ali, Christophe Fergeau, Jakub Steiner and Lasse Schuirmann, a problem came up: everybody have a different idea of what "adding multi-monitor support" means.

The main ideas where:
  • multiple monitors for one machine
  • multiple monitors for one machine only on fullscreen
  • multiple machines with one monitor
  • multiple machines with multiple monitors 
What will finaly be done will be decided by the maintainers and the designers (mainly Zeeshan Ali and Jakub Steiner).

I continued to read Boxes' code and understand its design.

Currently the Display listen to the App's state and set the state in response (via a static instance).
The App handles the window's state, wich is not problematic since they both are singleton.

This design works well for a single machine and a single window but is too static for multiple ones, so a deep rewrite may be needed and will take more time.

What needs to be done will be done but don't expect results soon.

dimanche 27 avril 2014

GSOC 2014, here I am!

It's all about taking and giving back

Some years ago, I discovered the principles of free software while becoming a happy GNU/Linux user (Ubuntu at this time). These principles have changed my vision of the world: I wanted to be part of this movement, I wanted to give back to the projects that gave me so much.

This is how I stopped being a laborer and became a computer science student, and I feel that I have enough knowledge to give something back.

The Google Summer of Code

I am very happy to say that I have been accepted to the 2014 edition of the Google Summer of Code!
Applying to this GSOC have been a stressful but already very enriching experience, the coding session haven't started yet but I already learned a lot!
I am sure it will be a great experience and that I will learn a lot on software engineering.

I decided to apply for GNOME because I simply love this desktop environment, from the experience I have using it to its software libraries.

This summer, my tutor will be Christophe Fergeau as I will hack on GNOME Boxes to make it offer to attach more than one monitor when creating a VM.

It certainly will be an interesting summer.

jeudi 24 avril 2014

Welcome to my blog.

I am Adrien Plazas, actually studying computer science in Montpellier, France.

Here I'll write about my studies, the GNOME desktop environment and video game preservation.

I hope you'll enjoy it! =)