Ensuite, j'ajouterais que Fg est une force conservative, et que Fc est normale à la trajectoire, donc exerce un travail nul.
Donc si Fp = 0 (aucune action sur le paddle), l'énergie mécanique Em = Ec + Ep = 1/2*mv² + mgh = m/2 (v² + 2gh) se conserve, donc la quantité vr2 = 2Em/m = (v² + 2gh) est constante (je ne sais pas si cette quantité a un nom officiel, donc je l'appelle vr2, 'carré de la vitesse de référence à l'altitude nulle'), et vr2 change éventuellement si Fp est non nulle.
Donc quand on lâche les commandes, il suffit de calculer vr2 à cet instant, et on laisse Sonic suivre le terrain en mesurant à chaque incrément de temps dt son altitude h afin de calculer sa vitesse v = sqrt (vr2 - 2gh), donc l'incrément de position ds = v*dt, et donc sa nouvelle position s2 = s1 + ds.
Par contre, si le terrain disparaît au cours de la trajectoire (tramplin, etc.), il ne faut plus suivre le terrain mais passer en mode 'chute libre parabolique' pendant lequel on a toujours la constance de vr2.
La difficulté, c'est de déterminer précisement et facilement quand est-ce que l'on passe d'un mode à l'autre ...
Le critère du passage en chute libre, c'est lorsque l'on voit qu'il faudrait une force Fn dirigée vers le terrain (Fn < 0) pour garder la somme vectorielle Fg + Fc + Fp tangente au terrain, et dans ce cas on pose Fn=0 et Sonic décolle.
Mais ceci oblige à calculer à tout moment les forces qui varient, donc on perd tout l'intérêt de l'utilisation de vr2 (en fait, on l'utilise uniquement si le mobile reste mécaniquement sur un terrain capable de fournir Fn < 0, comme par exemple un chariot de grand-huit sur ses rails).
Pour la force de propulsion Fp, outre la composante horizontale (croix directionnelle) qui, projetée sur la tangente du terrain, exerce un travail et donc modifie vr2, j'avais oublié le bouton de saut qui donne une composante normale au terrain (donc le travail est nul, donc vr2 reste constant) plus grande que Fn (donc Sonic décolle et décrit une parabole).
Enfin, concernant l'efficacité de l'utilisation des forces, c'est la solution la plus efficace en terme de réalisme du moteur physique, c'est même la seule qui soit physiquement exacte dans le cadre de la mécanique newtonienne (et facilement implémentable ... si tu as quelques années à perdre, tu peux toujours implémenter les équations de la relativité générale pour être physiquement exact dans le cadre de cette mécanique
) ...
Quant à l'efficacité algorithmique (temps de calcul), je ne trouve pas que ce soit bien lourd, il suffit de faire des produits avec les sinus et cosinus de l'angle de la pente du terrain pour se ramener dans le référentiel (O;x;y) de l'écran, et de faire ensuite des sommes selon les composantes x et y ...
Tu peux même faire ça en une seule fois avec une matrice de rotation (l'angle utilisé étant celui de la pente du terrain).
Ainsi, une méthode à la fois subtile et barbare (ça c'est tout moi
) pour pouvoir utiliser facilement n'importe quelle forme de terrain est de représenter chaque tile par une matrice de la taille du sprite et dont chaque élément coïncidant avec la surface contient l'angle de la pente en radians.
Je suppose que tu utilise déjà ce type de matrice, laquelle ne contient que des 0 ou des 1 (air ou terre) : dans ce cas, il suffit de faire une matrice de complexes, avec l'angle comme partie réelle et la valeur 0 ou 1 comme partie imaginaire.
Avec ça, la gestion de la trajectoire (position + vitesse, évidemment) sur un terrain tordu ou un looping se fait les doigts dans le nez
!
En plus, comme le centre du tile de Sonic doit être à une distance fixe (sauf quand il se baisse ou qu'il saute) de la surface, et que cette distance se mesure selon la normale au terrain, le calcul de la position de ce centre est alors immédiat, sans risquer de voir Sonic s'enfoncer sous terre.
@++