   Losing time with timeGetTime()?!
  Hi All,I am having some VERY strange problems with timeGetTime() and debugging is returning even more bizarre results.  I have the code...void GameApp::OnRender(DWORD in_currentTime, DWORD in_elapsedTime){DWORD totalTime=System::GetTime();DWORD newTime;DWORD currentTime=System::GetTime();_RPT1(_CRT_WARN, "start render views %i\n",totalTime);// render game viewsDListNode<GameViewPtr>* view=m_gameViews.Head;while(view != NULL){//currentTime=System::GetTime();// render and go to nextview->Data->OnRender(in_currentTime, in_elapsedTime);view=view->Next;newTime=System::GetTime();_RPT1(_CRT_WARN, "render view took %i\n",newTime-currentTime);currentTime=System::GetTime();_RPT2(_CRT_WARN, "newtime %i current time %i\n",newTime, currentTime);}_RPT1(_CRT_WARN, "render view total took %i\n",System::GetTime()-totalTime);}Which when I run, I am mostly getting consistent results of...start render views 562347render view took 20newtime 562367 current time 562367render view took 10newtime 562377 current time 562377render view total took 30But OCCASIONALLY I get...start render views 562437render view took 20newtime 562457 current time 562548render view took 20newtime 562568 current time 562568render view total took 131Which makes no sense to me at all because I seem to be losing about 100ms on an _RPT2 call.  Either that, or timeGetTime is screwed.Has anyone seen behavior like this before, or can maybe shed some light on what may be happening?Thanks!   
timeGetTime() is screwed. In addition, it's quite possible that some of your calls take longer than usual because of some stall, getting pre-empted by the scheduler, paging, etc.   ;  Thanks for the link.  I could understand if it was losing a couple of milliseconds here or there, but 100ms is a hell of a long time even for a pre-emptive interrupt.Is there any way to disable interrupts to test and see if this is the problem?  Also, if this is the problem, why do other games not exhibit the same issue?Oh, incidentally this is running on a Thinkpad T40, and also I get the same result with QueryPerformanceCounter.Thanks!   ;  I'm going to push this over to 'General Programming' - this seems to be more of a general Win32 type question rather than anything specific to the DirectX API.However, you might want to search the DirectXDev archives - I dont remember the exact thread title(s), but there have been numerous detailed discussions about timing functions in the last year or so.hthJack   ;Quote:Original post by RaeldorThanks for the link.  I could understand if it was losing a couple of milliseconds here or there, but 100ms is a hell of a long time even for a pre-emptive interrupt.Is there any way to disable interrupts to test and see if this is the problem?  Also, if this is the problem, why do other games not exhibit the same issue?Oh, incidentally this is running on a Thinkpad T40, and also I get the same result with QueryPerformanceCounter.Thanks!Are you sure they don't? Can you really spot whether a game *occasionally* takes 130ms to render a frame?100ms isn't that unrealistic for a preemptive interrupt. Depending on your OS, the quantum might be ~10-100ms (although WinXP is in the lower end of this, since it's  aimed at desktop use where responsiveness is more important than throughput)However, that's 10ms for one thread. There's no guarantee your thread will get the next timeslice.Anyway, IIRC, WinXP always executes the available thread with the highest priority. So if you set your priority to high, no other process will run at all, except when your thread is blocked and unable to run. That might help you in debugging your issue.   