Module de plugins

[ardemii]

Bonjour, une fonctionnalité qui pourrait rendre la SFML encore plus attrayante serait d'implémenter un système de plugins.

La SFML est une bibliothèque de création de jeu bas niveau mais qui gère les fenêtres, les images et les sons en haut niveau pour aider les codeurs à se concentrer sur le contenu lui même.
Il serait logique de créer un module pour gérer les plugins ce qui serait utile pour les gros projets
Il serait composé d'un classe de gestionnaire et qui gérerait les plugins, que l'on chargerait à la manière des images via un .loadFromFile() .
Chaque plugin serait un exécutable qui contiendrait une fonction qui renverrait un héritier d'une classe sf::Plugins générique.
Il gérerait les plugins avec les API dlopen pour Unix et Win32 pour windows permettant l'abstraction de ce fouillis.

sf::Plugin contiendrait un numéro de version de SFML et un numéro de version du projet projet pour éviter de charger des plugins trop anciens.

[ardemii]

Exemple :

// class abstraite
class Plugin
{
     public:
         // constructeur et destructeur personalisable
         Plugin();
         virtual ~Plugin();

        // fonction du plguin qui doit être personnalisé
        virtual T exec() = 0;

     protected:
        // numéro de version de la SFML utilisé
        long sfmlversion;
        // numéro de version du projet avec lequel le plugins est compatible
        long projectversion;
        // numéro de version de l'auteur
        long plugin version;
        // pseudo des auteurs
        string auteurs;

};

[ardemii]

Gestionnaire:

#include <SFML/Plugins.hpp>
#include <vector>
#incude <string>

class PluginManager
{
    public:

      PluginManager();
      ~PluginManager();

      // on récupère un plugin
      sf::Plugin getByName(std::String);

      // On charge un plugin en vérifiant les numéros de versions
      bool loadPluginFromDisk(std::String, long projectversion);
      // On décharge
      bool unloadPlugin(std::String);

    protected:
        std::vector<sf::Plugin> plugins;

};

[ardemii]

Exemple de plugin sous Unix avec l'api dlopen =

#include <SFML/Plugins.hpp>
#include iostream

class TestCarre : sf::Plugin
{
   virtual int exec(int a) const
   {
       return a*a
   }

};

extern "C" sf::Plugin* create() {
      return new TestCarre;
}

extern "C" void destroy(sf::Plugin* p)
{
       delete p;
}
 

Compilation :

g++ -fPIC -c Test.cpp
g++ -fPIC -o Test.so -shared - Test.o

.so => .dynlib sous mac

[Laurent]

Quel rapport avec SFML (qui est, je le rappelle, une bibliothèque multimedia) ? Et puis ce genre d'abstraction est disponible un peu partout, je pense que tu peux facilement trouver un code ou une bibliothèque dédiée sans que j'en réinvente une nouvelle.

[ardemii]

Quel rapport avec SFML (qui est, je le rappelle, une bibliothèque multimedia) ?

La SFML est une bibliothèque permettant de créer diverses applications en particulier des jeux vidéo.
Ses avantages son sa conception Orienté Objet mais aussi la gestion des modules qui permet de se concentrer sur uniquement le fond, le jeu en lui même.

On a un accès bas niveau au jeu se  qui nous permet de quasiment tous faire  tout en ayant un accès haut niveau aux
"Briques de bases".
 Cela permet de coder rapidement et proprement.

Un système de plugins permettrait de ne pas avoir à recréer à chaque fois les mêmes classes qui ne  serviront pas au jeu en lui même tout en maximisant la compatibilité avec l'API SFML.

Cela évite d'utiliser 40  libs différentes toute en permettent une meilleur intégration : Les plugins pour auraient plus facilement accès aux différentes classes telles que sf::Windows ou sf::Sprite.

Et puis ce genre d'abstraction est disponible un peu partout, je pense que tu peux facilement trouver un code ou une bibliothèque dédiée sans que j'en réinvente une nouvelle.

Ce genre d'abstraction est quand même plutôt rare et le code nécessaire est extrêmement petit par rapport aux gains de temps que cela ferait aux développeurs tout en augmentant l'attrait que peut avoir la SFML pour les dev venant d'autre lib comme la SDL.

[Ceylo]

J'ai pas vraiment compris l'intérêt par rapport à des bibliothèques ?

[Laurent]

Un système de plugins permettrait de ne pas avoir à recréer à chaque fois les mêmes classes qui ne  serviront pas au jeu en lui même tout en maximisant la compatibilité avec l'API SFML.

Il y a plein de choses dont un jeu a besoin, ce qui ne signifie pas que je doive systématiquement les mettre dans SFML
Si je codais un moteur de jeu, ok, mais là ça reste très bas niveau, je donne accès au fenêtrage/graphisme/son/réseau, point.

D'autant plus qu'une gestion de plugin ça peut être très personnel. A la limite, une abstraction pour charger une bibliothèque partagée et récupérer des fonctions dedans, ça peut être utile ; mais ensuite fournir une classe de base figée, avec des fonctions et des membres choisis arbitrairement, je ne vois pas l'intérêt.

[ardemii]

Il y a plein de choses dont un jeu a besoin, ce qui ne signifie pas que je doive systématiquement les mettre dans SFML
Si je codais un moteur de jeu, ok, mais là ça reste très bas niveau, je donne accès au fenêtrage/graphisme/son/réseau, point.

D'autant plus qu'une gestion de plugin ça peut être très personnel. A la limite, une abstraction pour charger une bibliothèque partagée et récupérer des fonctions dedans, ça peut être utile ; mais ensuite fournir une classe de base figée, avec des fonctions et des membres choisis arbitrairement, je ne vois pas l'intérêt.

Oui tu as raison une abstraction pour charger des bibliothèques partagées suffirait amplement.