Libretro

Écrit par Hugo F

Libretro est l’outil que je vais vous présenter aujourd’hui. Il m’a tapé dans l’œil récemment, malheureusement, je n’ai pas encore pris le temps d’approfondir le sujet donc la présentation ne sera pas technique.

RetroArch 👀

Si vous vous intéressez au domaine de l’émulation, vous avez sans doute déjà entendu parler de RetroArch. C’est une interface qui permet de donner accès à différents émulateurs ou jeux sur plein de plateformes différentes. Là où ça devient intéressant, c’est qu’en regardant d’un peu plus près l’aspect technique de l’outil, on remarque qu’il est basé sur une certaine Libretro.

Libretro 🎮

Forcément, quand j’ai découvert cet outil, j’ai voulu aller voir comment le tout fonctionne et ce que c’est que cette bibliothèque.

Il s’avère que RetroArch est basé sur un concept qu’on retrouve très souvent dans notre domaine de prédilection, le web, c’est l’architecture front-end / back-end. Cette architecture est rendue possible grâce à cette fameuse Libretro qui sert d’api à implémenter d’un côté et à utiliser de l’autre.

On a donc les back-ends appelés Libretro Cores, et les front-ends appelés Libretro Fronts. La Libretro se retrouve donc entre les deux, en fait, c’est un simple fichier header C (.h) qui met à disposition plusieurs structures de données qui pourront être utilisées pour que les deux parties puissent dialoguer entre elles. Ce fichier décrit aussi les fonctions qui devront être implémentées par le Core pour ensuite être appelées par le Front.

À l’origine, cette bibliothèque a été imaginée pour les développeurs d’émulateurs. En effet, grâce à celle-ci, plus besoin de se préoccuper de la gestion de l’affichage ou des entrées utilisateurs, ceux-ci étant directement gérés par le Front. On y gagne en simplicité d’usage et aussi en simplicité de portage. En effet, pour la grande majorité des applications multimédias, c’est à ce niveau-là que se trouve les plus grosses difficultés pour être disponible sur plusieurs plateformes différentes. Ici toutes ces difficultés sont déjà gérées par les Fronts existants.

Technique ⚙️

Alors oui, même si je n’ai pas assez approfondi le sujet pour proposer une implémentation, on va quand même parler un peu technique. En pratique, comment le tout fonctionne ensemble ?

En fait, le concept est très simple. L’idée, c’est donc d’implémenter les différentes fonctions décrites dans le fichier de définition libretro.h, puis compiler tout ça vers une bibliothèque statique ou dynamique qui pourra ensuite être utilisée par le Front que l’on souhaite.

Aujourd’hui malheureusement la documentation sur le développement d’un Core est assez éparse, on peut en retrouver une synthèse ici qui éclaircie certains points, mais dans l’ensemble, elle propose surtout d’aller voir différents projets open-source existants pour voir comment ils fonctionnent.

Globalement, le Front va appeler une série de fonctions pour s’initialiser ; vous allez pouvoir lui enregistrer des callbacks via les pointeurs sur fonctions qu’il appellera ensuite. Via ces callbacks, vous récupèrerez les entrées utilisateur, par exemple, ensuite charge à vous de remplir un buffer (tampon) de pixels qui sera affiché à l’écran par le Front.

Avantages ✅

On en a déjà parlé, mais un des gros intérêts, c’est que lorsqu’on va développer un Core (qui peut être un jeu, un émulateur ou n’importe quelle application multimédia), on n’aura pas besoin de se préoccuper de tout ce qui peut être spécifique aux différentes plateformes pour lesquels on souhaite le rendre disponible. En effet, tout ça est géré par le Front.

Ensuite, l’architecture proposée par la Libretro permet d’avoir accès à certaines fonctionnalités par défaut comme le real-time rewind (rembobinage en temps réel), ou bien le lossless video recording/streaming (enregistrement vidéo de la partie sans perte de qualité).

Désavantages ❌

Oui oui, il y en aussi !

En effet, comme on doit pouvoir compiler notre Core sous la forme d’une bibliothèque, on devra utiliser un langage… compilé ! (Alors avantage ou désavantage, je vous laisse choisir votre camp). De plus, ce langage devra pouvoir s’interfacer de manière assez transparente avec le C puisque l’on va utiliser les types définis dans le Header (C, C++, Zig et Rust sont les candidats qui me viennent tout de suite en tête, mais il y en a probablement d’autres).

Et enfin, mais ça, c’est un point plutôt technique. Pour simplifier les choses, la Libretro est faite pour tourner à une fréquence fixe. En effet, celle-ci étant à l’origine conçu pour les émulateurs, ses concepteurs sont partis du principe que les systèmes émulés sont souvent beaucoup plus anciens que nos machines actuelles, et donc qu’on pourrait la faire tourner sans problème à un taux de rafraîchissement fixe. C’est plutôt une bonne idée vu que ça simplifie pas mal les choses, mais du coup pas question de baser des fonctionnalités sur le temps, tout sera dépendant de la fréquence de rafraîchissement à la place. Ainsi, si votre machine ne supporte pas la fréquence visée, le jeu ou l’émulateur paraîtra plus lent et le gameplay en sera affecté.

Conclusion 👓

Voilà, j’espère vous avoir donné envie de mettre les mains dans le cambouis, que ce soit pour développer votre Core ou même votre Front selon vos affinités, c’est une excellente occasion pour se re-plonger (pour ceux qui n’y ont plus mis les mains depuis longtemps) dans des langages un peu plus bas niveaux que ce qu’on a l’habitude d’utiliser dans le web. J’espère revenir vers vous pour vous présenter une implémentation minimale d’un Core sous peu si je ne change pas de cap vers un autre projet qui m’aura fait de l’œil d’ici là !