Pour ceux qui n'auraient pas compris comment ça fonctionne, je vais essayer d'éclaircir ce point parce que le journal est assez confus. J'ai mis pas mal de temps à bien comprendre comment ça fonctionnait donc je vais en faire profiter tout le monde.
libretro est une API qui tient dans un .h et on a donc deux côtés à l'API : ceux qui vont implémenter l'API (les backends ou cores) et ceux qui vont l'utiliser (les frontends). Le frontend est chargé de fournir au backend via des callbacks tout un tas de service comme les entrées (clavier, souris, etc), le son, l'image, etc. C'est ce qui est fait dans le projet présenté dans ce journal. Le backend lui est l'implémentation générique d'un émulateur ou même d'un jeu. Il va utiliser les services génériques fournis par le frontend sans avoir à s'occuper de la plateforme sur laquelle il tourne. C'est donc le frontend qui assure la portabilité d'une plateforme à une autre. Comme libretro est orienté émulateur à la base, il y a la notion de rom qui est prise en charge nativement dans l'API. Le frontend de référence s'appelle RetroArch (un peu austère).
Les possibilités sont énormes puisqu'au delà des émulateurs, il est également possible de demander au frontend un contexte OpenGL et donc, n'importe quel jeu moderne pourrait être implémenté en utilisant libretro. Je crois savoir que certains moteurs de jeu ont implémenté cette API et les jeux utilisant le moteur sont alors vu comme des roms. Il est également possible d'utiliser libretro pour implémenter des visionneurs de vidéo, il y a un portage de FFMPEG pour utiliser libretro. Bref, c'est une API à surveiller, avec beaucoup de projets très actifs qui tournent autour.
L'API de Retro n'est pas à considérer comme stable pour le moment, mais elle est proche de l'être et ne devrait pas trop changer.
Raté ! Après avoir freiné des quatre fers pour introduire des changements incompatibles, les auteurs de libretro ont décidé de travailler à une version 2 de l'API pour corriger tout un tas de choses bancales. Le travail se fait dans le dépôt git libretro-arb. Parmi les modifications, l'introduction d'un pointeur utilisateur dans toute l'API (ce qui permettra d'éviter les variables globales comme c'est le cas actuellement quand on implémente un core). Il y a encore du travail mais ça prend forme doucement.
# libretro
Posté par rewind (Mastodon) . En réponse au journal Retro 0.1. Évalué à 10.
Pour ceux qui n'auraient pas compris comment ça fonctionne, je vais essayer d'éclaircir ce point parce que le journal est assez confus. J'ai mis pas mal de temps à bien comprendre comment ça fonctionnait donc je vais en faire profiter tout le monde.
libretro est une API qui tient dans un .h et on a donc deux côtés à l'API : ceux qui vont implémenter l'API (les backends ou cores) et ceux qui vont l'utiliser (les frontends). Le frontend est chargé de fournir au backend via des callbacks tout un tas de service comme les entrées (clavier, souris, etc), le son, l'image, etc. C'est ce qui est fait dans le projet présenté dans ce journal. Le backend lui est l'implémentation générique d'un émulateur ou même d'un jeu. Il va utiliser les services génériques fournis par le frontend sans avoir à s'occuper de la plateforme sur laquelle il tourne. C'est donc le frontend qui assure la portabilité d'une plateforme à une autre. Comme libretro est orienté émulateur à la base, il y a la notion de rom qui est prise en charge nativement dans l'API. Le frontend de référence s'appelle RetroArch (un peu austère).
Les possibilités sont énormes puisqu'au delà des émulateurs, il est également possible de demander au frontend un contexte OpenGL et donc, n'importe quel jeu moderne pourrait être implémenté en utilisant libretro. Je crois savoir que certains moteurs de jeu ont implémenté cette API et les jeux utilisant le moteur sont alors vu comme des roms. Il est également possible d'utiliser libretro pour implémenter des visionneurs de vidéo, il y a un portage de FFMPEG pour utiliser libretro. Bref, c'est une API à surveiller, avec beaucoup de projets très actifs qui tournent autour.
Raté ! Après avoir freiné des quatre fers pour introduire des changements incompatibles, les auteurs de libretro ont décidé de travailler à une version 2 de l'API pour corriger tout un tas de choses bancales. Le travail se fait dans le dépôt git libretro-arb. Parmi les modifications, l'introduction d'un pointeur utilisateur dans toute l'API (ce qui permettra d'éviter les variables globales comme c'est le cas actuellement quand on implémente un core). Il y a encore du travail mais ça prend forme doucement.