Re: [Tuxnes-devel] Smoother scrolling

[Mike M. <che...@ya...>]

Yes you are correct, how ever tuxnes takes care of counting ticks in the ASM.  Every time we draw
a frame it's been 1/60 of a second nes time, so we just need to make the real computer emulate
that.  In most video games timing will be constant, this way we don't get into complex
acceleration equations and such.  Too take care of the time we spend when were not sleeping we put
the gettime as close as posible to where we sleep.

Also I don't normally keep track of total time.  I don't know how different the 2 methods are, but
I know my way doesn't get overflowed.  What I do is reset my tick ctr to 0 every time I sleep, I
use the current time to populate basetime(Renamed to lasttime).  See my patch for an example that
includes a hybrid method.  I think it would be safe to remove the "if ( frame > 1800 )", I'd like
to here your comments.

--- digression ---

Yes you are correct, how ever video games use polling.  It's not clear what to do with a move once
the frame(round) is over, so processing(scoring) of that move MUST wait for the next round.  We
could take the input and differ scoring, but this would only make the usleep for this round a bit
less.  It's ok to ignore the input until it's round is being scored.

Also the nes uses polling, so we poll when it asks us too.  It would be cool to make this script
able for things like up-up-down-down...  Think mric type nes scripting :)

I've attached what I committed it's should hit the backup CVS server in 2 days.

mike

--- Jason Dorje Short <jd...@us...> wrote:
> Mike Mestnik wrote:
> > I was chasing a simular problem, but I coulden't get any thing to work.  I don't think it's
> > correct to cahnge the usleep, as it's based on the NTSC standared.  I.E. 16666 = 1 frame and
> if
> > were n frames ahead 16666 * ( n - 1 ) is how long we wait.
> 
> You don't want to usleep for a fixed amount of time, or you'll get 
> *behind*.  For instance if you sleep for 10 useconds and then do some 
> calculations that take 5 useconds, your tick length is actually 5 
> useconds instead of 10 useconds as you wanted it to be.  (Just using 10 
> as an example.)
> 
> Instead you want to do your 5 usecond calculations then sleep for just 
> the remaining 5 useconds.
> 
> The easiest solution is to track the time of each tick.  Use a timeval 
> struct to tell when the next "tick" should occur.  Then before sleeping 
> figure out how long is left between now and then, and sleep for that long.
> 
> Something like:
> 
>    struct timeval next, now;
>    int usec;
> 
>    /* This is the only time we call gettimeofday on 'next'.  After
>     * this we just increment it. */
>    gettimeofday(&next, NULL);
> 
>    while (1) {
>      next.usec += TICK_TIME;
>      if (next.usec >= 1000000) {
>        next.usec -= 1000000;
>        next.sec++;
>      }
> 
>      do_something();
> 
>      gettimeofday(&now, NULL);
> 
>      usec = 1000000 * (next.sec - now.sec) + (next.usec - now.usec);
>      if (usec > 0) usleep(usec);
>    }
> 
> In short, something like the attached patch should work.  I haven't 
> tested it, though.
> 
> 
> --- digression ---
> 
> There are also external events that generally need to be handled.  You 
> generally shouldn't poll for these (however this is NES emulation so 
> it's probably okay to be inefficient).
> 
> I've generally written network code where you want to call select() 
> while having a "tick" in place as well.  This works great since select 
> just takes the timeval struct as an argument.
> 
> In GUI code you want to either get interrupts or pass the waiting off to 
> a GUI function that can handle the interrupts directly.  My experience 
> is in GTK where you call a function to set a timer, then pass control 
> back to GTK.  While GTK has control it can do updates (like redrawing 
> windows), handle events (if a key is pressed GTK will call your 
> program's handler for that key), or handle the tick when the time comes 
> (GTK will call your program's handler for that tick).  SDL has something 
> similar, although it's generally implemented with polling anyway.
> 
> jason
> 


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus