Irrlicht Engine

Posted: **Tue Apr 21, 2009 9:21 pm**

Ok so I pondering an issue. I have most of my moment code done. For kicks I took my code to a fast computers and everything but sound and animations are way to fast. I know that sounds and animations sync to frame so I got to thinking I better do everything this way.

So I need to find a way to sync all my transformations to my fps. I would do this by using the timevars from the device or my animators, but I dont really see how i could- do this.

My move functions move by an amount its 0 to 25. 25 being as fast as the player can go. The rotations by in large only move a maximum of 2 at a time.

So what I'm wondering is , is there a common approach to this? Or do I need to move my player my amount * time past? Or better yet figure out what a frame is and only move my amount when a frame changes?

Then next, how to use this in all 100 functions? C++ and global functions = messy. Maybe I can calculate a global constant?

Posted: **Tue Apr 21, 2009 11:03 pm**

Well just use the irrlichttimer if you it is accurate for you (what it should be normally) and calculate the changes by i.e. current_velocity * delta_time. But this method is sometime inaccurate because juppy delta_time or something like this can mess up many algorithmen. So try to keep your delta_time as constant as possible. I.e. use something like this in your mainloop:

Code: Select all

while(device->run())
{
starttime = timer.getTime();
do_stuff();
current_deltaT = timer.getTime() - starttime;

if(current_deltaT < your_wished_constant_delta_time)
device->sleep(your_wished_constant_delta_time - current_deltaT);

Posted: **Tue Apr 21, 2009 11:10 pm**

yeah this was sort of my thought. I didnt know about sleep. So that is a way of limiting the fps in a sense. the game will run only when said time occurs. and since the animatinos and sound are set to detla they will not change..

Sound good I'll try it out, thx

Ok-- some understanding?

it would a pear my code runs a few cycles a frame, and this is expected. I would think that the time is some how constant over system to system? As in 1000 delta are the same on a 1gig and a 2 gig, I could be wrong. If it is constant then I can get the frame rate, I would think. So 233 delta would = one frame. This way I could set my time variable to that constant.

does this sound at all right?

for clarification this method does work, I just need to know how to match the speed across systems. If there is a constant, I'm hoping the timer is? So far setting my delta to 50 show a noticeable skip but 20 does not. and 20 makes the faster computer run a bit closer to the desired speed.

Posted: **Wed Apr 22, 2009 9:47 am**

i think the Irrlicht-timer measures time in msec. So it is constant at every system (in bestcase).

Posted: **Wed Apr 22, 2009 12:13 pm**

Thats is what I was hoping. So 1000mm would be one frame.

Posted: **Wed Apr 22, 2009 12:29 pm**

No. 1000ms are one second. Not more and not less.

Posted: **Wed Apr 22, 2009 1:51 pm**

durr , I meant one second, LOL.. My bad.

Sorry.

so at 60 fps, a second is like 16.666666666666666666666666666667 ms

Posted: **Wed Apr 22, 2009 1:57 pm**

ulao wrote:so at 60 fps, a second is like 16.666666666666666666666666666667 ms

rofl ^^
This time frame was correct

Seems like someone will go to bed earlier this night ^^

Posted: **Wed Apr 22, 2009 2:23 pm**

right frames not seconds...

agreed.. Long day.

Posted: **Thu Apr 23, 2009 7:01 am**

This is not the best approach to solve problem. What if somebody will try to run your app on slower computer than yours?

You should define your actions ...movements, rotations and like... per some global time unit ...like per second or hour.
Then you need to calculate time between frames and calculate your action based on that difference. Like that, your app will behave the same on any computer.
There is some danger if you would run it on computer which is so fast that time between frames will be smaller than 1 millisecond in which case it will be detected as 0 (there is no way of measuring time which is less than 1 millisecond). But there are ways of solving that too.

Just think:

your node should move 10 units per second
time elapsed between current and last frame is 100 miliseconds (0,1 seconds)
you will move your node 10 * 0,1 = 1 unit

next frame elapsed time will be 50 miliseconds (0,05 seconds)
you will move your node 10 * 0,05 = 0,5 units

Your movement is thus independent on framerate.

Posted: **Thu Apr 23, 2009 7:20 am**

If animations are too fast, node->setAnimationSpeed() would do it, no matter the refresh frequency.

Posted: **Thu Apr 23, 2009 1:21 pm**

arras wrote:there is no way of measuring time which is less than 1 millisecond

This statement in general is definitely wrong. Linux gettimeofday, Windows QueryPerformanceCounter. But in case of only Irrlicht supported timer your statement may be right.

And the shown solution is only a limitation. For the calculations the following sentence is important:

Nox wrote:Well just use the irrlichttimer if you it is accurate for you (what it should be normally) and calculate the changes by i.e. current_velocity * delta_time.

Posted: **Thu Apr 23, 2009 2:45 pm**

This statement in general is definitely wrong. Linux gettimeofday, Windows QueryPerformanceCounter. But in case of only Irrlicht supported timer your statement may be right.

Yes I was referring to Irrlicht and its timer.

And the shown solution is only a limitation.

In which way is it limiting (except limit of 1 milisecond discussed above)?

Posted: **Thu Apr 23, 2009 3:02 pm**

I mean: the delta_time+sleep solution is only for limiting the fps

Posted: **Thu Apr 23, 2009 5:10 pm**

Irrlicht Engine

syncing the game to a constant fps.

syncing the game to a constant fps.