Salut tout le monde,
Je voudrais savoir si vous savez comment faire pour détecter si deux images 2D se touchent en n´utilisant pas la technique du rectangle englobant l´image mais celle du " pixel perfect" c´est a dire tester si le pixel de l´image 1 est utilisé ou pas pour le dessin de l´image et la comparer avec un autre pixel de l´autre image et voir s´il y a collision

Tu utilises un API graphique pour cela ? Si oui quel est-il ?

--log

C´est pour utiliser DirectX mais je passe par le moteur Game Incubator pour la programmation

Oké, ben moi et Direct Hyckss ça fait 15, alors demande à un beau et grand gars dans ce forum, il s´appelle LGV, et il est spécialisé dans la programmation DirectX

--log

pour le pixel perfect, il y a 2 passes :
- la 1ere n´est pas couteuse : c´est les boites englobantes qui se touchent
de la tu extrait un rectangle d´intersection
la seule solution est ensuite le double for : donc tester 1 a 1 tous les pixels de ce rectangle d´intersection.

Tu peux passer par une étapes intermédiaire, qui est, non pas d´englober ton modele par 1 boite englobante, mais par plusieurs : genre une pour chaque jambe, une pour chaque bras, une pour le tronc, une pour la tete.

Merci JYY pour ces précisions . ..
Mais tu peux me dire juste coment faire pour tester le pixel , et quel sera le type du pixel qu´on teste(nombre de bits) ? Et comment faire pour détecter si il correspond à un pixel transparent ou pas?

il faut accéder au tableau de pixel de chaque surface de l´image.
regarde si tu as des méthodes Lock() avec directX, qui te donne un pointeur sur l´image.

la prodondeur du pixel dépend de ce que tu as défini !
la on tombe dans l´exploration octet par octet.
si tu es en 32 bits, chaque pixel fera 4 octets.
ils sont toujours rangés de gauche a droite et de haut en bas. le nombre d´octets pour une ligne est définie par le pitch de ta surface ( que tu dois avoir) d´une maniere ou d´une autre.
Tu calcules et accede au bon pixel.
Pour qu´il y aie supperposition de pixel, il faut et il suffit que pour un pixel donné, le pixel correspondant de la surface 1 soit différent de la couleur définie comme transparente pour la surface 1, ET que le pixel correspondant de la surface 2 soit différent de la couleur définie comme transparente pour la surface 2.
Dans ce cas la, il y a collision au pixel pres, sinon, non.

Aucun exemple d´implémentation, je sais faire ça sous SDL ou OpenGL, mais pas DirectX.

pour compléter ce que dit JY² et les précédents, moi au contraire je peux t´expliquer en DirectX, mais si c´est encapsulé dans GameIncubator, je ne sais pas trop à quel niveau tu te places :/
avant d´aller plus loin, si tu pouvais préciser si via ton API tu as accés aux fonctionnalités DirectX ou si ces dernières sont toutes masquées,ça pourrait aider

Tu peux acceder a quelques fonctionnalités DirectX au travers du Game Incubator ( notement il est possible d´acceder aux surfaces DirectX).

Cependant en general dans un jeu, l´affichage et le systeme de collision sont 2 choses separés. En effet, acceder aux surfaces pour les lires et tester les pixels est quelquechose de trés lent ( les images sont compressés, les surfaces sont pas en memoire principale, etc . ..).

Il existe toujours une facon simple et autonome de tester une collision.

Il faut bien definir ce qu´il te faut et comment y arriver.

( car sert a rien de tester au pixel si au final tu te rends compte que toutes tes formes sont des formes geometriques simples par exemple).

tiens, un exemple typique d´inutilité de tester la collision au pixel pres :

un jeu de course a la F-zero GX ( j´adooooorrre!!!)
ça va tellement vite que si tu testais les collisions exactes, tu ne verrais pas la différence ( je te parie que c´est testé par boites englobantes...)

Tout a fait.

Le jeu de voiture sur lequel je viens de bosser utilise des spheres pour les collisions ( une pour chaque roue et une pour l´ensemble de la voiture) et ca suffit amplement.

Une sphère pour l´ensemble de la voiture ?
Pourquoi ne pas avoir choisis un cube ? ( a moins que ce ne soit des courses de Smarts )

l´avantage avec les spheres, c´est que la collision revient juste a calculer la distance entre 2 points, ou qu´ils soient
pour éviter la racine carrée, tu gardes en mémoire le carré du rayon de la sphere et c´est lui que tu compares :

ainsi, un calcul de distance euclidienne ( 3 multiplications, 2 additions, et 1 comparaison) et tu sais si tu touches ou non : C assez puissant.
Hélas, ça convient a peu de modeles ( hors de question de faire ça pour un bonhomme qui marche)
mais pour des vehicules, je pense que a peut etre pas mal du tout !

hors de question de faire ça pour
un bonhomme qui marche

Tout depends du nombre de sphere que tu utilise. Tu peut trés bien utiliser un modele de collision avec 9 sphere par exemple ( 2 pour bras et jambes, 1 pour bassin, 1 pour buste et 1 pour tete).