[SDL] framerate -- increasing accuracy for compensation
Matt Johnson
mjohnson at shortgrass.net
Thu Apr 5 11:50:59 PDT 2001
Yeah I'll look into at the timing code at glElite and see if that helps. I
especially like that code where it checks to see if the FPS is greater (!)
than infinity. lol.
In case anyone is curious, gl tron does this "wrong" also..but there is no
other way I guess, you cant sample it every second because the adjustments
have to be made on the fly.. I need to check out TuxRacer again. Maybe the
loss between frames is neglible and the adjustments I made to the
movement/rotation is where I'm losing the accuracy..
Anyway for the curious this is how gltron does it.
int updateTime() {
game2->time.lastFrame = game2->time.current;
game2->time.current = SystemGetElapsedTime() - game2->time.offset;
game2->time.dt = game2->time.current - game2->time.lastFrame;
/* fprintf(stderr, "dt: %d\n", game2->time.dt); */
return game2->time.dt;
}
if
time.current was 50,90,110,140,190 (for 5 frames)
time.dt would be .. 40, 20, 30, 50
Which btw what happens when um time.current > 2^sizeof(time.current)?
hehe..remember MS logging bug where after 49 days it would mess up? It was
because it couldnt fit the # of milliseconds in 32-bit integer. See its
problems like these that keep my up at night.
This could occur though because note SystemGetElapsedTime() might not start
at 0, it might start near 2^32.. meaning wrapping error, time.current would
be giving you negative #'s..
void camMove() {
camAngle += CAM_SPEED * game2->time.dt / 100;
while(camAngle > 360) camAngle -= 360;
}
> > Anyone run into this issue?
>
> You describe exactly the problem I had :) Feel free to try my solution.
More information about the SDL
mailing list