yes, I have gone into it now and have found that its a waste of time trying to update faster than the refresh anyway....it just doesnt work very flush adn runs like a snail. The reason it changes speed is indeed because it is on the same thread. So, the vsync affects the overall timer speed![Happy](images/pgdsmilies/happy.gif)
That out of the way my problem is now catering for time based movement at very fast pixel moves at a deltatime of 17ms (which would be the minimum at 60Hz)
At this speed, each sprite is skipping 26 pixels (1500*(17/1000) ) at each frame (enough to miss the object it is supposed to collide with)
I have looked over what you wrote adn what a few people have wrote, but sadly, I just don't understand fully the logic behind catering for this kind of scenario.
I will look further into it, and if need be supply a demo so that maybe someone can show me the light hahaha But, I have tried to do this in delphix but failed. This would be so so so much easier on a piece of fixed hardware...if only![Happy](images/pgdsmilies/happy.gif)
:lol:
This is the kind of shoddy code I am working with (works great in non vsync mode though since deltatime is usually low on all computers)>>
ops:
Code:
deltaTime := timegettime - lastTime ;
if (Deltatime>15)then
begin
deltatime:= 15; //undesireable since those with 60Hz refresh (17 deltatime) will have an unfair advantage.
end;
lastTime := timegettime;
dx:=deltatime/1000;
I have now just extended the paddle by 5 pixels width, this will make sure it isnt possible for the ball to pass through at deltatimes of even 20 but it is a sloppy fix it has to be said
Bookmarks