2010-10-28 30 views
0

Hé les gars! Mon moteur physique marche assez bien (merci de le demander!) Et je suis prêt à commencer à travailler sur des choses encore plus avancées. Par exemple, j'essaie de configurer mon moteur de collision afin qu'un délégué arbitraire puisse être averti lorsqu'une collision se produit. Permettez-moi de créer un scénario pour vous:Schéma de délégué de détection de collision

Supposons que nous ayons l'objet A, l'objet B et l'objet C dans la simulation physique. Je veux être en mesure d'informer un délégué sur une collision entre A et B, ET informer un délégué potentiellement différent sur une collision entre A et C.

Un peu d'information de fond: J'ai une interface connue pour le délégué, je ont le potentiel de stocker l'état pour mon détecteur de collision (mais pas atm), et ont la capacité de stocker l'état dans les objets eux-mêmes. De même, j'utilise ce modèle de délégué pour gérer la résolution de collision, en définissant simplement le moteur physique en tant que délégué pour tous les objets par défaut, ce qui permet à l'utilisateur de modifier le délégué si vous le souhaitez.

Maintenant, j'ai déjà essayé d'avoir chaque objet stocker son propre délégué de collision qui serait informé quand une collision s'est produite. Cela n'a pas fonctionné car lorsque les objets avaient le même délégué de collision, la même collision était gérée deux fois. Quand je suis passé à seulement utiliser le délégué du premier objet (mais cela a été décidé), l'ordre de la simulation est devenu un problème. Je veux utiliser un dictionnaire, mais cela introduit une quantité importante de frais généraux. Cependant, cela semble être la direction que je dois prendre.

Donc, voici la question: se battre à la mort sur une solution appropriée. Comment résoudrais-tu ce problème?

Répondre

1

Je dois dire qu'il est un peu étrange que deux objets puissent avoir des délégués différents (lors d'une collision) et que ce serait encore pire si deux délégués identiques tiraient lors d'une collision. J'ai l'impression qu'ils devraient tous les deux tirer tout le temps ou seulement l'un d'entre eux devrait le faire. La cohérence est ce qui me dérange ici. Expliquant que cela aiderait un peu plus. Deuxièmement, si vous utilisez la version naïve de détenir un délégué pour chaque objet et que vous conditionnez sa fonctionnalité ("if (! Boolean indiquant que ce délégué a déjà été viré) {do something}"), cela pourrait être résolu avec un très petit frais généraux. Cela fonctionne, mais je n'aime pas ce genre de code. Ma suggestion (un peu complexe, donc réfléchis-y avant d'y travailler) est d'essayer de se concentrer sur un objet manager qui irait sur tous les délégués et invoquerait les deux qui étaient pertinents à la collision. Par exemple, A et B entrent en collision et le gestionnaire est appelé avec eux en tant que paramètres. Vous pouvez maintenant parcourir tous les délégués connus du système (en supposant qu'ils sont peu nombreux) et déclencher ceux qui correspondent à "delegate == a.del ou delegate == b.del". Cela entraîne des frais généraux plus importants, mais si nous parlons d'un petit nombre de délégués, cela fera très peu de différence. De l'autre côté, cela vous permettra d'étendre votre moteur de détection de collision dans ce domaine plus à l'avenir (comme l'existence de plus d'un délégué par objet).

+0

Votre suggestion est fondée. Je suis en train de concevoir quelque chose de similaire: un objet contrôleur prend des paires d'objets physiques comme des clés pour atteindre une valeur de délégué. Ce délégué est ensuite appelé avec la collision résultante entre les deux objets. Ainsi, lorsque A et B entrent en collision, le contrôleur recherche le délégué associé à A et B, puis, lorsque A et C entrent en collision, il recherche le délégué associé à A et C. Vous avez raison: cela a un coût important en termes de stockage et de complexité. Merci pour la suggestion! – Grimless

+0

J'ai décidé de définir des délégués par TYPE d'objet, ce qui semble être une solution acceptable. Merci! – Grimless