🔒 Locked

Losing time with timeGetTime()?!

Started by Raeldor Jun 5, 2006 at 8:14 PM 3 replies 950+ views

Original Post

Jun 5, 2006 at 8:14 PM

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
		DListNode<GameViewPtr>* view=m_gameViews.Head;
		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!

hplus0603

Jun 5, 2006 at 8:26 PM

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.

Raeldor

Jun 5, 2006 at 8:58 PM

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!

jollyjeffers

Jun 6, 2006 at 6:33 AM

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

Spoonbender

Jun 6, 2006 at 10:41 AM

Quote:
Original post by Raeldor
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!

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.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.