[Resolved] How to have a speed based on the timer ?

[FuZ Ion]

I want the player to move in the world with a constant speed. But when the fps is equal to 200, the player will move with a speed of 10 (for exemple) and when the fps will be equal to 2000, the speed will be equal to 100....
So I would like to have a speed based on the time, but I don't know how to do that.

Could you explain to me how to do pleaze ?

thanks

[bitplane]

this has been discussed countless times, the simplest way is-

position += velocityPerMilisec * numberOfMiliSecsPassed;

velocityPerMilisec is a vector3df, and you obviously need to store the current time so you can work out how much time has passed between frames

[Saku]

This should be pretty simple since Irrlicht has an internal timer.
See this example from my own code:

Code: Select all

// Get time since last render
ITimer * timer;
timer = device->getTimer();
float ThisUpdate = timer->getTime();
float deltaTime = (( ThisUpdate - LastUpdate ) / 1000.0f);
LastUpdate = ThisUpdate;

// Update Physics World
TA::Physics::GetInstance().Update ( (float) deltaTime );

Of course in your case you just replace the physics with you movement.
Also you would of course also have to have some sort of variable 'LastUpdate' probably declared static som where to hold the needed info.

Hope you can make some sence of this ^^

[FuZ Ion]

Thank you very mush !
bitplane >> I did a search on the forum but I didn't find the good topics...

[Guest]

another solution is possible:
it is ti limit the fps.
i've found the way to do it under windows only.
so i limit the FPS to 60, and then every computer which normally would have render the scene over 60 FPS, renders it at 60 FPS.
But for slower computer, that is a problem.

check google about this FPS limiter, or if you want i can send you my source code.

anyway, you'll need to know a little Object Oriented C, but it's not very difficult.
the last problem is that your code won't be compilable under OS other than Windows.
Choice what seems you the best way

[FuZ Ion]

Yes it's also a good solution !
Could you send your code to limit fps ?

you'll need to know a little Object Oriented C

... I don't have very mush experience with c++ but with all the forums about c++, I'll be able to understand the code I think...

thanks

[Guest]

another solution is possible:
it is ti limit the fps.
i've found the way to do it under windows only.
so i limit the FPS to 60, and then every computer which normally would have render the scene over 60 FPS, renders it at 60 FPS.
But for slower computer, that is a problem.

check google about this FPS limiter, or if you want i can send you my source code.

anyway, you'll need to know a little Object Oriented C, but it's not very difficult.
the last problem is that your code won't be compilable under OS other than Windows.
Choice what seems you the best way

Limiting frames is always handy as a feature (and stop widly varying delta times) but to advise someone to use it as reccomended is not correct. You should never use just frame limiting as it is really a kludge or a hack and will fall to pieces the moment a system you didn't test on can't keep up or if you loose focus for a second - things can go out of sync.

Always use timebasedmodeling (the deltatime method posted above) and get smooth exact motion whether running at 60fps or 600fps.

It is not without it's problems (moreso for 2D interpolation etc) but another way is to keep an array of the last ten deltatimes and just use the average this stops wild deviations and keeps things even smoother.

more advanced that that is fixed step time based where you ALWAYS send a tick of 1 to your updates but hold on the rest until that time (still delta timing but very smooth)

http://www.gaffer.org/articles/Timestep.html

I stress - never rely just on frame limiting it is poor.

[Guest]

Has anyone implemented the "Fix Your Timestep!" article from the link posted by "Guest" in the one right above this post?

I would love to see how this is method applied to one of the irrlicht examples.

[Guest]

I am guest who posted it and have been looking at irrlichts code. I can put the timestep stuff into my own code (app) because I use classes of my own that set positions and movements of 2D elements and some 3D etc.

Now, if you use any built in irrlicht stuff (animators) this uses irrlichts own timing which is based on QPC (good in most cases except a problem with HTP4 laptops). However irrlicht doesn't use fixed timestep (not sure if it should per se) but I think it could benifit from an accumulator (an array of the last X deltatimes always averaged to make the actual delta time which avoids wildly varying delta times that cause jerkiness) - though not 100% robust.

If anyone could post a solid tutorial on all of this it would be cool because there are a number of issues that need addressing:

.Decoupling logic from render frame rate (fairly simple)
.Minimising cpu usage (100% all the time is just wrong/bad) - sleep(1) is a hack?
.Delta Timing works but is not without issues - accumulators help a bit
.Fixed timesteps (really delta timing but more solid) but how to integrate with irrlicht? or do we dump the irrlicht animators and make our own versions so that we can update manually "on time"
.QPC problems (hardware bugs causing leaps in the reported time) - there is code around to recalibrate it should it drift and I think THIS is the most important area right now for both minor "jitter" fixes and major "goes completely weird on my laptop" problems. I hope niko can address this and make timers 100% solid, it would be appreciated and I know it's a pain in the backside when all you wanna do is write a game/engine.

[...]

also:

http://www.flipcode.org/cgi-bin/fcartic ... show=63823

is handy reference.

[pwierz]

I've tried both methods (using irrlicht's timer and GetTickCount()). It almost seems that my machine is ticking at 60Hz. That would be great but I get rounding errors. So one tick takes 16.667 ms but when I get the tick count it rounds it to 16.0. So I can't sleep fractions of a millisecond. Is there a way to jack up the tick rate?

[stodge]

microseconds?