Salut !

hier on soulevait sur IRC un probleme intéressant qui était celui de compter le temps !

Il y a plusieurs façons de compter le temps :
la plus pourrie je pense étant celle de < time.h>
qui fait des erreurs de 25 millisecondes... Ce qui est grave quand on veut qq chose de fluide.

Pour le moment ce que je connais de mieux ( sous Windows) :

1. include < mmsystem.h>

unsigned long timeGetTime();

retourne les millisecondes depuis le dernier boot, marge d´erreur de 4 - 5 millisecondes selon les systemes !

Si qq un a des fonctions plus précises dessus, je suis preneur ! !

GetTickCount fait exactement la même chose mais revient à 0 si le PC reste allumer plus de 49.7 jours(d´après l´aide API Windows).

vi en effet, ça se calcule
un Ulong boucle : ( 32 bits non signé)
( 2^32-1) +1 = 0

donc on peut stocker au max :

4 294 967 295 ms
= 4 294 967 s
= 1193 heures
= 49.7 jours

CQFD

Sous windows, 4 méthodes pour mesurer le temps :

- Le timer système, lié au BIOS, rafraichi 18.2 fois par seconde, soit environ 54 ms de précision.
- Le timer millisecondes GetTickCount.
- Le timer multimedia avec mmsystem et timeGetTime.
- Le timer haute résolution avec QueryPerformanceCounter.

Tous ces timers bouclent d´une manière ou d´une autre. Le fait que GetTickCount boucle à 49.7 jours tient au format du résultat, sur 32 bits non signé, soit un maximum de 4294967295 millisecondes, ce qui 4294967295 secondes, soit approximativement 1193 heures, ou 49.7 jours.

Il fallait lire :

" ce qui fait 4294967 secondes"

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q172/3/38.asp&NoWebContent=1

où est clock(); dans tout ça ?

clock() -> time.h -> mauvais...

anecdote :

un jour j´ai fait un test de sprites avec OpenGL : le sprite avançait de façon saccadée ! !
( je me suis dit : " 1 seul quad et je suis saccadé ! ")
en effet, au lieu d´avancer d´une distance D par frame, j´avançais d´une distance D par seconde, en me basant sur clock
alors j´ai affiché ce que me donnait clock, toutes les frames, ça donnait a peu pres cela :

0.526
0.526
0.526
0.557
0.557
0.557
0.582
0.582
0.582

bref, au lieu d´avancer régulierement par frame, il restait a la meme place pendant 3 frames, puis sautait d´un coup plus loin --> tout se passait donc comme si mon nombre de frame était divisé par 3...

tout a été mieux quand j´ai utilisé mmsystem

je vois

j´ai éssayé la méthode qui a besoion de mmsystem.h, mais mon compilateur me dis :

Compiling...
main.cpp
i:\program files\microsoft visual studio\vc98\include\mmsystem.h(113) : error C2146: syntax error : missing ´;´ before identifier ´MMVERSION´
i:\program files\microsoft visual studio\vc98\include\mmsystem.h(113) : fatal error C1004: unexpected end of file found

je suis sur qu´il n´y a pas d´erreur dans mmsystem.h, le probleme vient d´alleur. Mais d´où ?? ??

zut, j´avais jamais entendu parler de ça
Merci pour ce "up"

Je doute que la limite des 49 jours soit vraiment un problème ... déjà quelle appli tourne aussi longtemps ? sans rebooter au moins 1 fois.

Et puis même si cela arrivait, en général ces fonctions servent essentiellement pour calculer des deltaT, soit la différence entre t(n) et t(n-1). Donc peu importe, faudra juste penser à calculer cette différence en valeur absolue ;) A moins que le calcul soit suffisament long pour atteindre les 49 jours entre t(n) et t(n-1), un mega-calcul de raytrace peut être ? ;)

perso j´en ai pas beaucoup eu besoin mais j´ai utilisé SDLGetTicks() mais cela oblige a ajouter la lib sdl. Donne des résultat en ms depuis l´initialisation de sdl dans le prog. pour le moment je m´en plains pas mais j´imagine que cette fonction est bas

Sous windows la méthode la plus précise c´est le timer de haute résolution (comme le dit nesca) dont la fréquence est à peu près la même que celle du proco (donc plusieurs milliard de mises à jour par seconde).
Et comme le résultat est retourné dans un entier de 64 bits, on peut faire tourner un programme pendant plus d´une centaine d´années sans que le temps ne soit remis à zéro ...

Les fonctions à utiliser sont QueryPerformanceCounter pour avoir la valeur du compteur et QueryPerformanceFrequency pour avoir sa fréquence.

Je ne sais pas s´il y a un équivalent sous linux, mais probablement pas car ça se sers du matériel.

Altonfrere, je penses surtout que si ton calcul est susceptible de depasser les 50 jours, tu te fous completement davoir une precision de l´ordre de la milisecondes...

godrik ca c´est clair aussi

Pour la limite des 50 jours, j´ajoute qu´on s´en fiche éperduement !

En effet, comme disait Aitonfrere, le seul interet est de faire des Delta, uniquement.
A partir de la, on profite d´une propriété de la machine, qui est le "overflow"

J´illustre :
prenez un unsigned char :

ça va de 0 à 255.
Faites 255 + 1, vous obtenez 0 !
c´est cyclique !
(certes, le flag overflow est activé, mais on s´en fout)

Faites 255 + 4, vous "devriez" avoir 259, mais vous obtenez 3
faites 3 - 255, vous retrouvez bien le 4 !

C´est pareil pour le timer, tant que vous faites des delta, aucun probleme, meme pour le passage critique de 0xffffffff à 0x00000000

oui enfin,ceci n´est vrai que si on ne fait pas deux tours!
(mais bon, ca fait 100 jours, alors noter la date est bien plus pertinent pur ces opérations la...)

Ce qui ne sera pas bon, c´est un Delta de + de 50 jours, qui sera un résultat modulo, mais sinon, on peut faire autant de tours qu´on veut me semble t il !

A moins que j´ai oublié qq chose ?