Bonjour, j'essaye de faire un flipper sur DS (en C)n mais j'ai un problème dans mes detections de collisions ...

Actuellement, voici comment je fais :

J'ai un sprite de 16x16 pixels qui représente ma bille.
J'ai un tableau de 256 x 192 (résolution de l'ecran) qui me sert pour les tests de collisions. La valeur 1 provoque une collision, la valeur 0 non.

Chaque cycle, je teste 16 points autour du centre de ma bille dans le tableau. Je fais la moyenne des coordonnées de tous les points dont la valeur renvoyée est 1. Cela me permet de savoir quel endroit de la bille est entré en collision.

Grace à cela, je peux calculer l'angle que fait la normale à la surface de contact avec l'horizontale, et calculer le rebond en faisant des sin et des cos.

Jusque là, tout marche SAUF 2 points :

La bille rebondit toujours sur la surface, alors que dans un vrai flipper elle roule plutot
Parfois, si la bille va trop vite, la collision se detecte mal (la bille est trop entrée dans la surface )

Avez vous une idée d'une autre facon de faire ??

Salut, pour le problème de vitesse de la bille, tu devrai peut-être faire varier la distance des points de détection de collision par rapport au centre de la bille en fonction de sa vitesse.
 
De même, la vitesse influe sur le rebond. si la bille arrive avec une vitesse élevée, elle va avoir tendance à rebondir fortement. Dans la cas contraire, elle va rebondir de manière négligeable, et suivre la surface a cause de la gravité.
 
Au fait tu gères l'inclinaison du flipper?

pour la pénétration, tu prends la position précédente et la nouvelle position et tu fais une dichotomie:  
si nouvelle position a trop pénétré, on prends le point milieu, si le point le milieu a trop pénétré on prends le 1/4 sinon on prends les 3/4 du vecteur ppos->npos, etc... itérativement. (forcément là ça merde si la position précédente n'est pas "safe" )
 
a toi de bien définir ce qu'est la collision "nette" et la pénétration (nécessitant une entrée en itération par dichotomie).
 
il serait aussi judicieux de travailler en virgule fixe ou flottante pour les coordonnées de la boule ainsi que son vecteur vitesse, et a l'affichage & test bitmap tu arrondis les coordonnées au pixel le plus proche.
 
ton contour de flipper, est-il "nuageux" ou peut-il être modélisé par des segments de droites, cercles/disques pour faire une détection mathématique plustôt qu'au niveau pixel ? (j'ai peur qu'avec une boule de 16x16, le comportement soit rapidement vilainement instable dû aux "points de collisions" possibles alignés sur cette faible résolution)
 
de plus tu pourrais coller des matériaux a tes segments/disques pour définir le rebond, l'effet, etc...

en fait ouais, je pense que le mieux serait de faire toute la méca en virgule flottante et d'avoir une réprésentation géométrique math en plus du bitmap.

Pour le moment, c'est tout en virgule flotante, mais j'ai mit le projet en veille, justement pour les problemes que tu cites (amortissemrnt différent selon le materiau, problemes d'instabilité ...), je verrai quand j'aurai fini mon autre projet en cours, bien plus simple

Salut    
 
Je travaille aussi sur un truc similaire.
 

 
 
Le problème c'est qu'on "active" l'interpollation de collision lorsque qu'on détecte que l'objet sera en collision à sa prochaine position, or si la distance parcourue est trop grande il y a risque de "dépasser" intégralement une surface fine de collision et donc la fonction de collision n'est pas activée. Je sais pas si je suis clair    
 
Le top ce serai de systématiquement découper la distance parcourue en petits bouts et pour chaque bout faire une détection de collision, mais c'est au détriment des perfs
 
 
Actuellement j'ai le problème où la surface de rebond peut changer de forme, et donc il faut déterminer la normale en fonction des pixels voisins. Je compte faire comme tu as fait getget, mais c'est un peu bourrin comme méthode

tout à fait pour l'histoire de la distance, le mieux est de soit faire des étapes intérmédiares, soit d'envelopper la trajectoire de la bille avec une bounding box (ou plustôt un truc avec des arrondis a chaque bout, donc l'eveloppe serait un segment associé avec un rayon).
 
ta surface de rebond qui change, c'est quoi une animation bitmap ? ou un élement bitmap que tu fais tourner ?

Pour le problème de collision, je pense aussi que tu aurais tout à gagner à faire du temps continu ou de t'en approcher avec des "space-time volumes" (volumes englobants entre deux étapes), comme proposé par bjone. Le "temps discret" (pas à pas), ce n'est pas adapté à un flipper ou bien avec des tas de contraintes sur les "time step", les vitesses, l'épaisseur des obstacles, etc. Bref, on évite !
 
Par contre, pour ton histoire de surface qui peut changer de forme, une représentation des surfaces de collision par des polygônes ou des courbes de béziers serait bien plus appropriée et l'interpolation de la normale au point de collision serait bien plus précis.

Vous pouvez expliquer un peu la tehnique du "space-time volumes", je ne vois pas trop comment l'utiliser...
 
Ma représentation des surfaces est pour l'instant une simple matrice avec des 0 ou 1 suivant s'il y a qqchose ou non. Cette surface se déforme lorsque des objets tappent dessus, en gros les 1 deviennent des 0, la surface n'est plus plane pour un deuxième objet qui collisionnerait au même endroit.
 
Je ne vois pas trop comment utiliser une surface polygone ; ça signifie qu'il faut à chaque "tour" vérifier que le segment trajectoire ne coupe pas chaque segment des polygones présents non ?

Les "space-time volumes" : dans le cas d'une boule qui passe d'un point A à un point B durant un "time step", cela revient à considérer non pas la boule au temps A puis la boule au temps B mais une "capsule" (cylindre aux extrémités arrondies) composée de l'union de la boule en A, la boule en B et le cylindre du même diamètre que la boule et d'axe le segment [AB]. En gros, on en revient à considérer un volume dans lequel on est sûr de trouver l'objet durant une période de temps donnée. Les intersections deviennent alors des intersections capsule/décor et non boule/décor. Je parle en termes de volumes, en 2D, cela devient des surfaces...  
 
Pour ta représentation du "décor"... Plusieurs personnes t'ont signifié que l'utilisation d'un bitmap pour de la physique n'est pas judicieuce... Il est très facile d'altérer des polygônes après chaque collisions... Un partitionnement de l'espace (du plan, plutôt) pourra t'aider si tu trouves qu'il y a trop de segments à tester à chaque frame. Je te suggère un QuadTree... Un BSP dans sa version plan pourrait aussi être pertinent si tu as des portions de décor non déformables...

Ha ok, je vois    
 
Merci pour ces explications, je vais tâcher d'implémenter ça dans mon application   .