Partage
  • Partager sur Facebook
  • Partager sur Twitter

Plantage lors de l'appel d'une fonction d'un .dll

Sujet résolu
    13 janvier 2021 à 22:35:31

    alut, en fait, j'ai fais une classe qui récupère les constructeurs d'une classe créée par l'utilisateur, et une gui qui me permet de créer un objet de cette classe.

    Ensuite, l'application créée un script qu'il compile et exécute pour créer les objets et les ajouter dans l'application et les sauvegarder dans une fichier, voici le script en question :

    #include "C:/Users/Laurent/Projets/ODFAEGCREATOR/Test/Scripts/pnj.hpp"
    #include <fstream>
    #include <iostream>
    #include <vector>
    #include <string>
    #include "odfaeg/Core/archive.h"
    #include "odfaeg/Core/class.hpp"
    #include "../../Windows/Demos/ODFAEGCREATOR/application.hpp"
    extern "C" {
        void createObject(ODFAEGCreator* c);
        void readObjects (ODFAEGCreator* c);
    }
    std::vector<odfaeg::graphic::Entity*> vPnj;
    void createObject(ODFAEGCreator *c) {
        EXPORT_CLASS_GUID(BoundingVolumeBoundingBox, odfaeg::physic::BoundingVolume, odfaeg::physic::BoundingBox)
        EXPORT_CLASS_GUID(EntityTile, odfaeg::graphic::Entity, odfaeg::graphic::Tile)
        EXPORT_CLASS_GUID(EntityBigTile, odfaeg::graphic::Entity, odfaeg::graphic::BigTile)
        EXPORT_CLASS_GUID(EntityWall, odfaeg::graphic::Entity, odfaeg::graphic::g2d::Wall)
        EXPORT_CLASS_GUID(EntityDecor, odfaeg::graphic::Entity, odfaeg::graphic::g2d::Decor)
        EXPORT_CLASS_GUID(EntityAnimation, odfaeg::graphic::Entity, odfaeg::graphic::Anim)
        EXPORT_CLASS_GUID(EntityMesh, odfaeg::graphic::Entity, odfaeg::graphic::Mesh)
        EXPORT_CLASS_GUID(EntityParticleSystem, odfaeg::graphic::Entity, odfaeg::physic::ParticleSystem)
        odfaeg::core::Application::app = c;
       EXPORT_CLASS_GUID(EntityPnj,odfaeg::graphic::Entity,sorrok::Pnj)
       std::map<std::string, std::vector<odfaeg::graphic::Entity*>>::iterator itPnj = c->getExternals().find("Pnj");
       if (itPnj == c->getExternals().end()) {
           c->getExternals().insert(std::make_pair("Pnj",vPnj));
           itPnj = c->getExternals().find("Pnj");
       }
       if(itPnj->second.size() == 0) {
           odfaeg::graphic::Entity *questy = new sorrok::Pnj ();
           itPnj->second.push_back(questy);
           c->addExternalEntity(questy);
       }
       if(itPnj->second.size() == 1) {
           odfaeg::graphic::Entity *questy2 = new sorrok::Pnj ();
           itPnj->second.push_back(questy2);
           c->addExternalEntity(questy2);
       }
       std::ofstream ofPnj ("Pnj.oc");
       odfaeg::core::OTextArchive oaPnj (ofPnj);
       oaPnj(itPnj->second);
    }
    void readObjects (ODFAEGCreator *c) {
        EXPORT_CLASS_GUID(BoundingVolumeBoundingBox, odfaeg::physic::BoundingVolume, odfaeg::physic::BoundingBox)
        EXPORT_CLASS_GUID(EntityTile, odfaeg::graphic::Entity, odfaeg::graphic::Tile)
        EXPORT_CLASS_GUID(EntityBigTile, odfaeg::graphic::Entity, odfaeg::graphic::BigTile)
        EXPORT_CLASS_GUID(EntityWall, odfaeg::graphic::Entity, odfaeg::graphic::g2d::Wall)
        EXPORT_CLASS_GUID(EntityDecor, odfaeg::graphic::Entity, odfaeg::graphic::g2d::Decor)
        EXPORT_CLASS_GUID(EntityAnimation, odfaeg::graphic::Entity, odfaeg::graphic::Anim)
        EXPORT_CLASS_GUID(EntityMesh, odfaeg::graphic::Entity, odfaeg::graphic::Mesh)
        EXPORT_CLASS_GUID(EntityParticleSystem, odfaeg::graphic::Entity, odfaeg::physic::ParticleSystem)
        odfaeg::core::Application::app = c;
       EXPORT_CLASS_GUID(EntityPnj,odfaeg::graphic::Entity,sorrok::Pnj)
       std::ifstream ifPnj ("Pnj.oc");
       odfaeg::core::ITextArchive iaPnj (ifPnj);
       iaPnj(vPnj);
       c->getExternals().insert(std::make_pair("Pnj",vPnj));
       for (unsigned int i = 0; i < vPnj.size(); i++)
           c->addExternalEntity(vPnj[i]);
       c->updateNb("Pnj",vPnj.size());
    }
    

     Lorsque je ne crée qu'un seul objet pnj, ça passe, mais lorsque je veux en créer deux, ça plante, pourtant, j'ai bien fait un test sur la taille du vecteur pour ne pas réallouer le premier objet pnj lorsque je crée le deuxième et il ne va pas dans la méthode addExternal pour le premier objet lorsque je crée le deuxième mais rien à faire, ça plante comme si il y avait un accès concurrent ou bien que le premier objet pnj a été réalloué, pourtant l'application attend bien que la fonction du .so aie fini de s'exécuter avant de continuer donc il ne devrait pas y avoir d'accès concurrent.

    EDIT : Bon j'ai trouvé la solution, en fait, le problème c'est que lorsque je recompile le .so, comme j'ai alloué l'entité pnj dans le .so on dirait que à la recompilation du .so le premier object pnj n'est plus valide alors j'ai créer un vecteur temporaire dans lequel je stocke les entités à ajouté à partir de la dll :

    void ODFAEGCreator::addExternalEntity(Entity* entity, std::string type) {
        //std::cout<<"add entity : "<<entity<<std::endl;
        /*Command::sname = "EXTERNAL";
        name = "EXTERNAL";*/
        /*entity->setExternal(true);
        selectedObject=entity;
        displayTransformInfos(entity);
        displayEntityInfos(entity);
        getWorld()->addEntity(entity);*/
        std::map<std::string, std::vector<Entity*>>::iterator it = toAdd.find(type);
        if (it == toAdd.end()) {
            toAdd.insert(std::make_pair(type, std::vector<Entity*>()));
            it = toAdd.find(type);
        }
        it->second.push_back(entity);
    }

    Pour les cloner et les ajouter plus tard avec l'application :

    void ODFAEGCreator::onExec() {
        std::map<std::string, std::vector<Entity*>>::iterator it;
        std::map<std::string, std::vector<Entity*>>::iterator it2;
        for (it = toAdd.begin(); it != toAdd.end(); it++) {
            it2 = externals.find(it->first);
            if (it2 == externals.end()) {
                externals.insert(std::make_pair(it->first, std::vector<Entity*>()));
                it2 = externals.find(it->first);
            }
            for (unsigned int i = 0; i < it->second.size(); i++) {
                Entity* entity = it->second[i]->clone();
                entity->setExternal(true);
                if (i == it->second.size()-1) {
                    selectedObject=entity;
                    displayTransformInfos(entity);
                    displayEntityInfos(entity);
                    getWorld()->addEntity(entity);
                    it2->second.push_back(entity);
                }
                delete it->second[i];
            }
        }
        toAdd.clear();




    -
    Edité par OmbreNoire 14 janvier 2021 à 2:40:26

    • Partager sur Facebook
    • Partager sur Twitter
      14 janvier 2021 à 3:35:42

      >ça plante comme si il y avait un accès concurrent

      Toujours avec vos boucs émissaires pour pas cher.

      Bon, ces chemins à la con dans les "#include", vous comptez les utiliser encore longtemps ?

      Comme je l'ai déjà dit, le manque d'ABI en C++ fait que votre approche n'est qu'un horrible bricolage, et les "new" fait dans une Dll qui va se faire recycler, ça me laisse rêveur (l'application n'a pas forcement la même C-Runtime que la dll et la nouvelle version de la Dll n'a même pas forcement la même définition de la classe, c'est donc bien la mer..).

      Tant d'efforts pour un truc qui ne fonctionnera quasiment jamais dans le monde de la vraie vie véritable, c'est triste.

      C'est beau la confiance que vous avez de la classe "odfaeg::core::OTextArchive" pour qu'elle gère correctement les champs de types pointeurs, sans support de la réflexion nativement en C++. Moi, je suis plus suspicieux et je regarderais le contenu du fichier "Pnj.oc" pour voir s'il n'y colle pas des pointeurs bien foireux.

      Vous êtes bien gentil avec votre copie d'écran avec un "watch" de variable, mais avec la ligne ou ça plante, c'est quand même bien plus pratique, ainsi que le texte complet du message d'erreur/d'exception.

      P.S.: Arrêtez d'utiliser le terme script pour du code C++, et pour du code de tout langage compilé, ce ne sont pas des scripts (et c'est bien pour cela que votre approche est foireuse).

      P.S.S.: C'est couillu d'utiliser une variable globale (vPnj) quand on vous a déjà indiqué que les variables statiques, c'est comme les variables globales, c'est un piège à con.(mais bon ici, c'est peut-être un cas "justifié")

      EDIT :

      >on dirait que à la recompilation du .so le premier object pnj n'est plus valide

      Bin forcement, quand vous déchargez une Dll, c'est aussi bien le code que son ou ses segments de données.

      Quand vous rechargez la Dll, elle n'est même pas obligée d'être rechargée avec les même adresse.

      Je pensais que votre fichier d'objet sérialisée : "Pnj.oc", servait justement à conserver ces données entre le déchargement et le rechargement.

      Et remerciez le fait de n'avoir qu'un heap (un seul runtime-C) pour que votre hack ne se casse pas la gueule.

      -
      Edité par bacelar 14 janvier 2021 à 3:44:45

      • Partager sur Facebook
      • Partager sur Twitter
      Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
        14 janvier 2021 à 9:05:55

        Pourquoi alloues donc tu la mémoire manuellement avec new/delete au lieu d'utiliser std::make_unique et un std::unique_ptr ?
        • Partager sur Facebook
        • Partager sur Twitter
        l'azerty est aux dispositions ce que subversion est aux SCM
          14 janvier 2021 à 12:40:06

          Franchement, il vaudrait mieux utiliser un vrai langage de script...
          • Partager sur Facebook
          • Partager sur Twitter

          Si vous ne trouvez plus rien, cherchez autre chose.

            14 janvier 2021 à 15:53:45

            Je plussoie. À force de faire trop de généricité et d'overengineering on perd en simplicité et stabilité. Le C++ n'est pas un langage de script c'est un langage statique et compilé.

            Si ton but est de « charger » des objets dynamiques pour ton jeu alors un langage de script est plus adapté. Sinon en C++, code tout simplement tes entités directement dans ton application. Les charger dynamiquement n'a absolument aucun bénéfice.

            -
            Edité par markand 14 janvier 2021 à 15:54:09

            • Partager sur Facebook
            • Partager sur Twitter
            l'azerty est aux dispositions ce que subversion est aux SCM
              14 janvier 2021 à 21:51:34

              markand a écrit:

              Pourquoi alloues donc tu la mémoire manuellement avec new/delete au lieu d'utiliser std::make_unique et un std::unique_ptr ?

              Bonjour,  comme je crée l'entité avec le .so et que je le delete dans l'application, il faudrait que j'utilise des std::move je pense pas que ça serait plus simple de faire comme ça.

              dragonjoker a écrit:

              Franchement, il vaudrait mieux utiliser un vrai langage de script...

              Je ne connais pas de langage de script et je ne sais pas si il est possible d'exécuter une fonction d'un .so ou d'un .dll à l'exécution, mais pour l'instant ça fonctionne comme ça donc...

              markand a écrit:

              Je plussoie. À force de faire trop de généricité et d'overengineering on perd en simplicité et stabilité. Le C++ n'est pas un langage de script c'est un langage statique et compilé.

              Si ton but est de « charger » des objets dynamiques pour ton jeu alors un langage de script est plus adapté. Sinon en C++, code tout simplement tes entités directement dans ton application. Les charger dynamiquement n'a absolument aucun bénéfice.

              -
              Edité par markand il y a environ 5 heures

               Le problème c'est que comme le gameplay n'est jamais le même suivant le type de jeux, les classes ne sont jamais les mêmes, donc, si je code directement les entités dans l'application je devrai modifier les classes de l'application à chaque fois que je change de jeux. Le fait de charger les objets dynamiquement, m'évite de devoir faire ça, voilà le bénéfice de faire ça, surtout si je ne veux pas que l'utilisateur aie accès au code source de l'application et aie à le modifier mais qu'il puisse créer de nouvelles entités pour son jeux. 

              Bon j'avoue c'était galère à faire récupérer les informations sur les classes (constructeurs, fonctions membres, etc...) et de créer un .so qui crée les objets dynamiquement car à chaque recompilation et rechargement du .so la mémoire du .so se décharge, j'ai du donc faire tout un bazard. (passer les entités créées avec le .so à l'application et les cloner) En plus j'ai dû aussi supprimer les variables statiques et les remplacer par des variables membres car, elles étaient recréées à chaque rechargement du .so.

              Bref ça n'a pas été simple, je le reconnais, il y avait peut être moyen de faire mieux je ne sais pas, c'est la première fois que j'ai à faire quelque chose du genre, mais maintenant que ça fonctionne, ça va me faire gagner un temps fou, éviter de devoir modifier le code de l'application à chaque fois que je crée un nouveau type d'entité pour un jeux, je n'ai juste qu'à copier les fichiers du jeux dans un dossier du projet créé avec l'application et les créer dynamiquement avec l'application, les modifier, etc... et la réflexibilité me permet de ne pas avoir à recréer une nouvelle gui pour créer/modifier un nouveau type d'entité dont je ne connais de toute façon pas la structure à l'avance.

              Bref, ODFAEG et ODFAEGCreator n'ont pas été créer dans le but d'offrir de la simplicité et de la stabilité, mais d'offrir un système de généricité et d'over engineering de tel sorte que l'utilisateur puisse faire ce qu'il veut et rendre ça le plus flexible possible en devant modifier le moins de code possible. 

              ODFAEG permet entre autre de :

              -sérialiser des objets (par valeur ou des pointeurs) en utilisant des archives de n'importe quel type afin de sérialiser des objets sans avoir à se soucier du format de fichier (Txt, xml, binaire, etc...) bien que pour l'instant je n'ai fait qu'un type d'archive pour le format txt. 

              -créer des fonctions de callback et, leur passer des paramètres et aussi utiliser un système comme std::bind et les ajoutés dans un tableau comme ça pas besoin de créer un tableau différent, pour chaque type de fonction de callback.

              La réflexibilité permet de créer des menus pour créer n'importe quel type d'objets. (pour ODFAEGCreator)

              Le runtime compiler permet de créer des objets dynamiquement. (pour ODFAEGCreator)

              • Partager sur Facebook
              • Partager sur Twitter
                Hier à 0:29

                Si tu dois modifier ton moteur pour créer un jeu, c'est que tu as un gros soucis de conception, au niveau flexibilité...

                Un langage de script va te permettre de communiquer avec ton moteur via une API que tu auras définie et implémentée.
                Renseigne toi sur Lua, Python (avec Boost.python ça va assez vite).
                Pour Castor3D, j'ai une API Python et une API COM (pour pouvoir utiliser Castor3D en C# et autres langages Microsoft supportant COM, c'est à dire... presque tous ?)

                -
                Edité par dragonjoker hier à 0:30

                • Partager sur Facebook
                • Partager sur Twitter

                Si vous ne trouvez plus rien, cherchez autre chose.

                  Hier à 9:41

                  >comme je crée l'entité avec le .so et que je le delete dans l'application

                  Il faut donc que votre application et votre ".so" soit compilé avec le même compilateur, les mêmes réglages dans toute la chaîne de compilation et partage la même C-runtime, et aient le même code dans le destructeur, quel ironie quand on cherche à avoir quelque chose qui change tout le temps.

                  >Je ne connais pas de langage de script

                  Ca se compte pas centaines et c'est comme si ils tenaient pas le haut du pavé : Python, Lua, Javascript, etc...

                  >si il est possible d'exécuter une fonction d'un .so ou d'un .dll à l'exécution

                  Vous confondez but et moyen. Oui beaucoup permettent d'exécuter des fonctions C exporté par une Dll, mais on s'en fout, les scripts se chargent et se déchargent bien plus facilement qu'une Dll native.

                  Avez-vous commencé par analyser ce qui se faisait dans "l'industrie", avant ?

                  • Partager sur Facebook
                  • Partager sur Twitter
                  Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
                    Hier à 10:11

                    OmbreNoire a écrit:

                     Le problème c'est que comme le gameplay n'est jamais le même suivant le type de jeux, les classes ne sont jamais les mêmes, donc, si je code directement les entités dans l'application je devrai modifier les classes de l'application à chaque fois que je change de jeux. Le fait de charger les objets dynamiquement, m'évite de devoir faire ça, voilà le bénéfice de faire ça, surtout si je ne veux pas que l'utilisateur aie accès au code source de l'application et aie à le modifier mais qu'il puisse créer de nouvelles entités pour son jeux. 

                    Alors ton moteur fait trop de choses. Par exemple, si tu veux quelque chose de générique sans que ce soit compliqué; tu peux faire une entité qui sait se dessiner à l'écran en fonction de données simple (géométrie, effet, vélocité). De ce fait, que tu code un shoot em up, un RPG ou un sidescroller ça ne change rien. Ton application se lie à ta bibliothèque et rajoute des nouvelles entités qui vont bien.

                    Charger des .so/.dll doit rester une opération anecdotique. J'ai jamais vu un quelconque jeu/moteur charger chaque entité de données de cette manière. Comme déjà dit, il n'y a aucun intéret. Tu sépare ton moteur de ton « code de jeu » et lorsque tu initialise ton jeu tu ajoutes les objets qui vont bien à ton moteur, aucunement besoin que ce soit fait dynamiquement.

                    Exemple :

                    // Fonction fournie par le « moteur »
                    void Scene::add(Entity& e);
                    
                    
                    
                    
                    // Code de jeu de ton application
                    Entity mario;
                    Scene scene;
                    mario.addShape("mario.png");
                    scene.add(mario);

                    Dans tous les cas je t'invite fortement à lire le principe KISS.

                    -
                    Edité par markand hier à 10:34

                    • Partager sur Facebook
                    • Partager sur Twitter
                    l'azerty est aux dispositions ce que subversion est aux SCM
                      Hier à 19:16

                      Et pour les entités personnages par exemple, monstres ou bien pnj, quest je fais comment ? Sachant que les variables de ses classes peuvent changer suivant le jeux.

                      Parce que il y a les données simples oui (géométrie, etc..) qui sont communes à toutes les entités et que je peux inclure dans ODFAEGCreator, mais pour les autres données, le problème c'est que je ne les connais pas à l'avance et donc pour les créer je dois utiliser la réflexibilité et un .so (je ne peux pas les inclure dans le moteur) pour ne pas avoir à modifier le code source de ODFAEGCreator à chaque fois que je veux créer de nouvelles données. 

                      Je veux faire un peu comme le système d'assets de unity, mais, avec en plus une gui qui permet de créer les nouveaux types d'entité (GameObject avec unity) sans que l'utilisateur aie besoin de modifier le code source de ODFAEGCreator. Donc je fais les include dans le .so plutôt que dans ODFAEGCreator.

                      Et il y a trois type d'objets :

                      -Les entités interne à ODFAEGCreator, celles-ci sont crées/modifiées/supprimées avec ODFAEGCreator.

                      -Les entités externes qui hérite de la classe Entity, elles sont crées et supprimées dans le .so parce que ODFAEGCreator ne connais pas la structure des données à l'avance, pour la modification, les données communes sont modifiées avec ODFAEGCreator et les données non communes dans le .so.

                      -Les entités externes qui n'héritent pas de la class Entity : ells sont crées, modifiées et supprimées dans le .so.

                      Bref je veux créer un système un peu comme le système d'assets de unity mais avec en plus une GUI qui permet de créer,  modifier ou supprimer ces nouveaux "GameObject" sans devoir modifier le code source du moteur.

                      -
                      Edité par OmbreNoire hier à 19:19

                      • Partager sur Facebook
                      • Partager sur Twitter
                        Hier à 21:05

                        OmbreNoire a écrit:

                        Et pour les entités personnages par exemple, monstres ou bien pnj, quest je fais comment ? Sachant que les variables de ses classes peuvent changer suivant le jeux.

                        Mais c'est toujours pareil. Tu fais une bibliothèque spéciale orientée RPG avec ce que un objet de type PNJ est censé gérer et lorsque tu te lies à cette bibliothèque tu créé autant d'objet que ton scénario a besoin.

                        Par exemple, tu peux découper ton moteur du style :

                        • engine-core (utilitaires de base)
                        • engine-graphics (gestion très primitives des graphismes)
                        • engine-rpg (spécialisé dans les RPG : quêtes, pnj, etc)

                        OmbreNoire a écrit:

                        Je veux faire un peu comme le système d'assets de unity, mais, avec en plus une gui qui permet de créer les nouveaux types d'entité (GameObject avec unity) sans que l'utilisateur aie besoin de modifier le code source de ODFAEGCreator. Donc je fais les include dans le .so plutôt que dans ODFAEGCreator.

                        Rien ne t'empêche de générer du code C++ tout prêt avec ton éditeur si tu ne souhaites pas utiliser un langage de script. Ensuite, tu compiles ces fichiers sources. C'est ce que font des outils comme des designers UML.

                        • Partager sur Facebook
                        • Partager sur Twitter
                        l'azerty est aux dispositions ce que subversion est aux SCM
                          Hier à 22:06

                          markand a écrit:

                          OmbreNoire a écrit:

                          Et pour les entités personnages par exemple, monstres ou bien pnj, quest je fais comment ? Sachant que les variables de ses classes peuvent changer suivant le jeux.

                          Mais c'est toujours pareil. Tu fais une bibliothèque spéciale orientée RPG avec ce que un objet de type PNJ est censé gérer et lorsque tu te lies à cette bibliothèque tu créé autant d'objet que ton scénario a besoin.

                          Par exemple, tu peux découper ton moteur du style :

                          • engine-core (utilitaires de base)
                          • engine-graphics (gestion très primitives des graphismes)
                          • engine-rpg (spécialisé dans les RPG : quêtes, pnj, etc)

                          OmbreNoire a écrit:

                          Je veux faire un peu comme le système d'assets de unity, mais, avec en plus une gui qui permet de créer les nouveaux types d'entité (GameObject avec unity) sans que l'utilisateur aie besoin de modifier le code source de ODFAEGCreator. Donc je fais les include dans le .so plutôt que dans ODFAEGCreator.

                          Rien ne t'empêche de générer du code C++ tout prêt avec ton éditeur si tu ne souhaites pas utiliser un langage de script. Ensuite, tu compiles ces fichiers sources. C'est ce que font des outils comme des designers UML.

                          Ouais mais bon tout les rps n'utilisent pas forcément les même variables pour les quêtes, les pnj, etc..., c'est un peu casse gueule je sais bien mais bon...

                          Si je génère du code c++ compilé avec l'éditeur plutôt que de généré un .so pour créer les entités ça va être galère parce que pour modifier tout ce qui est commun aux entités (géométrie des pnjs, entités enfants pour l'affichage, etc...), je vais devoir modifier le code c++ hors que en faisant un .so qui crée une entité pnj et l'ajoute à l'éditeur, je peux créer une entité Tile par exemple ou Animation avec l'éditeur et réutiliser le code de l'éditeur pour ajouter l'entité tile comme enfant de l'entité pnj, bref, je pense qu'il faudrait que je fasse une vidéo tu comprendrais peut être mieux ce que je veux faire non ?  

                          -
                          Edité par OmbreNoire hier à 22:07

                          • Partager sur Facebook
                          • Partager sur Twitter
                            Il y a environ 22 heures

                            > je dois utiliser la réflexibilité et un .so

                            Non, ou plutôt vu que ton système est écrit dans le marbre alors oui...
                            Tu pourrais faire qu'un composant expose une interface name/type qui te permettra alors d'afficher/modifier ce que tu veux comme tu veux

                            > Les entités externes qui hérite de la classe Entity

                            Ton système d'entités est pourri, si tu dois faire ça... (pour te donner une idée, dans mon ECS, une entité est un entier tout con)

                            • Partager sur Facebook
                            • Partager sur Twitter

                            Si vous ne trouvez plus rien, cherchez autre chose.

                              Il y a environ 18 heures

                              Un moment donné, il va falloir que tu réalises que tu t'es complement planté. Tu fais des choses qui sont complètement WTF, que personne ne fait (un .so sous Windows ???).

                              Honnêtement, ca me fait penser a un débutant qui a lu le tuto C++ du SdZ, a vu la structure d'un jeu en dur dans le code et s'est dit qu'il allait faire un moteur de jeux basé sur cette architecture.

                              Mais si personne ne fait ca, c'est pas pour rien.

                              C'est pas grave de faire des erreurs, a partir du moment ou l'on arrive à se remettre en question. Mets ton moteur de côté et lis des livres de C++, de conception logiciel, d'architecture des moteurs de jeux. Et fais des projets simples.

                              Ou n'écoutes pas les conseils et fais comme tu veux.

                              (EDIT : il y un projet ODFAEG sur GitHub, sur Developpez.com sur le forum de la SFML, mais fait par un certain Laurent. Tu dis dans ta bio que tu t'appelles Florian. Vous êtes la même personne ? Ton projet ODFAEG est bien celui sur GitHub ?)

                              -
                              Edité par gbdivers il y a environ 18 heures

                              • Partager sur Facebook
                              • Partager sur Twitter
                              Pour poser des questions ou simplement discuter informatique, vous pouvez rejoindre le discord NaN.
                                Il y a environ 6 heures

                                Salut! Mon moteur (même si il est pourrit) suffit pour répondre à mes besoins et je les connais mieux que quiconque.

                                Laurent c'est bien moi, j'ai dû me tromper dans ma description.

                                -
                                Edité par OmbreNoire il y a environ 5 heures

                                • Partager sur Facebook
                                • Partager sur Twitter
                                  Il y a environ 3 heures

                                  OmbreNoire a écrit:

                                  répondre à mes besoins 

                                  Mouais. Ok.

                                  ------------------------------------------------------------------------------------

                                  Pour les autres débutants qui liraient cette discussion :

                                  On voir encore et encore les mêmes erreurs chez les débutants et donc on répète encore et encore les mêmes conseils. 

                                  1. notre propos n'est pas de vous faire abandonner votre projet. Au contraire, on vous donne des conseils pour que vous le réussissez. Mais cela implique souvent qu'on vous conseille de mettre de côté votre projet, d'apprendre progressivement, de faire des projets intermédiaires.

                                  2. Si vous voulez faire un jeu, utiliser un moteur de jeux. Créer un jeu et créer un moteur de jeux, c'est deux boulot différents.

                                  3. Si vous voulez faire un moteur de jeux... utilisez un moteur de jeux. Ca peut paraitre paradoxal, mais c'est une base en développement : on étudie l'existant quand on aborde un nouveau domaine. Ca veut dire lire des tutos ou livres sur les moteurs de jeux et leur développement, mais ca veut dire aussi utiliser un minimum des moteurs de jeux, pour savoir comment les autres ont fait.

                                  4. Créer un moteur de jeux est une tâche très complexe. Trop complexe pour les débutants. Il faudra avoir de bonnes bases en programmation (donc lisez des bons cours et pratiquez beaucoup), en conception et gestion de projet (ca fait la différence entre un projet qui est réalisé en 1 an, et le même projet réalisé en 10 ans parce que n'importe quoi), et pleins d'autres compétences, qui prennent du temps à acquérir.

                                  Il n'y a pas un choix à faire entre une voie rapide et difficile et une voie lente et facile. Il n'y a qu'une seule voie pour créer un moteur de jeux : une longue et difficile. Il faut beaucoup étudier, beaucoup pratiquer, accepter d'y aller progressivement, faire des erreurs et apprendre de ses erreurs.

                                  Et pour ceux qui ne veulent pas suivre les conseils qu'on donne... à dans 10 ans, avec votre projet qui ne sera pas abouti.

                                  -
                                  Edité par gbdivers il y a environ 3 heures

                                  • Partager sur Facebook
                                  • Partager sur Twitter
                                  Pour poser des questions ou simplement discuter informatique, vous pouvez rejoindre le discord NaN.
                                    Il y a environ 1 heure

                                    J'ai trouvé ça : https://www.youtube.com/watch?v=3OB3j330SMc
                                    • Partager sur Facebook
                                    • Partager sur Twitter

                                    Plantage lors de l'appel d'une fonction d'un .dll

                                    × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                                    • Editeur
                                    • Markdown