Je me suis mis en tête de créer un petit jeu de plateforme et j´aimerai avoir l´avis éclairé de quelqu´un connaissant le domaine de la détection de collision entre sprites et tilemap.
Entre 2 sprites, le principe est très simple et est décrit dans de nombreux sites, néanmoins concernant les collisions avec le décors, je n´ai rien trouvé : car cette dernière est plus compexe à mettre en oeuvre : exemple des plateformes sur lesquels on peut sauter ( ce qui signifie que le personnage doit passer à travers dans un sens ( saut) et rester dessus dans l´autre ( ne pas qu´il tombe comme si la plateforme n´existait pas)), des tiles en pente ( pas juste à 0 ou 90°) etc... je pensait faire bourrinement une sorte de catalogue de tile : celles qui ne laissent passer que dans un sens, dans les 2, solides etc... et faire des tests selon les cas, mais y a-t-il une méthode générale plus fine mis en oeuvre dans les jeux célèbres ?

Sinon, question concernant la gestion des physique, concernant nottament le saut ( phènomène de gravité) et les déplacement sur des tiles non planes ( genre celles en diagonale) : comment est-il mis en oeuvre dans ces mêmes titres commerciaux, pour savoir s´il existe une méthode meilleure qu´une autre ?
Merci des réponses

en quel langage ? parce que je peux te repondre en Actionscript . .. apres, pour le reste, j´imagine que Lapintade pourra t´orienter ( quoique le fait qu´il ne gere pas les tiles non-lineaires dans DNA me laisse penser que ce ne doit pas etre evident )

En Flash, basiquement, je n´utiliserai pas les sprites ( et encore moins la tilemap ) pour gerer la collision, mais une bibliotheque de lignes, non affichees, qui portent leur propres proprietes ( friction, gravite, direction de la poussee, etc )

Ca serait en C/C++, mais je m´intéressait à l´algorithmique générale, sachant que le moteur utilisera des bounding boxes pour les colisions inter-sprites.

j´y connais rien, mais j´imagine ( et je peux completement me planter, hein ! )

Tes tiles, lors de la lecture de la map, comporterai ent des " points cles", invisibles : la collision s´appuyerait sur les vecteurs definis en fonction ces points cles ( ce qui evite d´avoir 36 points cles pour en pente, quand tu peux n´avoir qu´un vecteur . .. tes vecteurs de collisions seraient calcules dynamiquement, lors de la lecture de la tile map, et organises en groupes de propriete ( par exemple, une meme pente qui est glissante en bas et rugueuse en haut serait composee de deux vecteurs . .. enfin, c´est comme ca que j´imagine la chose . .. je serai curieux de savoir si ce serait un solution viable en C++ . ..

Ou alors peut etre juste de la detection des pixels pleins ou vide, pour gerer la collision, mais cela fait beaucoup d´analyses / calculs . ..

Salut !

Alors pour une formule générale du tilemapping, j´ai bien une piste.
Cette piste coince cependant pour le fait que tu cites " ce qui signifie que le personnage doit passer à travers dans un sens ( saut) et rester dessus dans l´autre" --> qui n´est pas logique en réalité ( ce qui se comprend ! )

Avant tout, tu fais une fonction capable de te dire si oui ou non tu as le droit d´etre a l´endroit ou tu es :

int IsPossible(Bouding_box* mec,Monde* monde,Vecteur& normale);
qui te renverra 0 ou 1 si tu as le droit ou non d´etre la ou tu es.
Cette fonction doit, en outre, te renvoyer la normale a l´endroit ou tu touches :
si la fonction te renvoie 0, alors tu es dans le vide, et dans ce cas, tu renvoies vecteur NULL.
Sinon, si tu touches, a toi de préciser la direction de la normale au sol : c´est la que tu pourras faire tes pentes :
un bloc en pente renverra un vecteur en biais
De la, tu peux faire des blocs qui ont n´importe quelle tronche, a toi de savoir calculer le vecteur normal a n´importe quelle position, en fonction du type de brique touchée
A préciser que la norme de ce vecteur sera également importante : elle déterminera le coefficient de rebond de la brique !

Ensuite, tu ajoutes un petit moteur physique rudimentaire.
A chaque déplacement, tu regardes si tu atteris dans un sol ou non.
Si ce n´est pas le cas, la boucle est finie.
Si c´est le cas, tu dois trouver la position limite : pour cela, trouve la position entre la précédente et la courante ( interdite) qui est permise.
( dans un espace discret, tu peux te contenter d´un bete for, dans un espace reel, la dichotomie, avec un epsilon peut etre appliqué)
Replace ton sprite ici, et a la prochaine itération, ajoute la normale dans ta résultante de forces !

Enjoy !