   queryPerformanceCounter frequently jumps to far.
  Hey!i use the queryPerformanceCounter/queryPerformanceFrequency to ensure that my logic steps 100 times per second. But every couple of seconds it jumps far into the future causing my logic to step 50 odd times at once to catch up which basicly sends my simulation 0.5 sec into the future in an instant. This is quite anoying but "beareble" on my high end desktop pc but on my laptop its much worse.Ive read posts where similar problems were described but i could not find a clear solution. Is queryPerformanceCounter/queryPerformanceFrequency realy the best way to get acurate time? How does commercial quality game engines ussualy do it?Thnx in Advance!   
  That can be a problem with QueryPerformanceCounter and is usually due to hardware (or driver, actually) bugs. It seems odd that you have the same problem with two different computers, though.Commercial games use a combination of techniques to get accurate timing. Sometimes they simply use timeGetTime (and timeBeginPeriod(1)) instead, sometimes they do something more complicated.The simplest solution would be if the frame time is greater than a certain amount (e.g. 1/30s) to simply return the hard-coded value. That is,if (frameTime > (1/30.0f)    frameTime = (1/30.0f);A more elaborate solution might be to take the average frame time over the last n frames, and if the current frame time is too far from that average, to return the average instead. That'll be slightly more accurate, though slightly more complex.   ;  No, it is not the best way, except if you target Vista and later on the most modern processors only.In fact, QPC is not only not the best way, but it is probably the worst way to measure time. On less-than-last-generation CPUs and/or less-than-Vista, QPC uses the RDTSC instruction (except on Windows 95/98 where it uses some other weird stuff). So, QPC has all the problems of RDTSC (most notably, different cores being out of sync, a.k.a "jumps", and Speedstep slowdowns), plus it has OS call overhead, plus you can't even rely on it using RDTSC.timeGetTime() works reasonably well, although with lower resolution. At least, it's reliable, though. If you need the higher resolution, you should implement a RDTSC counter yourself and make sure that this thread runs on a known CPU (by setting affinity). I'm using a construct that blocks the RDTSC reader thread in a semaphore. For getting a time, you post it. Sounds horrible, but it works surprisingly well.Also, you'll need to make sure your program uses enough CPU power to prevent power saving features from clocking down the CPU, but this is usually not a problem for a game. :-)   ;  Thnx a lot!well il start with trying timeGetTime() and if i need to il look into creating my own custom solution :P   