Jyaif (./4) :
Première remarque qui n'a pas trop d'importances: je n'ai jamais expérimenté de différences de résultats après des tonnes de calculs flottant sur différents x86. (j'ai fais un jeu avec flottants qui rejoue des parties à partir de touches appuyées, et les résultats sont toujours les mêmes... <pub> http://code.google.com/p/killmario/downloads/list </pub>).

Tout dépend de comment tu fais tes calculs, mais tu auras forcément a un moment donné une imprécision qui dépend de la mesure du temps sur la machine. Par exemple si tu prend tes mesures sur un PC 'rapide' (enfin normal) puis que tu rejoues sur un PC extrêmement lent, est-ce que tu as la garantie que la courbe de ta parabole va bien se finir au même endroit et que ton personnage ne vas pas atterrir 3km plus loin après un saut ?
En fait la discrétisation du temps a aussi un autre intérêt (je viens à l'instant de m'en rapeller) c'est que tu peux faire une détection de collision "progressive"

Si jamais il y a effectivement des différences de résultat, le fait de découper les intervalles en pleins de sous trames augmente considérablement le nombre de calculs effectués. Comme chaque calcul provoque potentiellement une erreur, le résultat est encore plus chaotique!

Au contraire, plus tu découpes le temps, moins tu fait d'erreurs par rapport à la réalité. (enfin à supposer que tu utilise un bon timer pour tes mesures de temps... Par exemple GetTickCount() de mon exemple est loin d'être le meilleur: il n'a une précision que de 5ms)
En fait le tout est de prendre un intervalle de temps suffisamment petit pour qu'il y ait au moins 1 calcul par frame affichée (donc fréquence minimum de 2*x pour x étant le fps maximum... Prend par exemple x=120 fps pour un PC) et suffisamment grand pour que tes calculs soient significatifs (car évidemment la précision des double a une limite )
Enfin quoi qu'il en soit ce n'est en aucun cas chaotique, c'est justement complètement déterministe, et tu as la garantie qu'avec les mêmes entrées d'évènement (clavier, souris, nombres aléatoires, ...) tu auras toujours exactement les mêmes résultats, même si le PC est un 386 à 10 MHz qui ne fait tourner le jeu qu'à 1 fps.

Et de toute façon, à partir du moment où les calculs ne donnent pas des résultat identiques, il faut qu'il se débrouille pour que ça n'influence pas le déroulement du jeu.

J'espère bien

Tu appliques des formules physiques qui contiennent des approximations, ce qui te donne une formule, qui n'est valable qu'à un moment donné (hé oui) et qu'il faudrait changer 'en temps réel'.

Je ne comprend pas.

C'est assez simple à comprendre: Pars déjà du principe que les formules de mécanique sont des approximations (par exemple p=m.g avec g constant: g n'est pas constant !)
Imagine que tu fasse une simulation d'un système solaire contenant 1 million d'objets (oui c'est assez colossal). Tu sais qu'au delà d'une certaine distance les lois d'attraction gravitationnelle sont négligeables, donc tu ne calcules les forces qu'entre des objets proches (il vaut mieux car sinon tu prendrais bien trop de temps à tout calculer). Seulement les objets sont en mouvement, donc les objets qui influencent le calcul des forces pour un objet donné vont changer "avec le temps", ce qui donnera un résultat chaotique si ton intervalle de temps n'est pas déterministe

Remarque: la technique de GoldenCrystal revient tout simplement à sauter l'affichage d'un nombre variable de frames ^^

On peut voir ça comme ça, on peut aussi voir ça comme le fait que ce que je propose est une méthode d'approximation numérique, et que la méthode basée sur des frames revient exactement au même sauf que tu approxime des intervalles de temps variables (entre deux frames rien ne te garantit que le temps soit le même) à des intervalles de temps fixes