Animation time-based... - Page 1

Hello!
Je suis en train d'essayer de faire un jeu de plate-forme en time-based, plutôt qu'à mon habitude en frame-based. Et je rencontre des difficultés, par exemple pour la physique, avant j'avais simplement une vitesse, affectée par l'accélération, puis juste après la position était affectée par la vitesse. Ca donnait 2 additions, c'était super simple, mais là ça ne fonctionne pas (si le temps entre les frames est très grand). Alors j'ai fait autrement en me rappelant tant bien que mal des cours de physique:

# Membres: ax, ay (accélérations), vx, vy (vitesses), onGround
# On les conserve entre les frames.
function collisionEngine(t: number):
    # Ces nombres représentent le déplacement à faire pour cette "frame"
    dx, dy: numbers

    # Note: t est le temps écoulé depuis le dernier appel
    dx = 1 / 2 * ax * t ^ 2 + vx * t
    # Pareil en y
    dy = 1 / 2 * ay * t ^ 2 + vy * t

    # Modification de l'accélération ici
    if keyboard: held(Left):
        ax = 240
    else if keyboard: held(Right):
        ax = -240
    else:
        ax = 0

    # Gestion du saut
    # Et c'est là que ça blesse...
    # Pour moi ça me semble logique de faire ça ici, mais en fait non,
    # il n'y a que si je le fais en haut (avant de calculer dx/dy) que ça
    # marche correctement...
    # Actuellement en fait le saut est plus faible si t est grand
    if keyboard: pressed(Up) and onGround:
        vy = -300

    # La vitesse a besoin d'évoluer au cours du temps
    vx = vx + ax * t
    vy = vy + ay * t

    # Ca aussi, est-ce que c'est bien de le faire là?
    # "Ralentissement" du perso dû au "frottement"
    vx = vx * 0.95

    deplaceLePersoXY(dx, dy)

Bref je comprends bien que là je fous un peu la merde en modifiant aussi les vitesses, alors que normalement je ne devrais travailler qu'avec le niveau supérieur (accélération), sauf que ça me semble trop dur (dans le cas d'un saut il faudrait que je calcule l'accélération nécessaire pour passer de "vy actuel" à 300, et ce serait compliqué et lent en plus)

Des idées pour faire une bonne physique en time-based? (et pas forcément trop complexe vu que c'est pour du jeu )

En ce qui concerne le pb de vitesse: tu travail en virgule fixe j'imagine; peut être que c'est un problème d'arrondi? [edit: ah ouai, de la virgule fixe avec vx * .95 . bon je ne sais pas.]

En ce qui concerne le ralentissement:
Le "ralentissement" résulte du travail d'une force. Exactement comme pour la force de gravité, en "time based" tu dois gérer les frottements différement. Ça va être plus compliqué que la gravité, parceque le ralentissement n'est pas constant (il dépend de la vitesse).
Je crois que tu va devoir résoudre une équation différentiel pour trouver la nouvelle expression de dx(t)
Si tu ne vois pas ce que je veux dire, (et en supposant que je n'ai pas raconté de bétises,) je peux dévelloper (ça me fera réviser).

En fait, le problème du "time-based" c'est tout ce qui se passe dès lors que tu programmes sur une plateforme "non unique" (au hasard un PC).
pour avoir déjà été confronté au problème, tu peux effectivement résoudre des équations comme le suggère Jyaif (en fait c'est ce que j'aurai fait il y a pas si longtemps que ça) mais le problème c'est que ce n'est pas vraiment dynamique:
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'. Donc c'est même au delà d'une équation différentielle, car il faut arriver a recoller les bouts, et à priori sur deux pc différents tu pourrais avoir pour une scène programmée (mais pas précalculée ) qui donnerait un résultat totalement différent (théorie du chaos si je ne dis pas de bêtises ?) à cause de petites imprécisions de temps qui s'accumulent. (Bon après je suis pas expert mais voilà)

La façon dont je vois les choses c'est de fonctionner exactement sur le même modèle que les "frame", mais là où dans le cas "frame based" tu basait ton timing sur les "frame", tu feras l'inverse.
En gros tu découpe ton temps en intervalles de durée T (donc fréquence 1/T ) fixe, et tu fonctionne... ben comme la méthode d'Euler quoi
Je donne le pseudo-code C car sinon j'y arriverais pas sans faire un pâte pas beau

/* 120 Hz */
#define f 120d
/* f = 1 / T <=> t = 1 / f */
#define T (1d / f)

float Update(float delta);
void Render();

int main()
{
	long oldTime, newTime;
	double xTime = 0; /* Parce que sur x86 les float ça sert a rien :p */

	Initialiser();

	oldTime = GetTickCount(); /* Je prend un timer de référence (en millisecondes) */

	while true
	{
		newTime = GetTickCount();

		xTime = Update(xTime + (newTime - oldTime) / 1000d);

		Render();
		
		oldTime = newTime();
	}
}

double Update(double delta)
{
	while (delta > T)
	{
		delta -= T;
		
		/* Faire les calculs sur une durée écoulée T */
		
	}

	/* Il reste du temps non utilisé, on s'en servira la fois prochaine */
	return delta;
}

void Render()
{
	/* Dessiner ce qu'il faut ici */
}

Enfin bon c'est comme ça que je vois les choses. Plus tu prend T petit plus tu augmentes la précision et la quantité de calculs. Mais les calculs restent bien plus simples qu'avec des intégrales "exactes", donc ça devrait être plus efficace si tu sait choisir le bon T.

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>).

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!

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.

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.

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

Effectivement comme dit GoldenCrystal si tu veux du déterminisme tu es obligé de calculer en découpant en morceaux de taille fixe (= frame-based) plutôt qu'en morceaux de taille arbitraire. Donc ça dépend si tu as un besoin impératif d'être synchronisé entre différents clients...

Pour ./1 :
- pour la partie parabolique de la trajectoire tu sépares la mise à jour de dx et de vx, ça pose forcément des problèmes ; il faut que tu les mettes ensemble et que l'effet du clavier vienne soit avant soit après (tu utilises onGround, qui ne sera je suppose valable qu'au début donc il vaut mieux mettre ça avant ; et puis si tu le mettais après, le clavier serait toujours pris en compte un frame trop tard)
- vx = vx*0.95 ça ne peut pas marcher, c'est du frame-based : calcule ce qui se passe en frame-based, ça donne vx = vx*0.95^n pour n frames, donc on convertit ça en temps continu et ça donne vx *= exp(-0.05*t)
- modifier directement vy c'est pas un problème, ça correspond à un choc instantané

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>).

Un mario ça doit pas être très chaotique, et de toute façon sauf options de compilation spéciales un même compilo donnera un code parfaitement déterministe pour tous les CPU x86...

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!

Non, si tu compiles en mode IEEE avec une précision donnée c'est parfaitement spécifié et le fait de cumuler des erreurs d'arrondis ne change pas le déterminisme. Par contre, si tu fais pas exactement le même calcul (intervalle de temps variable) tout fout le camp...

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.

Si les règles sont assez chaotiques ça influencera forcément le déroulement du jeu, donc il faut faire ce qu'il faut pour que les calculs donnent pile le même résultat ^^
(sinon tu peux aussi te synchroniser régulièrement à un serveur, en priant pour que les petites différences n'aient pas d'influence sur les décisions que prendra le joueur)

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

En fait ta solution GC ça revient à faire du frame based avec du frameskipping, non? En fait j'ai pas envie de ça, puisqu'il me faut choisir un temps T de base et je ne sais pas lequel prendre puisque ça dépend de la fréquence de l'écran (si je prends 60 et que qqn est en 75 ça va saccader, 50 pareil, etc.). Je ne vais pas faire un jeu en réseau, en fait c'est pour du téléphone portable, et comme les framerates sont très variables dans ce domaine, ça me semble une bonne application pour tester le time-based (c'est un choix)
En fait je veux juste éviter que si je définis que mon perso peut sauter de 5 blocs il en fasse 6 (triche) ou 4 (jeu impossible) selon le téléphone quoi...

GoldenCrystal (./6) :
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.

Il ne le fera pas aussi bien tourner, vu qu'il faudra un nombre impressionnant d'itérations de la boucle pour rattraper le retard, et exécuter 120 fois les calculs est probablement plus lourd que de ne faire qu'une seul fois de plus gros calculs comme ici. Et puis au bout d'un moment le temps entre les frames risque de tendre vers l'infini (imaginons: une frame a pris 100 ms: tu vas ensuite effectuer la boucle 15 fois pour rattraper le retard, mais ça prendra 200 ms, donc tu vas exécuter 30 fois la boucle, ça prendra 350 ms, alors la prochaine fois tu l'exécuteras 50 fois, etc.)

Pollux (./5) :
- vx = vx*0.95 ça ne peut pas marcher, c'est du frame-based : calcule ce qui se passe en frame-based, ça donne vx = vx*0.95^n pour n frames, donc on convertit ça en temps continu et ça donne vx *= exp(-0.05*t)
- modifier directement vy c'est pas un problème, ça correspond à un choc instantané

Eh bien.... je serais très intéressé de savoir comment tu as fait cette transformation, mais en cherchant un peu j'ai peur qu'il me manque des bases, je ne connais pas les équations différentielles (mais les dérivées & intégrales qd même, je crois que c'est une base).
De plus, quand devrais-je effectuer cela? Actuellement j'ai:

Modification de ax / ay en fonction des touches
Modification brutale de vy en cas de saut (appui sur la touche)

Calcul du dx, dy (déplacement)
Modification juste après de vx, vy en fonction de l'accélération

Exécution du moteur de collisions

Je pense le faire avec la partie gestion des touches, mais d'un côté pourquoi elle ne pourrait pas aussi être appliquée juste après la modification de la vitesse par l'accélération?
Ce qui me semble bizarre c'est que je ne trouve rien sur le sujet de l'animation time-based sur le net, je dois pas m'y prendre correctement...
Tu as des tutos ou une bonne explication sur le sujet?
En fait est-ce que le time-based, c'est bien ce dont je parle là, ou c'est plutôt ce dont parle GoldenCrystal? Parce qu'on dirait que le frame-based n'inclut normalement pas de frameskipping (comme c'est systématiquement le cas pour moi).

Merci bcp en tous cas ^^

Brunni (./7) :
Eh bien.... je serais très intéressé de savoir comment tu as fait cette transformation

vx = vx+dvx avec dvx = - vx*0.05

tu pars de l'équation dvx = -vx*0.05
dvx/vx = -0.05
integrale dvx/vx sur t = intégrale -0.05 sur t
ln(vx) = Constante + t* -0.05
vx = exp(-0.05*t)+autreConstante

Sinon, est-ce que c'est plus difficile de rendre un jeu time-based scriptable qu'un jeu frame-based?
par exemple pour externaliser les comportement des ennemies etc dans un fichier script. si oui, en quoi c'est plus difficile?

./5 et ./6 > Ok j'ai compris mon erreur

./8 > Ce n'est pas plus dur de rendre scriptable un jeu time-based. Ce qui risque de devenir plus dur, c'est de faire les scripts, car ils doivent être capable de donner x(t) et y(t). Imagine faire ça pour une balle qui rebondie...

Brunni (./7) :
Eh bien.... je serais très intéressé de savoir comment tu as fait cette transformation, mais en cherchant un peu j'ai peur qu'il me manque des bases, je ne connais pas les équations différentielles (mais les dérivées & intégrales qd même, je crois que c'est une base).

Il y a la solution avec des équa diff comme l'a fait onur, mais tu peux simplement regarder ce qui passe en frame-based :
vx = vx0
vx = 0.95*vx0
vx = 0.95^2*vx0
...
vx = 0.95^n*vx0

=> pour t quelconque vx = 0.95^t*vx0, et c'est plus joli/rapide d'utiliser une exponentielle au lieu d'une puissance donc vx = exp(log(0.95)*t)*vx0 = environ exp(-0.05*t)

De plus, quand devrais-je effectuer cela? Actuellement j'ai:
...Je pense le faire avec la partie gestion des touches, mais d'un côté pourquoi elle ne pourrait pas aussi être appliquée juste après la modification de la vitesse par l'accélération?

En fait là pour le coup une modification directe de vx n'est pas appropriée puisque c'est pas un choc brusque : il vaut mieux écrire ax -= (1-exp(-0.05*t))/t*vx, ou tout simplement ax -= 0.05*vx si tu comptes pas utiliser des valeurs de t gigantesques.

Ce qui me semble bizarre c'est que je ne trouve rien sur le sujet de l'animation time-based sur le net, je dois pas m'y prendre correctement...
Tu as des tutos ou une bonne explication sur le sujet?
En fait est-ce que le time-based, c'est bien ce dont je parle là, ou c'est plutôt ce dont parle GoldenCrystal? Parce qu'on dirait que le frame-based n'inclut normalement pas de frameskipping (comme c'est systématiquement le cas pour moi).

Je crois qu'en fait time-based ça veut juste dire que les objets bougeront à la même vitesse quel que soit le framerate, donc c'est valable pour ta méthode comme pour celle de GC. La méthode de GC est globalement plus fiable et plus répétable, mais la tienne est moins gourmande...

Pollux (./10) :
=> pour t quelconque vx = 0.95^t*vx0, et c'est plus joli/rapide d'utiliser une exponentielle au lieu d'une puissance donc vx = exp(log(0.95)*t)*vx0 = environ exp(-0.05*t)

Oh merci ^^ Dans le train j'ai pris ma TI et j'en suis aussi arrivé à la conclusion que 0.95^t fonctionnait bien, mais je ne comprenais pas d'où tu sortais l'exponentielle Par contre je savais pas que c'était plus rapide de faire une exp, j'ai pas encore testé mais j'ai peur que ce soit bcp trop demandé à un téléphone ARM de faire ça :/

Pollux (./10) :
Je crois qu'en fait time-based ça veut juste dire que les objets bougeront à la même vitesse quel que soit le framerate, donc c'est valable pour ta méthode comme pour celle de GC. La méthode de GC est globalement plus fiable et plus répétable, mais la tienne est moins gourmande...

En fait j'en suis même pas sûr, parce que faire ça en frame-based c'est 2 bêtes additions et une multiplication, alors qu'en time-based on obtient des formules énormes et complexes (exposants réels justement...)
C'est marrant, je pensais que tous les jeux "3D" utilisaient le time-based au sens où j'en parle dans ce topic, car même si tu prends un vieux jeu comme Half Life, il tourne super fluide en 100 Hz comme en 120 Hz, et certains reportent y avoir joué à des fréquences plus élevées. Ce n'est pas possible en frame-based, à moins d'avoir choisi un frame time de genre 600^-1...

Par contre je me demande quand même comment je peux faire par exemple pour trouver une formule de x(t) / y(t) avec des éléments plus complexes. Par exemple, comment peut-on trouver 1/2at^2+v0t+x0? Ca me semble une double intégrale de a (logique), ensuite on doit ajouter une constante, et cette constante c'est la vitesse (pourquoi?), qu'on intègre une fois, à laquelle va s'ajouter x, qu'on n'intègre 0 fois.

Ben, c'est simple: x(t) est la position, v(t)=x'(t) est la vitesse, a(t)=v'(t)=x"(t) est l'accélération.

Si tu as une accélération constante a, pour trouver x, tu résous l'équation différentielle x"(t)=a. v0 dénote la vitesse de départ et x0 la position de départ, donc par leur définition-même, tu as les conditions initiales x(0)=x0 et x'(0)=v0. La solution de cette équation différentielle sous ces conditions de départ est x(t)=½at²+v0t+x0. Et tu peux en déduire que v(t)=x'(t)=at+v0 et évidemment a(t)=x"(t)=a (donc c'est bien une solution de l'équation différentielle).

Dans une situation plus complexe, tu peux te retrouver avec une équation différentielle plus complexe.

(Désolé pour les puristes physiciens, mais j'utilise les primes plutôt que les points pour rester en Latin1. )

Brunni (./11) :
C'est marrant, je pensais que tous les jeux "3D" utilisaient le time-based au sens où j'en parle dans ce topic, car même si tu prends un vieux jeu comme Half Life, il tourne super fluide en 100 Hz comme en 120 Hz, et certains reportent y avoir joué à des fréquences plus élevées. Ce n'est pas possible en frame-based, à moins d'avoir choisi un frame time de genre 600^-1...

À mon avis, le moteur doit interpoler les positions.

La méthode donnée par GC présente également l'avantage d'être très facile à optimiser pour un système multicore, puisque l'évolution du monde et l'affichage sont totalement séparés.
(L'intervalle de temps utilisé peut être déterminé dynamiquement en fonction du système et du nombre d'objets à gérer).

Brunni> ben généralement même en frame-based, dès lors que le framerate n'est pas garanti, il est fréquent de chronométrer le temps passé depuis la dernière frame et de l'utiliser comme base de temps. C'est même obligatoire, sinon ça te donnera ce que font les vieux jeux réellement frame-based : "start...game over".

Quelles sont les techniques utilisées actuellement dans les jeux vidéos ? J'en suis resté à l'époque Quake 3, qui il me semble fonctionne en frame-based (encore que je n'ai jamais lu le code pour vérifier), et les erreurs d'approximation avec cette méthode sont souvent négligeable (je n'ai jamais eu l'impression d'avoir des résultats différents en fonction des machines ; ils l'étaient certainement, mais pas assez pour que ce soit visible à l'oeil nu).

À l'inverse, la méthode de GoldenCrystal est plus fiable mais borne les FPS max, ce que je trouve quand même assez gênant (120 c'est une limite correcte, certes, mais ça reste une limite).

[edit] à la relecture j'ai un doute sur le vocabulaire... frame-based, c'est bien ce que décrit spectras au ./14, c'est à dire utiliser le nbr de frames écoulées ou le temps écoulé depuis la/les dernière(s) frame(s) pour obtenir le coef à appliquer ?

je crois que chaque personne qui a posté dans le topic a une définition différente

Si j'ai bien compris :
frame-based = fonction d'évolution entre deux frames qui ne dépend pas du temps (mais on peut limiter les fps pour éviter l'écueil de spectras -- typiquement c'est adapté au cas où sur 90% des configs cette limite sera toujours atteinte)
time-based = fonction d'évolution qui dépend du temps, et qui peut soit utiliser une fonction d'évolution discrète/small-step/"frame"-based à une fréquence supérieure à l'écran (méthode de GC), soit utiliser une fonction d'évolution continue/big-step qui n'a pas de fréquence prédéfinie (méthode de Brunni)

Alors la méthode de GC pour moi c'est du frame-based - comme les vieux jeux, mais avec gestion du frameskipping (comme les émulateurs de nos jours quoi).
En gros le jeu est prévu, mettons pour 120 fps, donc chaque frame = un 120ème de seconde, quelle que soit la config. Rien ne garantit en revanche que toutes les 120 frames seront affichées, l'affichage n'étant effectué que si "on n'est pas en retard" car il est très coûteux.
La méthode que j'essayais d'utiliser au début de ce topic c'est du time-based: quel que soit le temps entre deux frames (énorme ou minuscule), on peut gérer la physique pour ce delta. Et c'est beaucoup plus compliqué, en plus d'introduire éventuellement des imprécisions (faire 100 fois les calculs pour un delta de 0.01 seconde ne donnera pas forcément le même résultat que faire 1 fois le calcul pour un delta de 1.00 seconde).

, pour moi aussi la méthode de GC c'est du frame-based.

Non les deux sont du time-based, sauf que l'une est basée sur un intervalle de temps fixe, tandis que l'autre est basée sur un intervalle de temps variable.
Le frame-based c'est quand tu utilise une frame comme unité de temps, dans la plupart des cas en te synchronisant sur le rafraîchissement de l'écran, mais tu n'as pas de contrôle réel sur l"intervalle de temps réel écoulé, tu as juste défini que ton intervalle durait X avec X inconnu mais X constant.
Le time based c'est quand tu utilises le temps réel comme unité de temps dans le jeu, peu importe que ton intervalle soit fixe ou pas, tu as défini que ton intervalle durait X, et X est toujours connu, mais il peut être constant ou variable selon la méthode employée.

Disons pour faire simple: le frame-based, c'est X constant, et le time-based c'est X connu.
Alors ce que je propose est une sorte d'hybride entre les deux mais ça n'en reste pas moins du time-based

C'est ta définition ça. Avec une telle définition, la méthode "j'affiche une frame, j'attend que 20 ms se soient écoulées depuis la dernière frame" est classée comme étant du "time-based".

D'après Google, les gens qui utilisent le terme "time-based" sont plus d'accord avec la définition de Brunni.

Je propose ça comme définition:
Frame based: calculs en discret.
Time based (inutilisable pour des jeux): calculs en continu.

Non car une frame n'est pas une mesure de temps fiable sur la majorité des supports. Une frame c'est une unité de synchronisation matérielle, rien de plus.
Sur console portable tu pourra utiliser cette unité de synchronisation sans problème (habituellement ~60Hz), et sur console de salon c'est déjà moins le cas (en fait ça dépend des consoles, et du standard TV utilisé, 50 Hz/60 Hz).
Pour pratiquement tout le reste une frame ça ne signifie rien. Sur PC par exemple tu peux ou non activer le VSync, tu peux ou non modifier la fréquence d'affichage.
En gros le temps de frame est à priori inconnu et variable, c'est a dire totalement chaotique.

Je ne sais pas si tu saisis bien la différence entre la synchronisation par le matériel (tu ne contrôles pas entièrement, voire pas du tout le temps écoulé) et une synchronisation par l'horloge (tu contrôles parfaitement le temps écoulé, que ton intervalle soit constant ou non), mais c'est pourtant la seule vraie différence entre frame- et time- based

(En réponse à ./20 bien sur )

"j'affiche une frame, j'attend que 20 ms se soient écoulées depuis la dernière frame"
<=>

while (1) {
previousTime=getTime();
afficheFrame();
while(getTime()-previousTime<20);
}

Et ça, ça utilise "le temps réel comme unité de temps dans le jeu". C'est donc du time based d'après ta def.

./22 > Je crois que tu confonds la fréquence du téléviseur/moniteur et le fps. C'est pas parce que tu es en 50Hz, que tu as affiché 50 images "différentes".

Jyaif (./20) :
D'après Google, les gens qui utilisent le terme "time-based" sont plus d'accord avec la définition de Brunni.

Euh on doit pas avoir le même Google
http://www.sacredsoftware.net/tutorials/Animation/TimeBasedAnimation.xhtml
http://www.jmckell.com/timebased.html
etc...

dans ton premier lien il y a:
object.position += (3.0 * interval);

(il exprime dPosition(dt))

et ? lis la page, tu verras que ça correspond à ./16

ok, vous avez raison (2e lien de pollux)

(le premier lien aussi, si tu avais remarqué qu'il y a plusieurs paragraphes )

ya trop de texte dans le 1er.