Bienvenue, Invité. Merci de vous connecter ou de vous inscrire.
Avez-vous perdu votre e-mail d'activation ?

Auteur Sujet: [ODFAEG] (Open Source Development Framework Adapted For Every Game)  (Lu 50718 fois)

0 Membres et 1 Invité sur ce sujet

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #60 le: Mars 15, 2015, 09:20:28 pm »
Malgré cela :
Citer
Dans le cas improbable où un jour quelqu'un utilise ta bouse, il utilisera tes interfaces et pas la SFML ou la SDL non ?

Oui, il pourra utiliser mes interfaces, mais il ne sera pas obligé de le faire!

Cela dépend à quel niveau il veut travailler. (Au niveau du framework lui même ou bien seulement au niveau de SFML ou bien de la SDL, ou bien tout autre librairie)

Car pour créer des plus petits jeux la couche d'abstraction n'est pas nécessaire.

M'enfin de toute façon, cela ne regarde que moi, vu que personne d'autre à ma connaissance n'utilise mon framework, je le fais juste pour me simplifier la vie...

Mais je pense que il y en a quand même qui me suivent vu que j'ai quelque visite sur ma page facebook, bref...

TheYoungGeek43

  • Jr. Member
  • **
  • Messages: 87
    • Voir le profil
Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #61 le: Juillet 11, 2015, 12:25:45 am »
Bonjour,
J'ai vus se projet et il m'allair bien j'ai survolé le topic et je souhaiterais savoir où vous en êtes de se projet qui vas beaucoup servir je pense
L'échec est la preuve que l'on à essayer

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #62 le: Octobre 22, 2016, 05:44:30 pm »
Le framework à un site web, n'hésitez pas à aller lire la documentation :

Ici

lo7601

  • Invité
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #63 le: Janvier 03, 2019, 10:47:13 pm »
Je cloture ce topique odfaeg ne sera plus un projet SFML car SFML ne fonctionne pas avec ODFAEG je vais essayé une autre librairie SDL pour le fenêtrage et pour le réseau je vais voir du côté de boost asio. 

G.

  • Hero Member
  • *****
  • Messages: 1593
    • Voir le profil
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #64 le: Janvier 03, 2019, 10:56:44 pm »
Un vrai sketch. ::)

lo7601

  • Invité
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #65 le: Janvier 06, 2019, 11:41:24 pm »
Lol non j'ai dis une bêtise ça remarche avec SFML mais j'ai eu quelque crash à un moment donné que je n'avais pas eu avant lors de la création d'une fenêtre par exemple. (crash lors du partage du contexte opengl)

lo7601

  • Invité
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #66 le: Janvier 12, 2019, 10:06:09 pm »
Salut, je l'ai sans doute déjà dit mais SFML ne permet pas de faire grand chose, le développeur c'est juste contenté de faire des abstractions sur des petites libs mais ce n'est pas assez pour créer un jeux. J'ai alors essayé plusieurs moteurs de jeux existant mais je n'étais toujours pas satisfait alors j'ai décidé de créer mon propre moteur. Pour ne pas devoir recoder tout les modules j'ai décidé qu'il serait bien de reprendre les classes de la SFML comme base, mais ODFAEG permet de faire beaucoup plus de choses que SFML car c'est une surcouche de SFML, ODFAEG permet de :

-Faire du "sprite batching".
-Afficher des tiles semi-transparentes dans n'importe quel ordre.
-Afficher des ombres mais pour l'instant ODFAEG ne génère les ombres que à partir de la lumière ambiante. (Celle du soleil)
-Afficher des lumières mais pour l'instant seul les lumières ponctuelles sont gérées.
-Ajouter les objets dans un contenaire spécial et récupérer uniquement ce qui se trouve dans la vue.
-Affichage d'animations pour l'instant seul la méthode d'affichage des animations frame par frame est gérée.
-Envoyé et recevoir des messages sur le réseau de manière chiffrée.
-Récupérer le chemin d'un point A vers un point B.
-Ajouter un volume de collision à chaque objet.
-Dessiner des guis.
-Sauvegarder et lire des objets dans un fichier sans se soucier de la structure du fichier grâce à la sérialisation.
-Créer des évènements personnalisés grâce au système d'actions, de trigger et de slot.
-Afficher de la 3D et manipuler une vue 3D.
-Et encore pleins d'autres choses que je n'ai pas citées.


Par contre je ne gère pas encore la réfraction, ni l'importation de modèles 3D.

Malheureusement avant de continué le développement du framework et du futur jeux j'ai trouvé qu'il manque quelque chose au moteur pour qu'il équivale les moteurs de jeux récents tels que unity ou encore unreal engine : une interface graphique.
Et je suis justement entrain d'en faire une!
L'interface graphique du moteur ODFAEG s'appellera ODFAEG Creator.
Je pourrai déjà posté quelques vidéos de l'avancement du jeux, et de l'interface graphique mais, je trouve que c'est encore trop tôt.
Par contre il y a un gros bémol, mes shaders ne fonctionnent pas sous windows, pourtant je n'ai pas d'erreur de compilation de mes shaders sous windows et j'ai eu énormément de mal à compiler le moteur sous windows. (CMake ne supportais pas les accents, headers de la librairies openssl non trouvés hors que j'ai bien spécifié à CMake le dossier dans lequel il sont, etc..., etc...)
J'ai été déçu, je pensais pouvoir utiliser l'openGL moderne dans le moteur mais..., j'ai été aussi déçu d'apprendre que mon driver graphique sous windows ne supporte que opengl 4.1 et pas opengl 4.2 j'aurais voulu essayé imageLoadStore mais il parait que c'est lent, alors pour l'instant je continue le développement sous linux et je verrai après ce que je peux faire sous windows pour que ça marche aussi, l'affichage.







G.

  • Hero Member
  • *****
  • Messages: 1593
    • Voir le profil
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #67 le: Janvier 12, 2019, 11:02:32 pm »
J'imagine que puisqu'ODFAEG permet de créer des GUI tu utiliseras ODFAEG pour créer ODFAEG Creator ?

lo7601

  • Invité
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #68 le: Janvier 13, 2019, 12:00:07 am »
Citer
J'imagine que puisqu'ODFAEG permet de créer des GUI tu utiliseras ODFAEG pour créer ODFAEG Creator ?
Oui!

nagimar

  • Newbie
  • *
  • Messages: 36
    • Voir le profil
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #69 le: Juillet 15, 2021, 12:07:09 pm »
Salut! Je n'ai pas donné de nouvelles depuis longtemps, mais il va y avoir beaucoup de changement au niveau de ce projet, en effet.

J'ai remarqué la lenteur de la SFML et on m'a clairement fait savoir que la SFML n'était clairement pas une référence pour utiliser opengl de manière performante pour de gros projets. On m'a également dit que la création d'un contexte opengl par texture de rendu n'est pas une bonne solution qu'il valait mieux n'utiliser qu'un seul contexte. (Bien que dans un contexte multithread ou pour créer plusieurs fenêtre pas le choix, mais dans le cas du multithreading on m'a conseillé d'utiliser VULKAN)

Et je vais avoir besoin du multithreading pour faire plusieurs rendus hors écran simultanément (SFML ne le fait pas par défaut) en même temps, car, les appels à glDraw pour toutes mes textures de rendu sont lent, même si j'utilise le bindless texturing et les buffers pour ne faire qu'un seul appel à glDraw par texture de rendu.

Autre chose qui ralenti (mais côté CPU ici) ce sont les fonctions virtuelles, en effets, la recherche de la bonne fonction à appeler se fait à l'exécution et la SFML utilise des fonctions virtuelles.

J'ai alors réfléchi à une autre solution, sans pour autant supprimer l'héritage parce que j'avais pensé à un système de type ECS mais dans ce cas je devrais récupérer les composants de transformations de toutes les entités enfants, les enfants des enfants, etc... et calculer la matrice de transformation finale combinée et également les positions relatives hors que avec l'héritage je peux faire ça automatiquement avec une méthode onMove par exemple que je redéfini, comme ça, tout se remet à jour automatiquement à chaque fois que j'appelle move, sinon je devrai le faire manuellement après chaque appel à move. (SFML ne possède pas de méthode onMove)

Alors j'ai recherché une solution pour pouvoir utiliser l'héritage sans utiliser de fonctions virtuelles comme le fait la SFML, et j'ai trouvé une solution, qui utilise les templates variadique et le polymorphisme d'inclusion.

J'ai testé ça dans la fonction main la rapidité et je me suis rendu compte que c'est vachement plus rapide (4 fois plus rapide) que d'utiliser des fonctions virtuelles comme le fait la SFML, en plus j'en utilise pas mal dans ODFAEG actuellement, ce qui ralenti.

La solution que j'ai trouvée est d'inclure chaque nouveau type dans un tuple, et générer une série de fonctions qui vont se charger d'appeler un foncteur, sur le bon type. (En faisant une vérification (SFINAE) sur le nombre d'arguments et le type des arguments dans le cas d'une surcharge de fonction pour pas que le compilateur râle parce qu'il ne trouve pas la fonction lors de l'appel)

Et à l'exécution il va choisir la bonne fonction à appeler suivant le type, au moyen de if, else..., le type n'est rien d'autre que la position du type dans le "parameter pack".

Voici un code qui montre ce que ça donne au niveau de l'utilisation, j'ai testé et, ça à l'air vraiment cool, comme le type du tuple change à l'exécution je ne peux pas le stocker dans une classe en tant que variable membre, mais je peux le créer et le passer à une fonction (la boucle de jeux) ce qui m'évite de devoir utiliser un global.



Je pense également à mettre les constructeurs en privé et utiliser une factory qui va se charger de gérer les variables globale, plutôt qu'utiliser des variables statiques qui pose problème lors de l'utilisation de plugin, vu que sur windows, elles ne sont pas partagées lors de l'appel du pointeur de fonction extrait de l'une dll.

struct transformable {
    template<typename D>
    void move() {
        static_cast<D&>(*this).onMove();
    }
};

struct entity : transformable {
    unsigned int containerIdx, childrenContainerIdx, type, childrenContainerType, id;
    static unsigned int nbEntities;
    std::string managerName;
    entity() : transformable () {
        id = nbEntities;
        nbEntities++;
    }
    template <typename D, typename EntityManager>
    auto addChild(EntityManager& em, D* entity) {
        auto newem = em.add(entity);
        return newem;
    }
    template <typename EntityManagerArray, typename D, typename... Args, size_t... Ints, class = typename std::enable_if<sizeof...(Args) == 3>::type>
    void operator()(EntityManagerArray& ema, D* entity, std::string f, std::tuple<Args...> args, std::index_sequence<Ints...>) {
        if (f == "move") {
            move(ema, entity, std::get<Ints>(args)...);
        }
    }
    template <typename R, typename EntityManagerArray, typename D, typename... Args, size_t... Ints, class = typename std::enable_if<sizeof...(Args) == 3>::type>
    void operator()(EntityManagerArray& ema, D* entity, std::string f, std::tuple<Args...> args, std::index_sequence<Ints...>, R& ret) {
        if (f == "move") {
            ret = move(ema, entity, std::get<Ints>(args)...);
        }
    }
    template <typename R, typename EntityManagerArray, typename D, typename... Args, size_t... Ints, class... E, class = typename std::enable_if<sizeof...(Args) == 0>::type>
    void operator()(EntityManagerArray& ema, D* entity, std::string f, std::tuple<Args...> args, std::index_sequence<Ints...>, R& ret) {
        if (f == "f") {
            ret = func();
        }
    }
    float func() {
        return 1.1f;
    }
    template <typename EntityManagerArray, typename D>
    bool move(EntityManagerArray& ema, D* entity, float x, float y, float z) {
        transformable::move<D>();
        auto tp = std::make_tuple(x, y, z);
        ema.apply(entity->childrenContainerType, entity->childrenContainerIdx, "move", tp);
        return true;
    }
    void onMove() {
    }
};

unsigned int entity::nbEntities = 0;



struct sphere : entity
{
  sphere() : entity() {

  }
  void onMove() {
      std::cout<<"update datas on sphere instance : "<<id<<" moved"<<std::endl;
  }

};
struct rectangle : entity
{
  rectangle() : entity() {

  }
  void onMove() {
      std::cout<<"update datas on rectangle instance : "<<entity::id<<" moved"<<std::endl;
  }
};
struct convexshape : entity
{
    convexshape() : entity() {

    }
    void onMove() {
        std::cout<<"update datas on convex shape instance : "<<entity::id<<" shape"<<std::endl;
    }
};
template <typename D>
struct appli {
    bool running = false;
    bool isRunning () {
        return running;
    }
    template<typename EntityManagerArray>
    void update(EntityManagerArray em) {

    }
    template<typename EntityManagerArray>
    void init(EntityManagerArray& em) {
        static_cast<D*>(this)->onInit(em);
    }
    template<typename EntityManagerArray>
    void exec(EntityManagerArray& ema) {
        if (!running) {
            running = true;
            init(ema);
        }
        while(running) {

            static_cast<D*>(this)->onExec(ema);
        }
    }

};
struct myappli : appli<myappli> {
    sphere sph;
    rectangle rect, rect2;
    convexshape shape, shape2;
    myappli() : appli<myappli>() {

    }
    template<typename ManagerArrayEntity>
    void onInit(ManagerArrayEntity& ema) {
        sph.managerName="entity managers";
        rect.managerName="entity managers";
        shape.managerName="entity managers";

        ::EntityManager<IEntityManager, entity> ems;
        //ems.name = "entity managers";
        ::EntityManager<IEntityManager, entity> childrenem;
        //childrenem.name = "sphere children manager";

        auto children0em = sph.addChild(childrenem, &rect2);
        auto children1em = sph.addChild(children0em, &shape2);
        children1em.name = "sphere children";
        auto em = ems.add(&shape).add(&rect).add(&sph);
        em.name = "entity managers";
        auto emas = ema.add(&em).add(&children1em);
        sph.childrenContainerIdx = children1em.containerIdx;
        sph.childrenContainerType = children1em.type;
        exec(emas);
    }
    template<typename ManagerEntityArray>
    void onExec(ManagerEntityArray& ema) {
        bool retb;
        auto tp = std::make_tuple(1.1f, 2.2f, 3.3f);
        ema.apply(0, 0, sph.type, sph.containerIdx, "move", tp, retb);
        float retf;
        auto tp2 = std::make_tuple();
        ema.apply(0, 0, sph.type, sph.containerIdx, "f", tp2, retf);
        std::cout<<"rets : "<<retb<<","<<retf<<std::endl;
        ema.apply(0, 0, rect.type, rect.containerIdx, "move", tp, retb);
        ema.apply(0, 0, shape.type, shape.containerIdx, "move", tp, retb);

    }
};

int main(int argc, char* argv[])
{    
    myappli appli;
    EntityManagerArray<IEntityManager> entityManagerArray;
    appli.exec(entityManagerArray);

 

De gros changements sont à venir donc..., je ne sais pas si ODFAEG va rester un projet SFML, mais en tout cas le design de la SFML va être remplacé. (Enfin tout dépendra de la rapidité de ce nouveau design à l'exécution lorsque je l'implémenterai dans le framework et surtout, si ça fonctionne pour tout mes projets utilisant le framework.)








G.

  • Hero Member
  • *****
  • Messages: 1593
    • Voir le profil
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #70 le: Juillet 15, 2021, 10:20:47 pm »
T'étais pas déjà passé 10 fois à SDL ?  :o ???

nagimar

  • Newbie
  • *
  • Messages: 36
    • Voir le profil
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #71 le: Juillet 16, 2021, 09:07:23 am »
non, et puis de toute façon je possède une interface, je peux passer d'une lib à l'autre sans soucis si j'ai un problème avec SFML parce que par exemple SFML le module fenêtre de la SFML ne gère pas Vulkan, là je suis entrain de faire des tests pour voir ce qui est plus performant, je pense que un système sans polymorphisme est le plus performant car pas besoin de rechercher des types (enfin c'est ce qu'on m'a porposé de faire), cependant, pas de redéfinition de comportements possible donc plus lourd à mettre en œuvre et c'est ça qui est frustrant, qu'on utilise la POO et qu'au final on se rend compte que ...

Je vais quand même faire un benchmark pour voir si, ça vaut la peine de change le design du framework.



nagimar

  • Newbie
  • *
  • Messages: 36
    • Voir le profil
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #72 le: Juillet 17, 2021, 10:30:08 am »
J'ai essayé plusieurs design de conception et je me suis rendu compte que au niveau des performances, le design actuel est celui qui convient le mieux.

Par contre j'ai des pertes de performances au niveau des draws calls. Je ne sais pas trop ce que je vais faire, utiliser plusieurs threads pour éliminer les goulots d'étranglement, comme je faisais avant, je les avais retiré parce que, une personne m'avait conseillé de le faire mais j'ai remarqué que il faut pas toujours écouter ce que les gens propose, surtout sans avoir fait de tests de performance.

nagimar

  • Newbie
  • *
  • Messages: 36
    • Voir le profil
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #73 le: Juillet 23, 2021, 10:00:10 pm »
Salut à tous, ça y est j'ai enfin trouvé ou ça coïnce au niveau des performances!

https://quick-bench.com/q/jEGRWG62s39A0OzY22E-iNtuvWo

Je vais donc changer la conception du framework, il devrait être vachement plus rapide une fois cela de fait!
Je suis curieux de savoir ce que ça va donner au niveau du raytracing, qui pour l'instant, est beaucoup trop lent.

nagimar

  • Newbie
  • *
  • Messages: 36
    • Voir le profil
Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
« Réponse #74 le: Juillet 15, 2024, 08:44:43 pm »
Salut!
En ayant vu plusieurs développeurs créer des petites libs dans leur coin utilisant la SFML j'ai décidé de regrouper toutes ces petites libs dans un grand projet (ODFAEG) et ici je fini de coder ODFAEG Creator et enfin sortira la version 1.

J'ai donc regarder les sources de projets comme les librairies thor, sfgui, sfmovie que je dois encore intégrer, etc..., et je m'en suis inspiré pour les intégrer au code source de ODFAEG.
J'ai également intégrer des codes sources sur l'utilisation de opengl (per pixel linked list, dynamic environnement mapping, shadow mapping, per pixel lightning, etc...)

J'ai également fait un système ECS pour éviter la perte de performance due aux fonctions virtuelles.

Dans le rendrer pour les per pixels linked list désormais je met un bord autour de l'objet grâce au stencil buffer si l'objet est sélectionné.

J'utilise des optimisations pour le rendu tel que les le batching (je regroupe tout les sommets utilisant le même type de primitive et les mêmes matériaux pour les tracer avec le moins de drawcalls possible)

J'utilise également le bindless texturing pour réduire le nombre de drawcall et l'indirect rendering pour réduire les appels à draw pour l'instanced rendering on peut choisir si l'on veut dessiner les entités en mode instance ou en mode normal.

Le développeur à la possibilité d'utiliser la SFML pour les petits projets ou bien alors le système ECS de ODAEG pour les grands projets. (Le système d'héritage de la classe entity étant obsolète)

ODFAEG Creator se veut être un moteur de jeux générique c'est à dire que l'utilisateur devra créer ses propres scripts pour coder le gameplay car celui-ci varie selon le type de jeux que l'on veut créer et il y aura la possibilité de créer un objet du gameplay comme par exemple une quête (voir même n'importe quoi d'autre) avec ODFAEG Creator qui va juste récupérer toutes les informations des classes et vous n'aurai plus qu'à rentrer la valeur des variables et l'objet sera créé ou modifié ou supprimé et lorsqu'il sera crée vous pouvez lui ajouter un mesh si vous le souhaiter et le traiter comme si c'était un objet de ODFAEG. Je n'ai pas trouvé cette fonctionnalité ni dans unity ni dans unreal engine pour créer des monstres, des quêtes, voir même ce qu'on veut c'est d'ailleurs pour ça que j'ai crée mon propre moteur de jeux.

De plus j'ai trouvé le système de blueprint de unrela engine 5 et l'utilisation de unity assez compliquée il y a beaucoup d'options et faut suivre des tutoriels vidéos de 10h dans lesquels je ne comprends rien finalement.

Par contre j'ai dû laisser tomber vulkan pas moyen de faire un rendu hors écran et les libs ne sont fournit que avec visual studio qui ne compile pas ODFAEG ou bien alors sur linux que j'ai désinstallé parce que ça faisait planter windows en changeant des paramètres dans le bios.










« Modifié: Juillet 15, 2024, 08:48:26 pm par nagimar »

 

anything