Code erreur -1073741819 (0xC0000005)

**RDM_dev** · 25/09/2021, 01h42

Bonsoir c'est encore moi :p

Toujours sur mon ECS, cette fois-ci j'ai voulu lancer une instance pour tester, sauf que ma fenêtre se ferme presque instantanément en me retournant -1073741819 (0xC0000005)... J'avais déjà eu ce problème, j'avais posé la question et on m'avait dit "utilise le débuggeur", ce que j'ai fait mais... Ça m'a pas trop aidé... :'( Du coup je retente ma chance, en espérant que quelqu'un m'aide un peu plus qu'en me disant d'utiliser le débuggeur parce que, même si je peux pas nier que c'est un bon conseil, en l'occurrence là ça ne m'a pas aidé ^^'

Je vous mets mon code en pièce jointe, j'espère vraiment que vous pourrez m'aider !
Merci d'avance !

ECS_Essai2.zip

======================================================

EDIT : J'ai réussi à résoudre le problème en initialisant mon pointeur vers EntityManager dans la fonction Init de ma classe Engine, maintenant je n'ai plus l'erreur 0xC0000005 mais 0xCFFFFFFF :sob:

**LittleWhite** · 26/09/2021, 07h11

Bonjour,

Moi, perso, j'attends toujours votre retour dans la discussion initiale, où, en effet, j'ai recommandé d'utiliser le débogueur.
D'ailleurs, vu les erreurs que vous avez, le débogueur serait vraiment d'une aide inestimable, sachant qu'il pourra vous indiquer où cela crashe.

Et finalement, vous ne donnez pas de Makefile/CMakeFile/Ligne pour compiler votre projet. Du coup, j'ai un peu lâché l'affaire pour tester de mon côté.

**RDM_dev** · 26/09/2021, 12h52

Comme je l'ai dit dans mon premier post sur ce sujet, j'ai déjà utilisé le débogueur, et il ne m'a montré aucune erreur ^^' Et j'utilise Code::Blocks donc je sais pas quelle est la ligne utilisée pour compiler ^^'

**LittleWhite** · 30/09/2021, 22h00

Deuxième essai, je n'arrive toujours pas à compiler. Donnez nous le fichier du projet (pour Code::Blocks, c'est le .cbp). Sinon, donnez-nous tout votre dossier de travail, c'est pas si grave, non ?

**RDM_dev** · 03/10/2021, 12h33

Le soucis c'est pas que je veux pas donner tout le dossier de travail, c'est qu'il est trop lourd pour que je puisse l'uploader ici :p Sinon je peux l'uploader sur quelque chose du genre mediafire et j'envoie le lien ici, ça passe ?

**LittleWhite** · 03/10/2021, 20h17

Le cbp (le fichier de projet de Code::Blocks) suffirait. Mais en effet, j'ai pas vérifié s'il y avait des ressources nécessaires (images, sons). Du coup, un Mediafire ou autre, y a pas de souci.

**koala01** · 04/10/2021, 13h02

Salut,

Ce qui serait ien mieux encore que mediafire, ce serait de placer votre projet sur git (github, framagit ou autre), car cela vous permettrait, en plus, de garder l'historique de votre projet, au moins à partir du moment où vous l'auriez fait. Et ca, c'est souvent d'une valeur inestimable

Bien sur, ill va falloir vous habituer aux différentes commandes, car cela signifie de créer un dossier géré par git sur votre ordinateur. Mais, en

gros,
vous prenez un dossier vide dans lequel vous lancez la commande git init pour que git puisse y placer ses fichiers de travail
vous copiez / déplacez l'ensemble de votre projet dans ce dossier
vous ajoutez un fichier .gitignore dans lequel vous indiquez les différents dossiers et fichiers qui ne doivent pas être pris en compte (les dossiers de compilation, les différents résultats de la compilation etc)
vous lancez la commande git add * pour que git ajoute automatiquement tous les fichiers qu'il ne connait pas à la liste des fichiers qu'il gère
vous lancez la commande git commit -a -m "un message d'explication (idéalement, 80 caractères max" pour que git enregistre les changements apportés sur les fichiers qu'il gère (un ajout complet la première fois)
quand vous avez quelque de "correct" vous lancez la commande git push pour que git envoie les modifications apportées sur le serveur

Par la suite, vous pourrez créer de nouvelles branches, pour ne pas "salopper" la version "fonctionnelle" de votre projet (et commiter / envoyer les modifications apportées à ces branches (sur le serveur) ), et la logique sera toujours la même :

git add pour ajouter de nouveaux fichiers
git commit pour prendre en compte les modifications
git push pour envoyer vers le serveur

Avouez que ce n'est pas bien compliqué, non

**LittleWhite** · 04/10/2021, 18h04

Entièrement d'accord avec koala01

, utiliser Git, c'est apprendre à utiliser un outil extrêmement répandu.

**RDM_dev** · 04/10/2021, 19h10

J'essayerai Git, mais en attendant je vous envoie le projet sur Mediafire, ça sera plus rapide pour l'instant :p https://www.mediafire.com/file/ljh61...etECS.zip/file

**koala01** · 05/10/2021, 01h50

Oh, My God ...

Peut-être ne l'as tu pas encore compris, mais l'objectif principal d'un ECS est -- justement -- de proposer une alternative à l'approche purement orientée objets "classique", principalement pour contourner les limitations liées à l'héritage publique, qui peut -- dans bien des cas -- être remplacé par une agrégation / composition.

Mais ca signifie qu'il faut penser aux différents aspects de manière totalement différente! Par exemple, il n'y a absolument aucun besoin de faire hériter les différents composants d'une classe de base, et encore moins de vouloir à tout prix les données que ces composants contiennent dans une accessibilité autre que publique.

La notion d'entité, on peut la limiter à sa plus simple expression, étant donné que tout ce que l'on attend d'elle, c'est de fournir un identifiant unique. Cela pourrait donc se limiter à quelque chose comme un simple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

using EntityId = size_t;

Il nous faudrait donc juste un moyen de maintenir en mémoire la liste des entités qui existent, par exemple, à l'aide d'un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
std::vector<EntityId> & allEntities(){
    static std::vector<EntityId> entities;
    return entities;
}

Ainsi que le moyen de rajouter de nouvelles entités et de supprimer celles qui ne sont plus utiles. Cela pourrait se faire sous la forme de deux (allez, mettons trois, pour nous donner l'occasion de supprimer toutes les entités d'un seul coup

) fonction finalement très simples:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
EntityId createEntity(){
    static EntityId lastEntity{0};
    ++ lastEntity;
    auto & entities = allEntities();
    entities.push_back(lastEntity);
    return lastEntity;
}
void destroyEntity(EntityId id){
    auto & holder = allEntities();
    auto end = std::remove_if(holder.begin(), holder.end(),[&](EntityId check){return check==id;});
    holder.erase(end, holder.end());
}
void destroyAllEntities(){
    allEntities().clear();
}

Ouais... je sais... on pourrait envisager de faire plus compliqué pour la gestion des entités, par exemple, en permettant de récupérer les identifiants des entités qui n'existent plus... Mais, pourquoi faire compliqué dans un premier temps

Une fois que l'on sait traiter les entités, on peut s'attaquer aux composants. Il ne doit y avoir aucune relation entre les différents composants, qui doivent vraiment pouvoir travailler "tout seuls". Et, pour aller plus loin, tu peux te dire que ce ne sont que des agglomérats de données qui vont bien ensemble

Ainsi, si je me base sur le code que tu présente, tes différents composants pourraient ressembler à quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
/* ton Vect2F peut lui aussi être réduit à  sa plus simple expression ;) */
struct Vect2F{
    Vect2F(float x, float y):x{x},y{y}{
 
    }
    float x;
    float y;
};
struct RigidBody{
    RigidBody(float mass, float gravityScale, Vect2F const & force , Vect2F const & velocity, Vect2F const &drag):
        mass{mass}, gravityScale{gravityScale}, force{force}, velocity{velocity}, drag{drag}{
    }  
    float mass;
    float gravityScale;
    Vect2F force;
    Vect2F velocity;
    Vect2F drag;
};
struct Transform{
    Transform(Vect2F const & position, Vect2F const & scale, float rotation):
        position{position}, scale{scale}, rotation{rotation}{
    }  
    Vect2F position;
    Vect2F scale;
    float rotation;
};
struct Sprite{
    /* pas besoin de transmettre les données spécifiques utilisées par SDL ici, elles seront traitées "ailleurs" ;) */
    Sprite(EntityId spriteId, 
           int x, int y, int width, int height):
        spriteId{spriteId}, x{x}, y{y}, width{width},height{height}{
 
    }
    EntityId spriteId;
    int x;
    int y;
    int width;
    int height; 
};

Et c'est tout!

Même les constructeurs pourraient être supprimés sur ce coups... il ne sont donnés que pour simplifier le travail par la suite

Eventuellement, on pourrait envisager d'y ajouter "automatiquement" une information supplémentaire qui serait l'identifiant de l'entité à laquelle le composant est rattaché, ce qui nous donnerait quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
struct Vect2F{
    Vect2F(float x, float y):x{x},y{y}{
 
    }
    float x;
    float y;
};
template <typename T>
struct ComponentBase{
    ComponentBase(EntityId entityId):entityId{entityId}{
    }
    EntityId entityId;
};
struct RigidBody : ComponentBase<RigidBody>{
    RigidBody(EntityId entityId, float mass, float gravity, Vect2F const & force,
              Vect2F const & velocity, Vect2F drag):
        ComponentBase<RigidBody>(entityId), mass{mass}, gravityScale{gravity}, 
        force{force}, velocity{velocity}, drag{drag}{
    }  
    float mass;
    float gravityScale;
    Vect2F force;
    Vect2F velocity;
    Vect2F drag;
};
struct Transform : ComponentBase<Transform>{
    Transform(EntityId entityId, Vect2F const & position, Vect2F const & scale, 
              float rotation):
        ComponentBase<Transform>(entityId), position{position}, scale{scale}, 
        rotation{rotation}{
    }  
    Vect2F position;
    Vect2F scale;
    float rotation;
};
struct Sprite : ComponentBase<Sprite>{
    Sprite(EntityId entityId, EntityId spriteId, 
           int x, int y, int width, int height):
        ComponentBase<Sprite>{entityId},
        spriteId{spriteId}, x{x}, y{y}, width{width},height{height}{
 
    }
    size_t spriteId;
    int x;
    int y;
    int width;
    int height; 
};

Oui, je sais... Tu vas me dire que cela ressemble quand même furieusement à de l'héritage publique... Mais il ne faut pas se laisser berner par les apparences, car le propre de l'héritage publique est de créer une relation particulière entre les classes dérivées qui héritent d'une même classe de base, dans le sens où chaque classe dérivée peut "passer pour être" du type de la classe de base.

Il n'y a rien de tel ici car il n'existe absolument aucun lien entre la structure RigidBody (qui hérite pour la cause de ComponentBase<RigidBody>) et la structure Transform (qui hérite elle pour la cause de ComponentBase<Transform>). Et il en va -- bien sur -- de même pour toutes les autres structures qui pourront servir de composant

Bien sur, nous allons avoir besoin d'un moyen pour maintenir les différents ensembles composants d'un même type en mémoire. Cela pourrait être (pour n'importe quel composant) à l'aide d'une seule et unique fonction template proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
template <typename T, typename Holder = std::vector<T> >
Holder & allComponents(){
    static Holder components;
    return components;
}

Et, bien sur, nous voulons pouvoir rajouter ou retirer un composant à n'importe quelle entité, ce qui pourrait se faire, encore une fois, à l'aide d'une simple fonction template qui prendrait la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
template <typename Component, typename ... Params> // Component représente le composant à créer, Params représente les paramètres à  fournir au constructeur
Component & addComponent(EntityId entity, Params ... params){
    auto &holder =allComponents<Component>(); // on récupère le tableau des composants
    Component c{entity, params...};
    holder.push_back(c);
    return holder[holder.size()-1];
}
 
template <typename Component>
void removeComponent(EntityId entity){
    auto & holder=allComponents<Component>();
    auto end = std::remove_if(holder.begin(), holder.end(), [&](Component const & c){ return c.entityId == entity;});
    holder.erase(end, holder.end());
}

Et, tant qu'à faire, on pourrait vouloir savoir si une entité bien précise dispose effectivement d'un composant particulier... Et, pour bien faire, pouvoir récupérer le composant en question si tel est le cas

Ici aussi, des fonctions template relativement simples devraient faire l'affaire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
template <typename Component>
bool hasComponent(EntityId entity){
    auto & holder = allComponents<Component>();
    return std::find_if(holder.begin(), holder.end(), 
    [&](Component const & c){return c.entityId == entity;})!= holder.end();
}
 
template <typename Component>
std::optional<Component> componentById(EntityId entity){
 
    auto & holder = allComponents<Component>();
    auto found=std::find_if(holder.begin(), holder.end(), 
    [&](Component const & c){return c.entityId == entity;});
    if(found != holder.end())
        return *found;
    return {};
}

Note que je ne cherche pas absolument l'efficacité pour l'instant... Je veux juste te démontrer qu'il est possible de faire des trucs sympas avec quelques lignes de code et sans avoir recours à la POO. "Plus tard", nous pourrons essayer de voir s'il n'y a pas des structures (essentiellement des collections) ou des algorithmes plus "efficaces". Mais, pour l'instant, on veut quelque chose qui fonctionne d'abord et avant tout.

Et ca marche! Parce que je peux désormais créer autant d'entité que je veux (enfin, je suis soumis à la limite de la valeur maximale d'un size_t ce qui nous emmène à quelque chose comme 18 446 744 073 709 551 615 ... ca fait de la marge

) et, même si je n'ai pas encore la notion de services, je peux déjà utiliser les deux assez facilement. Regarde:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
int main(){
    auto id1 = createEntity(); // la première chose à faire est toujours de créer une entité ;)
    addComponent<RigidBody>(id1,1.f,2.f, Vect2F{3.f, 3.f},Vect2F{3.f, 3.f},Vect2F{3.f, 3.f});
    addComponent<Sprite>(id1, 3, 1,2,3,4);
    /* l'ordre dans lequel on ajoute les éléments n'a que peu d'importance tant que l'on a une entité 
     * à laquelle les ajouter
     */
   auto id2 = createEntity();
    addComponent<Sprite>(id2, 5,6 ,7,8,9);
    addComponent<RigidBody>(id2, 5.f, 6.f, Vect2F{7.f, 7.f},Vect2F{7.f, 7.f}, Vect2F{7.f, 7.f});
 
    /* je peux passer l'ensemble des entités qui existent en revue: */
    for(auto entity : allEntities()){
        /* ce qu'il faut faire */
    }
    /* je peux passer l'ensemble des composants qui existent en revue, sans m'inquiéter
     * des entités auxquelles ils sont rattachés
     */
    for(auto & component : allComponents<RigidBody>()){
        /* ce qu'il faut faire */
    }
    /* je peux récupérer le composant bien particulier associé à une entité particulière (et vérifier s'il existe au passage) */
    auto mySprite = componentById<Sprite>(5); // celui ci n'existe pas ;)
}

je me suis d'ailleurs amusé à créer quelques fonctions template en plus dans un exemple fonctionnel que tu retrouveras ==>ici<==.

Alors, bien sur, il manque la notion de services. Si je voulais vraiment ne pas me casser la tête, je pourrais "simplement" te dire que, dés que je vais créer une fonction qui travaille avec un ou plusieurs type(s) de composant, je créerais forcément un service dans la réalité des faits.

Et ca tombe bien, car ma réponse est déjà beaucoup trop longue... ce sera pour la prochaine fois, si cela t'intéresse

**RDM_dev** · 11/10/2021, 13h58

Merci énormément pour l'explication et l'aide, et désolé de répondre tant de temps après, j'ai eu quelques soucis de santé :p Je modifierai mon code du coup, mais j'ai l'impression que ça n'aura pas trop d'impact sur mon problème, qui est lié au TextureManager du coup :p

============================

EDIT : Je viens de me rendre compte que j'avais pas dit :
Je pense que mon problème vient de ma classe TextureManager, parce que quand je retire la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TextureManager::get().loadTexture(/*arguments*/);

présente dans l'initialisation de mon Engine le programme se lance correctement sans me produire l'erreur 0xCFFFFFFF

**Bousk** · 12/10/2021, 15h42

Il y a ~100% de chance que ton truc ne trouve pas le fichier.
L'erreur de débutant classique étant le working path mal défini, ou le chemin du fichier incohérent.

**RDM_dev** · 12/10/2021, 15h59

Clairement pas, j'ai même essayé en mettant le chemin absolu et j'ai toujours la même erreur... J'ai même mis mon fichier dans chaque dossier par lequel passe le chemin absolu, ainsi que dans tous les dossiers de mon projet ^^'

**ternel** · 15/10/2021, 12h39

A tout hasard, 0xcFFFFFFF, c'est la valeur "variable non initialisée" utilisée en debug par bien des compilateurs pour windows.

PS: Koala01, je t'aime, tu m'a démystifié l'ECS à un de ces points! Merci!!!