4 réponses à ce sujet

[gilloub]

Bonjour à tous,

Je viens de poster sur mon blog un tutorial (en anglais) expliquant comment optimiser la détection de collision entre sprite en utilisant des bitmaps data. Il explique aussi comment l'implémenter avec l'API Starling (API utilisant le GPU pour l'affichage de sprite).
Merci d'avance, Les commentaires sont les bienvenus.
Voici le lien http://www.cocoapp.eu/?p=342

Merci

Modifié par gilloub, 19 December 2011 - 22:00 PM.

[dldler]

Bonjour Gilloub.

Un tutoriel de plus sur les collisions est toujours une bonne nouvelle tellement c'est une question récurrente.

Dommage qu'il soit en Anglais cela dit.

Sinon, je n'ai pas poussé très loin, mais je me demande si l'optimisation de ton code est vraiment poussée question CPU.
Par exemple, dès le début :

 var intersection:Rectangle    = rect1.intersection(rect2);
if(intersection.width != 0 || intersection.height != 0) //  rect collision
 

Récupérer les 2 rectangles des formes, + test d'intersection, + un if, avec deux inégalités et un OU, ça me semble un test lourd… D'autant que tu parles plutôt d'un ET dans le texte : "area has no width and no height"

Est-ce qu'un test simple type AABB basé sur des && ne serait pas plus efficace puisque dans un premier temps tu ne veux qu'un boolean ? Le nombre de fois ou ça éviterait le calcul d'un Rectangle et du if doit largement composer son inutilité dans le cas d'une collision (comparée au Rectangle, qui lui, effectivement, à l'avantage de resservir, je me comprends )


Idem plus loin, la determination de la zone NESW n'est pas du tout optimale… Je n'ai pas été plus loin.
Du coup, je ne sais pas trop si un francophone débutant a un intérêt à faire l'effort de te lire alors qu'il existe des tutoriels en français de bonne facture ? Un petit mot pour décrire le "plus" de ton article serait le bien venu.

[Logic]

Salut.

Je suis assez d'accord, la partie "avoid overlapping" n'est pas du tout dans l'esprit d'un système simple et optimisé. D'ailleurs, même sans parler d'optimisation , elle peut donner lieu à des comportements étranges. En effet, quand Mario saute sous une plateforme et la frappe avec sa tête, si sa vitesse est trop conséquente, il se peut que la détection de collision se fasse sur la partie SUD de Mario, et donc il serait "poussé" par dessus la plateforme.

Aussi, ne pas parler de collision entre sprite. Le Sprite en AS3 a sens bien précis (la classe Sprite), or un Sprite a la possibilité de rotation, ce que ton système ne prend pas en compte.

[gilloub]

Merci pour les commentaires.

Pour ce qui est des tests sur les rectangles, ce qui est mis plus en oeuvres c'est que le rectangle d'un sprite est stocker dans l'objet LitePhysicsData, il sont donc générer qu'un seul fois et pas à chaque tests de collisions. Pour ce qui est du test sur la taille du rectangle, je me suis rendu compte qu'une seul suffit.

Je suis assez d'accord pour ce qui est de la rotation des sprites, il est vrai qu'il serait intéressant de l'implémenter mais j'ai pas l'occasion de le faire pour le moment.

Dans la section overlapping, j'ai bien précisé que ce systeme avait ses limites et on peut voir dans le résultat final qu'on définir dans LitePhysicsData que certain obstacles peuvent êtres des plafond, des sols ou des murs. le système NSEW se base pas sur la position du personnage mais sur la position du rectangle d'intersection récupéré à la phase d'avant. Mais c'est vrai que si mon personnage se déplace plus et traverse le mur il sera projeter dans le mauvais sens.

Encore merci pour les feedbacks, je pense que je vais étoffer mon article plus tard.

[Logic]

Il te faut conserver la position de départ des objets. Comme ça tu sais exactement dans quelle direction les déplacer pour le "avoid overlapping". Par ailleurs avec ça en plus tu pourras optimiser en faisant une recherche par dichotomie, au lieu de décaler pixel par pixel.