Sign in to follow this  
Raeldor

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
		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!

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this