squalyl (./1745) :
il s'exprime mal, c'est pas fixed timestep sinon le jeu rame selon la vitesse cpu.

Absolument pas, c'est bien du fixed timestep qu'il faut. Et ça ne fait pas ramer le jeu "selon la vitesse du CPU"

mais gaffe dès que le timestep devient trop grand, on peut faire diverger les intégrales du mouvement.

Tout à fait. C'est une des raisons pour laquelle le variable timestep c'est mal.
Mais comme le dit monsieur le maki-to-be, si tu fais très bien tes calculs (en fait dans un jeu c'est impossible à cause des entrées utilisateur), alors ça ne devrait pas non plus arriver
Sauf que de tels calculs sont extrêmement couteux, et peu rentables par rapport à une bête approximation type Euler avec un pas fixe

Donc voilà le graphique:
C'est une fonction assez simple, et voilà ce que ça donne en 100 itérations. (Mais la courbe est tracée par rapport au temps vu que c'est ce qui nous intéresse)
En gros, la courbe bleue est totalement indépendante du temps. (Fonction réelle)
La courbe rouge est une approximation de Euler à intervalle fixe. (La méthode du fixed timestep)
La courbe verte est une approximation de Euler avec un intervalle « en moyenne » constant. (La méthode du variable timestep dans le cas standard et plus ou moins optimal)
La courbe violette est toujours la même approximation de Euler, dans le cas où l'intervalle précédent subit des variations plus ou moins imprévisibles. (La méthode du variable timestep sur un PC moins bon ou un peu chargé)

La courbe bleue: Si tu arrives à implémenter ça dans tous les cas (même quand tu as plus qu'une simple gravité) avec un timestep variable, le résultat sera assez bon, et relativement indépendant de la machine. Mais à chaque image, les calculs doivent être refaits à partir de t=0 afin de ne pas accumuler d'erreurs non prévisibles.
La courbe rouge: Quelle que soit la machine et la configuration, les résultats seront constants. Pas totalement corrects numériquement, mais malgré tout très proche (il faut quand même prendre un intervalle assez petit. Au moins 1/60 pour PC.)
La courbe verte: Les écarts ici ne sont pas suffisamment grands pour trop influencer la courbe. Les petites approximations (erreur plus faible) viennent compenser les plus grosses approximations (erreur plus élevée).
La courbe violette: Ce qui se passe quand ça marche moins bien qu'avec la courbe verte.

En fait le fixed timestep est totalement prévisible. (Et l'erreur aussi est prévisible du coup)
Cela te permet d'utiliser des approximations de manière fiable.
Ça va donner *exactement* les mêmes résultats (numériques) sur toutes les machines.
Ça peut te permettre de faire des évènements scriptés qui vont jouer exactement pareil partout. (Tu peux donc aussi facilement faire des replay… PS: imagines toi rejouer un replay enregistré à 45FPS en moyenne sur une machine à 57FPS en moyenne)
Ça peut aider à la synchronisation pour le jeu en réseau. (Enfin là c'est une science complexe, donc bon…)
Si tu conçois bien ton jeu, il est impossible que tu rates une collision avec un fixed timestep. (Y'a des vitesses maximales à respecter, totalement dépendantes de l'intervalle que tu auras choisi… C'est mathématique ! )

En fait, les intervalles variables sont très bien uniquement si tu peux garantir que l'exécution de la trame n ne dépend en aucun cas de l'exécution des trames précédentes. Dans ce cas là ils n'ont aucun défaut et que des avantages.
Les approximations type Euler se basent toujours sur des résultats (approximations) intermédiaires calculé à la trame précédente… Ce qui est un énorme défaut avec les intervalles variables.

(Bon, c'est plus complexe, mais il y a aussi la possibilité de faire des modèles hybrides. Par exemple quand tu fais tourner ton moteur physique à 30 FPS, et que ton écran rafraîchit entre 60 et 85 FPS… En général tu aimerais bien que le jeu en profite.)