[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: timing ?




On 19-Aug-99 Ken Dunn wrote:
> 
> Can anyone see anything wrong with doing this for a simple
> delay between up dates, outside of non-portability ? 
> 
> 
> /* for a least 1/20 pause */
>#define USEC_DELAY 50000 
> 
> void tick(void)
> {
> struct timeval nt;
> static int64_t old;
> static int64_t new;
> long long t_delta;
> for(;;) {
>         gettimeofday(&nt, NULL);
>         new=(int64_t) nt.tv_usec + (int64_t)\
>                 (1000000 * (int64_t) nt.tv_sec);
>         t_delta = new - old;
>         if(t_delta > (int64_t) USEC_DELAY)
>                 { old = new;
>                   return;
>                 }
>         /* has system time gone backwards ?*/
>         if(t_delta < 0)
>                 { old = new;
>                   continue;
>                 }
>         usleep(1); /* works very nicely on my machine. Where HZ = 1024 */
>         }
> }
> 
> 

the code looks correct as far as I can see. But in using this 'tick()'
function, you limit your maximum framerate. Why not just calculate the time
delta then scale everything against that? that way time related stuff is
calculated in a common medium on ALL systems from an alpha rendertower 16 to a
386sx16 with 4m ram... By using the tick method, faster cpu's won't gain
framerate beyond the 'target' speed, and machines below the 'target' speed will
suffer. Could also screw up network communication :) just my insignifacant
thoughts 

        -Erik <br0ke@math.smsu.edu> [http://shells.clipboard.com/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.