AccueilAccueil  FAQFAQ  RechercherRechercher  S'enregistrerS'enregistrer  MembresMembres  Connexion  

Partagez | 
 

 Structure pour un moteur de collisions

Voir le sujet précédent Voir le sujet suivant Aller en bas 
AuteurMessage
onilink_
Modérateur
avatar

Messages : 8915
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Structure pour un moteur de collisions   Jeu 7 Nov 2013 - 22:51

Salut,
ça fait un petit moment que j'ai écrit un moteur de collision pour mon jeu (couplé a la onilib) mais je me rend compte que c'est assez mal fichu au niveau de la structure.
En effet le système actuel utilise des casts de pointeurs et ne permet pas d'ajouter de nouvelle formes a celles déjà codé.


En ce moment j'ai une classe Shape:
Code:
struct Shape
{
    enum { NONE, PRECISE, RECTANGLE, DISK, ELLIPSE, CONVEX, POLYGON };
    
    virtual bool intersect(const Shape * s, double dx, double dy) const = 0;
    virtual bool intersect(double x, double y) const = 0;
    virtual int type() const = 0;
    virtual void draw(double x, double y) const = 0;
    
    virtual ~Shape() {}
};
Pour chaque nouvelle forme, je la dérive de Shape, et je ré-implémente type() avec la bonne constante associée.
Pour les collisions je ré-implémente intersect(const Shape * s...), puis je fait un code du genre:
Code:
if(s->type() == RECTANGLE)
    return intersect( *((Rect*) s), dx, dy );
/*
if(s->type() == PRECISE)
    return intersect( *((PreciseShape*) s), dx, dy );
    
if(s->type() == CONVEX)
{
    const ConvexPolygon * convex = (ConvexPolygon*) s;
    return convex->intersect(*this, -dx, -dy);
}
...
}
Ça me permet d'automatiser les collisions dans mon système d'objet, en passant directement l'adresse du masque de collision de mon instance.

Mais bon, en plus de pas être vraiment propre, ça empêche un utilisateur de la librairie de définir ses propres masques...
Donc si quelqu'un a une idée, je suis preneur :b

_________________
                 
Revenir en haut Aller en bas
D-z
Utilisateur confirmé: Rang *****
avatar

Messages : 1609
Localisation : Montpellier

MessageSujet: Re: Structure pour un moteur de collisions   Jeu 7 Nov 2013 - 23:16

Ça c'est un problème épineux. J'y ai déjà eu affaire, et ça s'est fini avec des classes templates, des fonctions templates, des macrofonctions horribles bourrées de token pasting, des templates récursifs et des reinterpret_cast de pointeurs de fonctions incompatibles faits à la tronçonneuse. Et j'avais quand même une enum qui listait les types de masques : en ajouter un générait tout ce qu'il fallait pour le collisionner avec tous les autres, plus qu'à implémenter les fonctions ; mais pas moyen à l'utilisateur d'en rajouter un.
De plus les reinterpret_cast de fonctions, c'est de la nitroglycérine : là ça marche parce que l'héritage en place est simple, et que les classes ont le même alignement, coup de bol. C'est prêt à exploser dès que je ferai un truc exotique avec, et je sais d'avance que ça serait violent ^^

Si j'en suis arrivé à une créature de Frankenstein pareille, c'est parce que le C++ n'a pas de double dispatching. Le dispatching simple assure qu'un objet polymorphique appelant une méthode virtuelle utilisera la bonne version, correspondant à son type réel au runtime. Le double dispatching consisterait à identifier les types polymorphiques passés en paramètre.

Si tu cherches "double dispatching", tu tomberas sur la solution utilisée en C++ : le Visitor Pattern. Principe : un objet descendant de A doit interagir avec un objet descendant de B. On va avoir la méthode virtuelle A::interact(B& theB). Mais au lieu d'utiliser B (de type réel inconnu car pas de double dispatching), on appelle une méthode virtuelle de B, en permutant appelant et paramètre :
Code:
void A::interact(B& theB) {
    return theB.interact(*this);
}
Le type de theB est alors résolu puisqu'il est l'appelant. this a lui aussi un type défini, donc le bon overload de B::interact est appelé. Problème résolu.

Je vais bientôt recommencer à bidouiller avec ça (j'avais fini par sortir le module collision de mon projet, il ne suivait pas l'évolution assez vite), je vais voir comment ça sort :p

_________________
 
Home is not a place, it's a feeling.
Revenir en haut Aller en bas
onilink_
Modérateur
avatar

Messages : 8915
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Structure pour un moteur de collisions   Jeu 7 Nov 2013 - 23:43

Mh ok je vois, en gros pour faire un truc propre je suis plus ou moins dans la ***** (oniquantique mrgreen2 ).

Je vais essayer d'assimiler le Visitor Pattern, on va voir si ça permet de donner un bon truc :b
Merci pour ta réponse.

_________________
                 
Revenir en haut Aller en bas
onilink_
Modérateur
avatar

Messages : 8915
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Structure pour un moteur de collisions   Ven 8 Nov 2013 - 10:34

Le visitor pattern fonctionne nickel (par contre Shape doit être en même temps l'élément et le visiteur :b), mon code est propre, c'est cool.
Merci pour ton aide Deezee :b

Par contre l'utilisateur ne pourra toujours pas ajouter ses propres classes pour les collisions, dommage.

_________________
                 
Revenir en haut Aller en bas
D-z
Utilisateur confirmé: Rang *****
avatar

Messages : 1609
Localisation : Montpellier

MessageSujet: Re: Structure pour un moteur de collisions   Ven 8 Nov 2013 - 14:41

C'est là où ça devient rigolo

_________________
 
Home is not a place, it's a feeling.
Revenir en haut Aller en bas
Contenu sponsorisé




MessageSujet: Re: Structure pour un moteur de collisions   

Revenir en haut Aller en bas
 
Structure pour un moteur de collisions
Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 1 sur 1
 Sujets similaires
-
» moteur qui claque
» Joints pour vidange
» HRP : Proposition de structure pour Forum 2
» Aide pour config moteur
» ASTUCE POUR DEMONTAGE MOTEUR 1300AB?

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
Forum Le CBNA :: Développement :: Programmation-
Sauter vers: