# Losing time with timeGetTime()?!

## Recommended Posts

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 views
while(view != NULL)
{
//			currentTime=System::GetTime();

// render and go to next
view->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 562347 render view took 20 newtime 562367 current time 562367 render view took 10 newtime 562377 current time 562377 render view total took 30 But OCCASIONALLY I get... start render views 562437 render view took 20 newtime 562457 current time 562548 render view took 20 newtime 562568 current time 562568 render view total took 131 Which 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!

##### Share on other sites
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.

##### Share on other sites
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!

##### Share on other sites
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.

hth
Jack

##### Share on other sites
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)

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.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628283
• Total Posts
2981823

• 10
• 10
• 11
• 17
• 15