   fps not calculated correctly?
  hey there.i've been trying to calculate the fps of my game. currenly a maximum of 37 thousand polygons are rendered to my screen(including culling) on geforce 9600 GT, yet the time steps between every frame is way too low(talking about less than 1 milisecond).so far i've been doing this    int temp = GetTickCount();   DrawInGame(Device);int d = GetTickCount()-temp;if(!d)d+=1;FPS = 1000/d;if(FPS > 60)FPS = 60;that means i get atleast 1000 fps, which seems kinda way too high for that number of polygons, also my movement system depends on fps, so if i realy did have more than 1000 fps then my character would be flying.i am doing this every frame. did i do something wrong?   
  GetTickCount isn't very accurate..use QueryPerformanceCounter() and QueryPerformanceFrequency() instead   ;  GetTickCount() is only accurate to about 15ms, so you can't use it to measure more than ~67 FPS. If you want to time things like that you need to use a high performance counter like QueryPerformanceCounter().Alternatively, do things differently - Count how many frames you render in a second, and use that as your FPS value (Or count the number of frames in 100ms, and then your FPS = that * 10, etc). If you're timing 1000ms, then GetTickCount() should be fine.   ;  i see, thanks :)i am not sure though how QueryPerformanceCounter() is used + i heared it causes some problems with certain old windows operating systems like NT nad 9x.   ;Quote:Original post by Brui see, thanks :)i am not sure though how QueryPerformanceCounter() is used + i heared it causes some problems with certain old windows operating systems like NT nad 9x.And it doesn't work very well on dual core PCs either. I'd recommend just timing over a short-ish interval like 250ms.   ;Quote:Original post by Evil SteveQuote:Original post by Brui see, thanks :)i am not sure though how QueryPerformanceCounter() is used + i heared it causes some problems with certain old windows operating systems like NT nad 9x.And it doesn't work very well on dual core PCs either. I'd recommend just timing over a short-ish interval like 250ms.Is that still a problem with modern processors? The only sources that I can find regarding the issues with QPC on multi-core processors are from threeish years ago.   ;Quote:Original post by bobofjoeIs that still a problem with modern processors? The only sources that I can find regarding the issues with QPC on multi-core processors are from threeish years ago.I believe so. There's multiple methods that QPC can use. If it uses the time stamp counter, then it fails on variable speed (I.e. laptop) or multi-core CPUs. If it uses a motherboard timer, it can still break under heavy bus traffic.Personally, I prefer to not have to deal with all of the problems it has (or can have), and not use it. I also don't trust users to have up to date systems with any patches that may have been released for it.   ;  I use timeGetTime(). MSDN says it's accurate to within 1 ms. You must include winmm.lib and winmm.h if you defined lean and mean.   ;Quote:Original post by Evil SteveQuote:Original post by bobofjoeIs that still a problem with modern processors? The only sources that I can find regarding the issues with QPC on multi-core processors are from threeish years ago.I believe so. There's multiple methods that QPC can use. If it uses the time stamp counter, then it fails on variable speed (I.e. laptop) or multi-core CPUs. If it uses a motherboard timer, it can still break under heavy bus traffic.Yep, and what's worst, you have no way to know what it's using (though it's pretty much safe to assume that pre-Vista post-95 Windows uses RDTSC), and the time stamp counter does not necessarily correspond to time at all, despite its name.This is no problem if either your program always uses 80-100% CPU, or if you are interested in actual ticks, not time. In those cases, RDTSC absolutely rules (if used with affinity).However, if time is what you want, and you aren't sure that your program will hog the CPU enough, then it won't work reliably, as most modern CPUs will cut down the clock speed to 1/2 or 1/4 (or some other unknown number) if they're not loaded. Thus, you get less ticks in the same time interval...   