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

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

: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