A Hiccup in movement
My program as of now simply moves a paddle up and down. I have used the following code in order to standardize the speed across different processor speeds. The problem is that every now and then the movement will 'hiccup' and jump up or down. It will move farther than normal that is.
The Player.Update() simple adds or subtracts '1' to the y-coordinate.
Any clues as to the hiccup?
Thanks.
timeBeginPeriod(1);
currentTime = timeGetTime();
timeEndPeriod(1);
if(!firstTime)
{
currentTime = timeGetTime();
oldTime = currentTime;
firstTime=TRUE;
}
if(currentTime - oldTime > 2) {
Player.Update();
oldTime = currentTime;
}
Doesnt this just delay it and not check it? (will move faster anyway)
I always did it like this. (pseudocode)
...
if(first frame)
{
start = gettime;
}
draw();
current = gettime;
(note all times are in milliseconds)
y += [MovementPerSecond]*(1000.0/(current-start));
That way it wil almost always move correctly (but it still hiccups because it is a multimedia timer... if you can use the hardware high performance timer.
if it does check, try using the high performance timer (check the tutorials)
I always did it like this. (pseudocode)
...
if(first frame)
{
start = gettime;
}
draw();
current = gettime;
(note all times are in milliseconds)
y += [MovementPerSecond]*(1000.0/(current-start));
That way it wil almost always move correctly (but it still hiccups because it is a multimedia timer... if you can use the hardware high performance timer.
if it does check, try using the high performance timer (check the tutorials)
The world isn't unpredictable. It's CHAOTIC.
Yeah basically Intamin is right, you take the previous time displacement and multiply it by the speed.
However even with a high performance counter timed movement can still be choppy.(Plus high performance counters are not available on all cpus) I had problems with choppy timed movement in 2D myself and searched the forums. Basically this happens because because this is "integration" over an unstable time period. Basically we assume that the current time period is prety close in duration as the previous frame. However in reality the time duration of frames doesn't transition "smoothly" from one to the other. Frames can have significant time jumps ("hickups") reletive to their previous frames many times a second. There are several solutions. One is to use a constand frame rate update scheme. But if you want to stick to frame independence, there are other methods. Check out Runge-Kutta integration. Also I am sure there are many other ways of integration you can find on the web. Also there is a methong where you average the previous 4 or 5 frame durations.
Also (brainstorming out of my head) you can use a slope line to predict the next time interval. Or maybe even a fitted curve. But these are just ideas I am planning to test.
However even with a high performance counter timed movement can still be choppy.(Plus high performance counters are not available on all cpus) I had problems with choppy timed movement in 2D myself and searched the forums. Basically this happens because because this is "integration" over an unstable time period. Basically we assume that the current time period is prety close in duration as the previous frame. However in reality the time duration of frames doesn't transition "smoothly" from one to the other. Frames can have significant time jumps ("hickups") reletive to their previous frames many times a second. There are several solutions. One is to use a constand frame rate update scheme. But if you want to stick to frame independence, there are other methods. Check out Runge-Kutta integration. Also I am sure there are many other ways of integration you can find on the web. Also there is a methong where you average the previous 4 or 5 frame durations.
Also (brainstorming out of my head) you can use a slope line to predict the next time interval. Or maybe even a fitted curve. But these are just ideas I am planning to test.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement