Re: [Tuxnes-devel] Smoother scrolling

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

The desync variable should be renamed to framesbehind.  When it's more than one we should not call
gettime or do the usleep.  We should framesbehind-- every frame and set it acordingly after the
gettime and before the usleep(Dose not get called when were behind).

As for the last time patch it stands as is.  The measurement of 1/60 a second applies to
everything we do, including the usleep.
  The fix needed is to redo the ordering.  Putting the usleep after we draw the frame before we do
the scoring is the answer.  It's true we can't find ought how log to wait at that time but we can
guess based on how long the last frame took.  The loop itself doesn't really have a start or
end(it's a loop) this concept is only created by the line numbers and should be ignored.  This is
the best order IMHO: Scoring(running the emu) before Rendering(Video&Sound) before
Gettime&Calculation before Sleeping before Drawing&Playing.
Drawing the frame and then calling swapbuffer(if available) after the usleep is a good idea but
it's not needed we can render right to the screen.  This would mean that any given frame is
displayed for exactly 1/60 a second.  The draw back is that every frame would be one frame behind
the input.  This is the case now but it's only part a frame.  The problem with nes emulation is
that input can be handled mid frame.  I don't think we can change the frame after the vsync has
ended.

--- Jason Dorje Short <jd...@us...> wrote:
> Mike Mestnik wrote:
> 
> > I forget where you can trap keypresses, there is a select statement some-where.  Reserve a key
> for
> > saving state, I started a branch for it and it's quite close to being testable.
> 
> Looks like there's already code for this.  There's a switch in 
> controller.c.  The keypad values change speed (for instance keypad 6 
> sets 6x speed).  They also set desync to 1 and 
> renderer_data.pause_display to 0 (no idea what this means).
> 
I was thinking about putting this code in another process, a fork.  Then emulate the nes
controller, I have the frequency some where.  This would get us away from polling and allow us to
do arbitrary input stuff(A bleeding flipper and a menu :).  We can use shared memory for the nes
registers and a command pipe/socket for every thing else.  This other process would also draw the
menus and other OSDs.

> > Things I'm looking fore are docs on nesticle.sta and that other nes file format.  The docs I
> have
> > on sta are not fully complete and I would like to include a copy of the rom in the image(for
> > game-genie).  There is some open nes format but the docs just baffeld me. it seamed to be
> packet
> > based but no real docs just blerb ware.
> 
> Several years ago a tuxnes developer (Mike Melanson?) sent me a spec for 
> the common-nes-save-file-format.  I doubt that I could find it now, 
> though.  At the same time he told me that the nesticle format should be 
> ignored and only the common format implemented.
> 
A web search didn't turn anything up, http://tuxnes.sourceforge.net/features.php talks about STA
and SNSS.  I think SNSS will be vary difficult for me to understand.

> jason


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