Timing problems.

SteveDeFacto
Posts: 31
Joined: Sat Jul 23, 2011 4:24 pm

Timing problems.

Post by SteveDeFacto »

In my code I basically have it set up like this:

Code: Select all

DWORD previousTime = timeGetTime();
while( WM_QUIT != msg.message )
{
DWORD currentTime = timeGetTime();
DWORD elapsedTime = currentTime - previousTime;
// do stuff
DynamicsWorld->stepSimulation(((float)(elapsedTime * elapsedTime * elapsedTime)) / 100000.0f);
}
I cubed the elapsedTime because I noticed that as my FPS went up objects started to move too fast. Now that I did this objects in my scene move at the same speed at 15 FPS as it does at 150 FPS but when it's about 60 FPS they move too fast... How can I get my scene to move at the same speed no matter what the FPS is?
eagletree
Posts: 28
Joined: Sun Jul 31, 2011 11:20 pm

Re: Timing problems.

Post by eagletree »

I can't answer you. But given the low traffic on the forum, it can't hurt to talk between people trying to figure this stuff out. I had the same problem plus, in a widely varying framerate while spawning many vehicles, I also had jerky rendering if I tried to use the sane version of the stepSimulation. I haven't solved it but have a hack that worked and kept it that way as there was no one to ask why it works or if I've created a problem I'm not aware of yet. What I did will seem stupid and I don't mind anyone saying so if they can explain what I should be doing. Even to be mocked is better than no replies ;).

I called the stepSimulation three times per render recalculating the delta each time and using a substep of 1. This is only for my driving level as it worked horribly for character controller or just applying force on rigid bodies without rewriting everything else. For everything else, I was using a single call with the definitions I'd assumed to be stock (delta/1000.0f,60). I couldn't reproduce the effectiveness of this with a single call and tried for several days, even posting here but deleting after no reponses. Here was the hack:

Code: Select all

if (level==1.4f) {
		World->stepSimulation(TDeltaTime/1000.f,substeps);
		irr::f32 then = device->getTimer()->getTime(); 
		then-=TDeltaTime; 
		World->stepSimulation(then/1000.f,substeps);
      newtime=device->getTimer()->getTime();
		newtime-=then;
		World->stepSimulation(newtime/1000.f,substeps);
	}
This gave me smooth movement, was realistic enough and consistent speeds when the frame rate varied. I've no idea why. Adjusting forces was necessary to make this work.
SteveDeFacto
Posts: 31
Joined: Sat Jul 23, 2011 4:24 pm

Re: Timing problems.

Post by SteveDeFacto »

eagletree wrote:I can't answer you. But given the low traffic on the forum, it can't hurt to talk between people trying to figure this stuff out. I had the same problem plus, in a widely varying framerate while spawning many vehicles, I also had jerky rendering if I tried to use the sane version of the stepSimulation. I haven't solved it but have a hack that worked and kept it that way as there was no one to ask why it works or if I've created a problem I'm not aware of yet. What I did will seem stupid and I don't mind anyone saying so if they can explain what I should be doing. Even to be mocked is better than no replies ;).

I called the stepSimulation three times per render recalculating the delta each time and using a substep of 1. This is only for my driving level as it worked horribly for character controller or just applying force on rigid bodies without rewriting everything else. For everything else, I was using a single call with the definitions I'd assumed to be stock (delta/1000.0f,60). I couldn't reproduce the effectiveness of this with a single call and tried for several days, even posting here but deleting after no reponses. Here was the hack:

Code: Select all

if (level==1.4f) {
		World->stepSimulation(TDeltaTime/1000.f,substeps);
		irr::f32 then = device->getTimer()->getTime(); 
		then-=TDeltaTime; 
		World->stepSimulation(then/1000.f,substeps);
      newtime=device->getTimer()->getTime();
		newtime-=then;
		World->stepSimulation(newtime/1000.f,substeps);
	}
This gave me smooth movement, was realistic enough and consistent speeds when the frame rate varied. I've no idea why. Adjusting forces was necessary to make this work.
Actually I found a way to get reasonably consistent speed at different frame rates. Maybe it will help you:

Code: Select all

DynamicsWorld->stepSimulation( ((float)(UpdateTime)) / 1000.0f, UpdateTime / 5 );
Also from the way you describe your problem this may also help but I'm just throwing it out there:

Code: Select all

DynamicsWorld->getDispatchInfo().m_allowedCcdPenetration = 0.0001f;
mi076
Posts: 144
Joined: Fri Aug 01, 2008 6:36 am
Location: Bonn, Germany

Re: Timing problems.

Post by mi076 »

:oops:
eagletree
Posts: 28
Joined: Sun Jul 31, 2011 11:20 pm

Re: Timing problems.

Post by eagletree »

SteveDeFacto wrote:
eagletree wrote: Actually I found a way to get reasonably consistent speed at different frame rates. Maybe it will help you:

Code: Select all

DynamicsWorld->stepSimulation( ((float)(UpdateTime)) / 1000.0f, UpdateTime / 5 );
Also from the way you describe your problem this may also help but I'm just throwing it out there:

Code: Select all

DynamicsWorld->getDispatchInfo().m_allowedCcdPenetration = 0.0001f;
I tried it. It was consistent and good physics appearances, but it didn't solve the jerky rendering updates. That's a separate issue I was having with the vehicle controller which started my quest to get this stepSimulation understood and how I ended up with the hack.
eagletree
Posts: 28
Joined: Sun Jul 31, 2011 11:20 pm

Re: Timing problems.

Post by eagletree »

SteveDeFacto wrote:
eagletree wrote: Also from the way you describe your problem this may also help but I'm just throwing it out there:

Code: Select all

DynamicsWorld->getDispatchInfo().m_allowedCcdPenetration = 0.0001f;
I just realized you were suggesting a solution for my other problem in the "falling through level thread". I hate to say it worked without about an hour of testing, but so far, it does seem to work. Thanks for answering my thread even though this was yours ;).