juddering motion

This topic is 4811 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hi, My d3d9 app has a judder in the motion of its camera. The camera always moves in the direction it is Looking like this:
void Ccam::move(float timeDelta)
{
mPos += mLook * m_fSpeed * timeDelta;
}

The judder appears to be once per second. I imagine this is something to do with the way the timeDelta is used to affect the speed of the camera. timeDelta is set here:
	timeDelta  = (timeGetTime() - now) * 0.001f;
now = timeGetTime();
timeElapsed = now - begin;

if ((timeElapsed) > 1000.0f)
{
finalFPS = fps;
fps = 0;
frameLength = 1000.0f / finalFPS;
begin = now;
} else { fps++; }

Can anyone see why this might be juddering along? I am baffled! Thanks Simon

Share on other sites
Have you used timeBeginPeriod( ) and timeEndPeriod( ) to increase the precision of timeGetTime( ) ?

Some unrelated minor tips on your code:

Use
finalFPS = fps / ( timeElapsed / 1000.0f );
finalFPS = fps;
Your calculation assumes that exactly 1000 ms have passed since the last measurement which might not be the case if for example 1014 ms have passed. Also use >= instead of > in the condition so that you cover for the case when timeElapsed is equal to 1000.0f.

You can skip the else-statement and put fps++ before the if-statement. Otherwise the frame that you perform the finalFPS calculation will not be counted in fps, since you skip the fps++ at that frame. If you do it the suggested way fps will always be increased and if one second has passed it will be used to calculate finalFPS and then nulled to start over at the next frame.

Stay sharp.

Share on other sites
it's windowed mode right? I just had the exact same problem in my own app. Try setting the presentation interval to D3DPRESENT_INTERVAL_ONE rather than DEFAULT. The documentation says that they're almost exactly the same, but the default seems to interfere somehow while ONE is super smooth. I also found that the D3DPRESENT_INTERVAL_DEFAULT works best for full screen apps.

Share on other sites
Hi,
2 things to check -

1) Is the movement smooth without the "* timeDelta"?

2) Is the scene quite complex? It may be that the frame limiter's slight inaccuracy (as mentioned above) may be noticable with large numbers of polygons, etc. Also, As the problem happens every second, it might be in the actual limiter code, try just working with integers - make all the variables (timeElapsed, finalFPS, fps and frameLength) integers and use 1000 rather than 1000.0 or 1000.0f, this might have an effect.

Good Luck!

-indirectX-

Share on other sites
Thanks to all of you but particularly staaf who was right,

By placing the fps++ in an else branch, it was not counted on the last frame, so each second the last frame had an inaccurate timeDelta.

Smooth as you like now!

Share on other sites
You're welcome. See you around.

1. 1
2. 2
JoeJ
14
3. 3
4. 4
5. 5
frob
11

• 13
• 16
• 13
• 20
• 12
• Forum Statistics

• Total Topics
632178
• Total Posts
3004603

×