Hiya, check out this code sample
Basically TimingMethod=0 will move one pixel per frame, so it's pretty smooth but will be a different speed on different PCs (depending on Desktop Hz). TimingMethod=1 will move by a delta amount each frame based on elapsed time, so will be the same speed on all PCs.
Note that the top rectangle is only drawn at integer coords with DrawRect by the graphics card so will look a bit jerky with TimingMethod=1, whereas the bottom rectangle (uses DrawImage) will look smoother due to Anti-Aliasing on the edges of the rectangle. Anyway, that's not the point of this post, I just thought I'd mention it so as not to send you on a red herring (lol, I mean wild goose chase).
Here's the thing: both skip/jerk a little bit occasionally, but it looks worse on the delta time version.
When I look at the output window in the IDE I can see where the jerks occur because the normal values (millsecs between each frame) are around 11,12,13 and when a skip occurs it goes up to 21 or 22 for one frame then 0 or 1 for the next frame.
This means that a frame doesn't get drawn when you expect to see it, so the old frame remains on-screen for longer. Then the new frame is flipped onto the screen.
With TimingMethod=0 this simply results in a time loss as the delay is never "caught up". However, with TimingMethod=1 the delta time makes the shape jump ahead a bit to catch up for the loss, and then worse, because it thinks the next frame took no time at all, it doesn't move it on much - a double whammy of crap compensation.
So, if I can't get to the bottom of why these delays occur (must be windows/other apps doing a load of background stuff) my challenge is to smoothly compensate/interpolate when these glitches (and possibly bigger glitches occur). Perhaps I could say, OK don't catch up that loss in one frame, do it over several frames. Also if a frame takes lower than expected, it could subtract that from the "pool" of time to catch up. Sound sensible?
Any ideas? Thanks, this is driving me nuts!
Strict SetGraphicsDriver D3D7Max2DDriver() 'SetGraphicsDriver GLMax2DDriver() Graphics 800,600,0 Local x# = 0 Local TimingMethod = 1 Local width = 200 Local height = 200 Local FPS# = 85 'target FPS Local MSPerFrame# = 1000.0/FPS Local Delta# = 0 'grab an image of a rectangle with a one pixel border for anti-aliasing Cls DrawRect 1,1,width-2,height-2 Local Image:TImage = CreateImage(width,height,1) GrabImage image,0,0 Local LastTime = MilliSecs() While Not KeyHit(Key_ESCAPE) Local now = MilliSecs() Local Elapsed# = now-LastTime LastTime = now 'logic Select TimingMethod Case 0 x:+1 'fixed amount each frame Case 1 Delta# = Elapsed/MSPerFrame x:+Delta End Select If x>= 800 Then x:-(800+width) 'draw Cls DrawText Delta,0,0 Print Elapsed SetBlend AlphaBlend 'Note: Rectangles are drawn at integer coords so look jerky with Timing Method 1 DrawRect x,50,width,height 'Note: Image is drawn at a floating point coord and anti-aliased with Timing Method 1 DrawImage image,x,350 Flip 1 Wend
Basically TimingMethod=0 will move one pixel per frame, so it's pretty smooth but will be a different speed on different PCs (depending on Desktop Hz). TimingMethod=1 will move by a delta amount each frame based on elapsed time, so will be the same speed on all PCs.
Note that the top rectangle is only drawn at integer coords with DrawRect by the graphics card so will look a bit jerky with TimingMethod=1, whereas the bottom rectangle (uses DrawImage) will look smoother due to Anti-Aliasing on the edges of the rectangle. Anyway, that's not the point of this post, I just thought I'd mention it so as not to send you on a red herring (lol, I mean wild goose chase).
Here's the thing: both skip/jerk a little bit occasionally, but it looks worse on the delta time version.
When I look at the output window in the IDE I can see where the jerks occur because the normal values (millsecs between each frame) are around 11,12,13 and when a skip occurs it goes up to 21 or 22 for one frame then 0 or 1 for the next frame.
This means that a frame doesn't get drawn when you expect to see it, so the old frame remains on-screen for longer. Then the new frame is flipped onto the screen.
With TimingMethod=0 this simply results in a time loss as the delay is never "caught up". However, with TimingMethod=1 the delta time makes the shape jump ahead a bit to catch up for the loss, and then worse, because it thinks the next frame took no time at all, it doesn't move it on much - a double whammy of crap compensation.
So, if I can't get to the bottom of why these delays occur (must be windows/other apps doing a load of background stuff) my challenge is to smoothly compensate/interpolate when these glitches (and possibly bigger glitches occur). Perhaps I could say, OK don't catch up that loss in one frame, do it over several frames. Also if a frame takes lower than expected, it could subtract that from the "pool" of time to catch up. Sound sensible?
Any ideas? Thanks, this is driving me nuts!