Structure pour un moteur de collisions

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

Ç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

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

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.

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.

C'est là où ça devient rigolo