Still dont get timeGetTime()

Started by
16 comments, last by Gooberius 19 years, 5 months ago
It would equal some number between 0 and 2^32 - 1, which as fel said is the number of milliseconds since the last boot.
ReactOS - an Open-source operating system compatible with Windows NT apps and drivers
Advertisement
I think i get it, i think i got it from the guy that posted the example code. I needed to know it for framerate, Thanks!
Sure i will write my signature, just gimme a piece of paper
So to get the number of seconds, do:
float Seconds = float(timeGetTime()) * 0.001f;
~CGameProgrammer( );Developer Image Exchange -- New Features: Upload screenshots of your games (size is unlimited) and upload the game itself (up to 10MB). Free. No registration needed.
Quote:Original post by CGameProgrammerQueryPerformanceCounter() finds the number of clock cycles elapsed, and QueryPerformanceFrequency() finds the number of ticks per second (2.4GHz for me). Your way is basically an inferior hack due to not knowing about the above functions.


Not quite an inferior hack (I think ;). What bothers me about QueryPerformanceCounter and QueryPerformanceFrequency is that the documentation for QPF says that the value returned won't change while the system is running (click here for the QPF msdn page). Now, I know that some laptops *will* change their clock speed according to battery level and such, so either QPF/QPC are based off a different clock (in which case that's all well and good), or they don't quite support variable clock speed systems properly. I was under the impression that QPC was basically just RDTSC behind the scenes and that there was/is no other very high resolution timer currently in PC systems, hence my confusion.

I haven't looked into this personally because my method works just fine and dandy for me, but if anyone can shed light on this I'd be interested to hear about it.
QueryPerformanceFrequency does indeed use the rdtsc instruction. My hack comment was about you using timeGetTime() instead of QueryPerformanceCounter(), which is far more precise (it's perfectly precise).
Whoops, that post was by me.
~CGameProgrammer( );Developer Image Exchange -- New Features: Upload screenshots of your games (size is unlimited) and upload the game itself (up to 10MB). Free. No registration needed.
I just redid my whole timing system using QueryPerformanceCounter and QueryPerformanceFrequency and ran it alongside the system clock for about half an hour to test the accuracy, I think it lost about a quarter of a second in all that time, which is probably due to my code putting certain things outside of the containment of my StartClock() and EndClock() statements. Compared to my old millisecond thing that would lose between 2 and 7 seconds every minute and whose resolution led to very changeable framedeltas, this is awesome.

use it now.
Quote:Original post by Anonymous Poster
QueryPerformanceFrequency does indeed use the rdtsc instruction. My hack comment was about you using timeGetTime() instead of QueryPerformanceCounter(), which is far more precise (it's perfectly precise).


Ok, QPC is basically RDTSC. QPF returns the clock speed of the CPU. But the MSDN page for QPF states that the value returned won't change while the system is running. I know for a fact that some systems (notably laptops running on battery, but still worth considering for some of us) *do* change their clock speed on the fly, so QPF should return a different value when necessary. My "hack" is basically fixing the broken QPF function. I don't see what the problem is. Admittedly, using timeGetTime for accurate timing is madness, but just using it to see when >1000 milliseconds have passed should be accurate enough most of the time.

This topic is closed to new replies.

Advertisement