timeDelta causing laggy movement

Graphics and GPU Programming Programming

Started by StoneDevil April 04, 2006 12:37 PM

5 comments, last by Armadon 18 years ago

122

Author

April 04, 2006 12:37 PM

im trying to create a simple camera class that can move around and rotate. and it is working but not when im multiplying its movements by timeDelta. timeDelta is calculated every frame like so:

int d3d::mainLoop( bool (*ptr_display)(float timeDelta) )
{
	MSG msg;
	::ZeroMemory(&msg, sizeof(MSG));

	static float lastTime = (float)timeGetTime(); 

	while(msg.message != WM_QUIT)
	{
		if(::PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
		{
			::TranslateMessage(&msg);
			::DispatchMessage(&msg);
		}
		else
        {	
			float currTime  = (float)timeGetTime();
			float timeDelta = (currTime - lastTime)*0.001f;

			ptr_display(timeDelta);

			lastTime = currTime;
        }
    }
    return 0;
}

and in my display method i am checking input and moving the camera

if(::GetAsyncKeyState('W') & 0x8000f)
			cam->translate(0,0,1.0f*timeDelta);
		if(::GetAsyncKeyState('S') & 0x8000f)
			cam->translate(0,0,-1.0f*timeDelta);
		if(::GetAsyncKeyState('D') & 0x8000f)
			cam->translate(1.0f*timeDelta,0,0);
		if(::GetAsyncKeyState('A') & 0x8000f)
			cam->translate(-1.0f*timeDelta,0,0);

it all works if i dont multiply by timeDelta...the movement is very smooth...but it wouldnt be timebased....but i dont know why the timeDelta is making it run choppy thanks

SiS-Shadowman

359

April 04, 2006 02:30 PM

i have the same problem like you
i wrote my own camera class and it's position is updated every frame.
when i use this code, the movement is smoth, but when i multiplie it with the frametime ( wich is beeing calculated the same way than yours ), the movement isn't smoth, wich doesn't make any sense to me ( perhaps my logic is broken again *lol* )

mvEyePoint.x = mvEyePoint.x + cosf(fvAngle)*sinf(fhAngle);mvEyePoint.y = mvEyePoint.y + sinf(fvAngle);mvEyePoint.z = mvEyePoint.z + cosf(fvAngle)*cosf(fhAngle);mvEyePoint.x = mvEyePoint.x + cosf(fvAngle)*sinf(fhAngle)*FrameTime*15.0f;mvEyePoint.y = mvEyePoint.y + sinf(fvAngle)*FrameTime*15.0f;mvEyePoint.z = mvEyePoint.z + cosf(fvAngle)*cosf(fhAngle)*FrameTime*15.0f;

i multiply the whole factor by 15, because the speed would be too slow ( at 60 frames, i got a frametime of 0.015 secs, and that crops down speed... )

i hope anyone knows the answer to this problem

Gamedev-Journal

JoeyBlow2

100

April 04, 2006 02:57 PM

timeGetTime is not the best method to use.

I believe its based on a 5ms timer internally. So sometimes you will get the time passed as 0, othertimes 5ms. So depending on the results you get, it could leave you with a choppy scene.

QueryPerformanceCounter() is the best time method to use. It goes down to the clock cycles for interval/calculation and can give you the time in nano-seconds rather than 5 milliseconds.

Quote:

Windows NT/2000: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the timeBeginPeriod and timeEndPeriod functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and QueryPerformanceFrequency functions to measure short time intervals at a high resolution,

StoneDevil

122

Author

April 04, 2006 03:24 PM

thanks for that....i got it working better now....just have to scale the time down mmore than before...

ET3D

810

April 04, 2006 03:47 PM

BTW, when using QueryPerformanceCounter, it's a good idea to add a test whether you get negative time differences. This can happen with Athlon X2 CPUs. A driver update (which can be downloaded from the AMD site) can solve this problem.

ET's Place

JoeyBlow2

100

April 04, 2006 05:02 PM

I believe that only applies if you have multiple threads.

If I remember right, the DirectX 10 documentation says that each thread should calculate its delta from results of QueryPerformanceCounter on the same thread. For example, you don't want to call QueryPerformanceCounter on one thread to get the start time, then calculate the end time from another thread. As the threads could report different times because the cores have different results (and give you negatives.) If you have each thread doing its own QueryPerformanceCounter start/end calls, you are doing it as they suggest.

However, I may have misunderstood that.

Armadon

1,091

April 04, 2006 10:39 PM

If you find that time delta is a bit too jerky, try and average it out. Just take the previous time delta and the current and get the average and use that. I have used it many times before where I was not satisfied with the movement I was getting.

I hope this helps.
Take care.

timeDelta causing laggy movement

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

timeDelta causing laggy movement

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines