Mouvement plateforme custom basé sur le timer

[Olivier]

Je n'ai pas réussi à faire fonctionner ta solution dampat. Pour ma part j'ai utilisé cette condition afin de stopper complètement l'objet lorsque qu'il n'y a plus d'accélération horizontale:
<div class="ubbcode-block"><div class="ubbcode-header">Code:</div><div class="ubbcode-body ubbcode-pre" ><pre>Abs(VelocityX( &quot;Active 6&quot; )) &gt; 0</pre></div></div>

Concernant la distance de freinage/accélération il est certain que la différence entre différents FPS est relativement négligeable (quelques pixels). Mais ça m'intrigue cependant, car le calcul me semble être identique à celui de l'axe Y.
Si c'est bien le passage par zéro qui pose problème, qu'est-ce qui peut être fait?

Je poste l'exemple en version 0.2. J'ai appliqué les modifs suggérées jusqu'à présent, et fais quelques changements qui je l'espère sont pertinents. Les explications sont dans les commentaires du code et dans le log intégré au MFA. J'espère que ce sera assez clair:
http://www.clickteam.com/epicentre/ubbth...e=CTBPMv0.2.mfa

[dampat]

J'ai regardé ton fichier, ça m'a l'air très bien. Pour l'erreur qu'il reste, il y a la solution qui est pour moi la plus évidente: ce serait de calculer la position exacte d'arrivée à partir de la vitesse initiale et position initiale avant décélération puis forcer par min ou max la valeur lorsque la vitesse s'annule. On aurait alors la position vraie au final pour tous les cas de framerate. Cette méthode pourrait même permettre d'utiliser uniquement une relation de la position en fonction du temps et virer les relations de vitesse.
Pour ce qui est de la différence entre le Y et le X, je ne sais pas encore. Toute la difficulté est de récupérer l'erreur de position sur X entre 2 mouvements identiques à framerates différents. Comment fais-tu pour déterminer cette erreur ?

[Olivier]

Voilà j'ai re-posté la v0.2 en ajoutant un groupe de code Debug et deux objets. En gros je désactive le contrôle joueur lorsque l'objet est au-dessus d'une certaine zone. Ça déclenche le freinage. Et la valeur PosX de l'objet est affichée pour une meilleure comparaison.
J'obtiens une différence de quelques pixels (de 1 à 4 environ) entre différents FrameRates. Mais le comportement n'est pas identique en allant vers la gauche qu'en allant vers la droite.

Question: le calcul en ligne 36 est-il exact dans tous les cas? Car parfois AccelerationX est positif, parfois négatif. Le signe '-' ne doit-il pas se transformer en '+' si AccelerationX est négatif?
<div class="ubbcode-block"><div class="ubbcode-header">Code:</div><div class="ubbcode-body ubbcode-pre" ><pre>PosX( &quot;Active 6&quot; )+(VelocityX( &quot;Active 6&quot; )*TimeDelta)-(AccelerationX( &quot;Active 6&quot; )/2*TimeDelta pow 2)</pre></div></div>

Le truc c'est qu'il y a une différence majeure entre l'axe X et l'axe Y. Je crois que tu l'as souligné Damien.
Sur l'axe Y il y a en permanence une accélération vers le bas, la gravité. Et pour sauter on modifie bruquement VelocityY avec une valeur négative. C'est comme si on appliquait ponctuellement une force (contraire à la gravité).
Sur l'axe X on a parfois, et seulement parfois, une accélération (positive = accélération, négative = décélération). Et parfois on a rien du tout.
Je me demande si il ne faudrait pas traiter l'axe X comme l'axe Y. On aurait en permanence une décélération, on pourrait considérer que c'est la friction avec l'air ou l'inertie. Et pour accélérer on appliquerait une force contraire.

Je ne sais pas si j'emploie les bons termes. La notion exacte de Force et d'Inertie, telle qu'elle est traitée en physique m'échappe encore. Mais je m'instruis:
http://en.wikipedia.org/wiki/Equation_of_motion
http://en.wikipedia.org/wiki/Force

[dampat]

Changer le mode de fonctionnement de la vitesse en X ne changera rien. L'erreur vient de l'échantillonnage de notre fonction. Pour avoir une erreur moindre il faut avoir une accélération/vitesse initiale multiple du temps entre chaque frame. Par exemple, pour l'axe y, le passage en zéro se fait à 450/1100=0,409s ce qu est très proche de 4*0,1 (0,1=1/framerate). Pour y le passage en zéro se fait à 600/200=0,333, ici beaucoup plus éloigné d'un multiple du framerate. Si on prend decelx=400 à la place de 600, l'erreur est quasiment nulle.
La seule solution est de considérer comme je le disais la valeur vraie au passsage en zéro pour annuler totalement cette erreur.