j'eseille de flair un programme en opengl et il faut que je sache combien de temps il mette pour fair une boucle et je trouve pas de fonction qui son assez presise

Pour mesurer un temps d'execution on utilise clock(), pas une fonction relative au date comme time()

Ben au lieu d'exécuter ta boucle une seule fois tu l'exécute 10000 ou 100000 fois et tu divises
 
Ensuite tu répètes 15 ou 20 fois pour avoir un échantillon significatif et tu fais la moyenne
 
Quand t'as 2h de tests de perf, une précision d'une seconde sur les 2h n'a pas d'importance

cortex le souri> Ça pourrait t'intéresser aussi.
 
http://www.linuxfocus.org/English/ [...] e371.shtml
http://www.linuxfocus.org/Francais [...] e371.shtml
 
(retire tes mouffles la prochaine fois..)

pas mal comment tu écris presi

Ben non, c'est pas comme ça qu'on fait. Au deuxième passage tout est en cache et ça va beaucoup plus vite, donc tu ne mesure plus du tout la même chose.

Et si tu commençais par faire un correcteur d'orthographe ?
 
Sinon, utilise un profiler (gprof, par exemple), c'est fait pour...

désolé pour orthographe je suit plus douer en programmation que pour l'orthographe
mais je me suit malle exprimer pour ma question je doit savoir le temps qu'il mette pour une seule boucle et m'en servir dans le programme car si on se déplace je veut pas qu'on ralentise si le pc rame

à la lumière de ce que tu dis : mauvais raisonnement. Si tu dois consommer du CPU, tout le monde préfère une tâche qui se termine au plus vite. C'est le rôle de l'OS de faire en sorte que les autres processus obtiennent un part équitable de temps CPU. Faire trainer artificiellement un programme, c'est irritant et contre productif.
 
en fait j'ai rien compris : c'est qui "il" ? ça veut dire quoi se déplacer ?

imaginons que je veut faire un jeux de voiture je dit a la voiture d'avancer de 1 a chaque boucle du programme ben si le programme fait sa boucle en 0.001 seconde la voiture va avancer rapidement met si la programme fait 0.01 seconde pour flair une boucle la voiture va ralentir alors si je fait avancer la voiture de "100 * le temps d'une boucle" ben elle va toujours allez a la même vitesse

Je sentais le truc venir  
 
Donc la vitesse de tes voitures va varier selon le processeur que tu as ?  
C'est un concept original    
 
T'as juste besoin d'un mécanisme de timer en gros, donc voir sleep/usleep

non justement je veut éviter que la voiture varie en fonction de la vitesse du processeur

ils sont un peu hors sujet.
 
Sous Windows, c'est le couple QueryPerformanceTimer()/QueryPerformanceFrequency() qui te permet de mesurer ton temps par frame, et donc de réguler tes animations.
 
Sous Linux je sais pas je regarde en même temps sous google....

C'est le côté le plus complexe du problème, déterminer le sujet en question

tu as SDL_GetTicks() dans la SDL, mais ça peut provoquer des calculs instables vu que ça descends qu'a la miliseconde (si jamais tu fais un pic à 400-600fps, ce qui est probable lors des situations de faibles charge en OpenGl).

 
ce qu'il veux mesurer c'est le temps par frame pour faire ses animations/évolutions de son monde 3D.  
quelque soit la manière dont est régulée le traçage (sans limites comme tous les jeux, où régulée par timer comme peuvent l'être les moteurs de Carmack qui est l'un des seul a proposer une option dans la console pour réguler le framerate par voie multi-tâche friendly),  
il te faut une mesure de temps (suffisament) précise pour avoir tes animations en temps réel qui est réel. et pas en temps réel distordant
 
car même si ton moteur 3D en OpenGl, tu régules le traçage par message de timer, le message du timer ne te garanti rien, les messages ils peuvent arriver quand ils veulent, et le temps de traitement global de ta frame, déclenché parle message du timer, peut dépasser la période du timer de messages.  
 
ie timer à 30hz, si tu mets 1/22.78545s pour faire ta frame (soit plus de temps), pour l'actualisation des animations à la frame suivant il faut prendre en compe 1/22.7854s et non 1/30s sinon tes objets ils vont ralentir... (oups me suis gouré 1/30 < 1/22... )

et accessoirement, si le rendu est dérégulé comme le son tous les moteurs de jeux vidéo actuels (qui sont pas bloquants sur la queue de message), tu peux monter à 1000-2000fps en regardant un ciel, et être à 40fps en regardant à l'horizontal vu que tu auras le terrain et les objets dans le champ de vision), dans le cas 1000~2000fps max, il te faudra une poignée de µs pour la résolution de ton timer, si tu veux pas avoir des inconsistances temporelles suivant où tu regarde (et la charge graphique/générale liée au point de vue)

bon sous linux, gettimeofday() devrait faire l'affaire puisque tu as les µsecs (tout ça pour ça )

merci beaucoup sa devrait très bien aller
juste vue le nom je croix qu'il faudra que je fasse attention a minuit il doit passer de beaucoup a 0

je vient de faire un petit test en vitesse et avec une modélisation tout simple et un code qui est loin d'être fini voici le résulta
205528
224347
243266
259951
275502
visiblement s'est bien assez presi
encor merci

pour le rebouclage vers minuit, lorsque tu fais la différence, tu prends en compte le cas où la fin < début
 
 
si temps_fin < temps_début
   temps_ecoulé = temps_fin + (temps_max - temps_début).
sinon
   temps_ecoulé = temps_fin - temps_début

après le cas suivant problématique, c'est si ta frame mets plus de 24h a être faite