Discussion :

[KeN1985]

Bonjour à tous,

j'aurais voulu savoir comment fait pour fair varier la vitesse d'une animation en fonction du FPS, de manère précise et efficace (et surtout portable). Il y a deja des postes et des sites qui traitent de ca mais je ne trouve pas ça très clair.

je vous resitue dans le contexte : j'ai une liste contenant des objets, et chacun d'entre-eux correspond à une petit cercle à l'écran. J'utilise un déplacement fixe (par ex 0.05). Si la liste contient quelques centaines d'éléments, ca va, la vitesse des entités à l'ecran me convient, mais si il ne reste plus que 2 ou 3 éléments, ceux-ci vont tellement vite qu'on les voit à peine :p
C'est logique puisque avec une petite liste, on va passer beaucoup plus de fois dans la fonction d'affichage.

Moi ce que je voudrais c'est que la vitesse varie en fonction du fps pour que celle-ci reste constante malgré la puissance de la machine ou la taille de ma liste. Il faut absolument que ce soit portable ! Perso j'utilise Glut, peut-être peut on le faire avec ?

Merci d'avance de vos explication.

[shenron666]

Salut,

Tu utilises une bibliothèque de fenêtrage pour conserver un code portable ?
genre SDL ou GLUT ?

auquels cas tu as une fonction d'accès à un timer :
SDL_GetTicks() dans le cas de SDL
je ne sais plus laquelle sous glut

cette fonction te retourne un temps écoulé en millisecondes
si tu récupères cette avleur entre chaque image tu connais le temps qui s'est écoulé et tu te sert de cette donnée pour déplacer ton objet
par exemple : déplacement = vitesse * temps

[KeN1985]

ah c'est gentil

jvais essayer comme ca

merci !

[bafman]

en fait tu a 2 ecoles qui s'"opposent" sur ce sujet.
tu a la methode decrite pas shenron qui consiste a avoir un vecteur de deplacement en fonction du temps ecoulé (et ne pas de la frame). cette methode a l'aventage d'etre moins couteuse, car a chaque frame on effectue le calcule pour placer l'entitée et c'est fini. en plus elle a l'aventage d'etre plus precise que la seconde methode. par contre, son gros probleme c'est pour la gestion des collision... si jamais tu a un temps ecoulé trops important, l'objet est projeté au loins et on risque de ne pas detecter les collisions proches...

la seconde methode consiste à dire que chaque objet se deplace qu'une valeure fixe a chaque "top" que lui donne le moteur. ca s'appel le time stamping. en gros, le moteur a un laps de temps donné ou il efectue ce "top" pour mettre à jours les objets. si jamais le temps ecoulé est trop long, le moteur effectue plusieurs top.
l'aventage de cette methode est que les objet n'on pas à prendre en compte le temps par eux même et la detection des collisions est simplifiée (car on sait que l'obje ne sera jamais projeté au loins). par contre c'est plus couteux quand l'ordinateur est lent car on peut effectuer plusieurs top par frame sans que ceux ci apparaissent à l'ecran... (mais si l'ordinateur est rapide, on peut encore gagner du temps car les top ne sont pas effectué à chaque frame... bref on ne prete qu'au riches avec cette methode... plus l'ordinateur est lent, plus il est ralenti...)

[shenron666]

[...]si jamais le temps ecoulé est trop long, le moteur effectue plusieurs top.
l'aventage de cette methode est que les objet n'on pas à prendre en compte le temps par eux même et la detection des collisions est simplifiée (car on sait que l'obje ne sera jamais projeté au loins). [...]

Mais si l'ordi doit effectuer plusieurs top, le problème où l'objet serait projeté trop loin ne se repose t-il pas ?
je connaissais cette méthode mais sans les tops, juste 1, et du coup si l'ordi n'était pas assez puissant, l'animation ralentissait

à la limite on peut définir un nombre de top maxi ?

[Sivrît]

Mais si l'ordi doit effectuer plusieurs top

Les tops sont le rythme de la gestion physique. La mise à jour des coordonnées et la détection des collisions y ont lieu, alors que l'affichage est relégué à "quand on peut".

je connaissais cette méthode mais sans les tops, juste 1, et du coup si l'ordi n'était pas assez puissant, l'animation ralentissait

Ben ça fait une troisième méthode. Décréter un temps fixe entre chaque frame, quitte à ce qu'il ne corresponde plus au temps réel si la machine ne suit plus, est ce que l'on fait (faisait ?) en animation 2d. Par contre, ne pas oublier de plafonner le nombre de fps pour avoir la bonne vitesse quand tout va bien.

[shenron666]

Par contre, ne pas oublier de plafonner le nombre de fps pour avoir la bonne vitesse quand tout va bien.

Ce qui est le but premier de ce post
sinon pas la peine de prendre le temps bon ok ->[]

[bafman]

Ben ça fait une troisième méthode. Décréter un temps fixe entre chaque frame

en fait c'est tres exactement ca le time stamping : on definit qu'une frame dure par exemple 1/24 seconde, et si le temps ecoulé est d'une seconde, on fait 24 top. ainsi, si notre objet se deplace de 1 unité par top, avec la methode qui consiste à passer le temps en parametre, notre objet va se deplacer de 24 unité, et a moins de gerer les collision de facon continu et non discrete, si on mure se presente à 12 unités, on le traverse.
par contre avec le time stamping, on va deplacer 24 fois notre objet de 1 unité, et donc on va detecter la collision en 12... maic ca fait 24 fois plus de calcule pour un ordinateur qui etait deja lent...
par contre pour l'ordinateur rapide qui fait du 48 image par seconde par exemple, le moteur ne fera de top qu'une image sur 2, donc on effectue moins de calcules...

c'est la methode su time stamping qui est utilisé par les moteurs physiques comme ODE et novodex. par contre a priori, le havok 3 et le moteur physique de Doom 3 gerent les collision de facon continu. c'est plus lourd en calcules, mais on n'a pas de risque de traverser un objet si on se deplace tres vite (probleme des objet à haute velocité qui n'est pas resolu par le time stamping)

[Invité]

Bonjour,

la seconde methode consiste à dire que chaque objet se deplace qu'une valeure fixe a chaque "top" que lui donne le moteur. ca s'appel le time stamping. en gros, le moteur a un laps de temps donné [b]où il effectue ce "top" [b]pour mettre à jours les objets.

Et comment fait-on ce "top" ?
Il faut ajouter un "timer" ? On le fait avec Glu, glut, autre ?

[shenron666]

dans ton programme, tu as une boucle qui attend des événements et qui lance ton affichage

en gros, dans ton affichage, tu peux avoir quelque chose du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void Affichage(void)
{
   if(tempsActuel < topAattendre)
      return;
 
   afficherLaScene;
}

le top, c'est un instant à partir duquel tu autorise ton programme à continuer
il y a d'autres méthodes plus ou moins portables et plus ou moins propres
à toi de voir également comment ton programme est structuré

[Omfraax]

Euh, j'ai en fait un peu le même problème que Kent sauf que je n'ai pas de problèmes de collision donc j'opterais pour la 'première' méthode, mais donc finalement, c'est quoi l'équivalent de SDL_GetTicks() sous Glut ?

Jusqu'à maintenant, j'utilisais un clock() de la librairie time.h (je suis en C) mais ça ne doit pas être si fiable, nan ?

[shenron666]

sous Glut tu peux utiliser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
glutGet(GLUT_ELAPSED_TIME);

[Omfraax]

Et ça, c'est le temps depuis la dernière frame ?
Est ce que ça correspond au dernier appel de la fonction passée en argument de glutIdleFunc() ??

(Je suis un peu paumé sur quand et comment OpenGL gère les appels à toutes ses fonctions )

[bafman]

non, glutGet(GLUT_ELAPSED_TIME) te retourne le temps ecoulé depuis le lancement de glut, donc si tu veut avoir le temps ecoulé depuis la derniere frame, il faut sauvegarder le temps de la derniere frame et faire une bete soustraction avec le resultat de GLUT_ELAPSED_TIME pour avoir le temps ecoulé.
de plus, il est preferable d'utiliser la fonction de glut pour recuperer le temps ecoulé car

• elle est portable
• sous windows, elle utilise le timer precis (le fameux performance counter), qui lui permet d'avoir une precision inferieur à 10ms (ce qui n'est pas le cas avec les compteur de base de windows)

[shenron666]

Et ça, c'est le temps depuis la dernière frame ?
Est ce que ça correspond au dernier appel de la fonction passée en argument de glutIdleFunc() ??

On va éviter de te copier/coller la doc de glut dans le forum
Une petite recherche sur internet du type "glut documentation" donne en premier lien :
http://www.opengl.org/documentation/...ec3/spec3.html

il n'y a pas de miracle, faut lire les docs

(Je suis un peu paumé sur quand et comment OpenGL gère les appels à toutes ses fonctions )

attention à ne pas te mélanger les pinceaux avec les différentes bibliothèques, chacune a son champ d'action
OpenGL gère les appels à OpenGL (les fonctions glMachin) pour l'affichage
Glut lui, gère les appels à glut (les fontions glutMachin) pour la l'interfaçage avec le système (fenêtrage, entrée / sortie,...)

[Omfraax]

Okay, merci et désolé pour pas avoir cherché dans la doc avant mais je passais par hasard sur le forum, j'ai vu ce post d'ouvert et j'ai pas pu résister à poser ma question