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?
syncing the game to a constant fps.
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);
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.
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.
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.
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.
This statement in general is definitely wrong. Linux gettimeofday, Windows QueryPerformanceCounter. But in case of only Irrlicht supported timer your statement may be right.arras wrote:there is no way of measuring time which is less than 1 millisecond
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.
Yes I was referring to Irrlicht and its timer.This statement in general is definitely wrong. Linux gettimeofday, Windows QueryPerformanceCounter. But in case of only Irrlicht supported timer your statement may be right.
In which way is it limiting (except limit of 1 milisecond discussed above)?And the shown solution is only a limitation.