RE: RE: [AL] Smooth screen updating.

[Sean <se...@ho...>]

RE to: Isaac Cruz

> >     /* blit to screen */
> >     frame_count = update_count = 0;   // don't want them getting too big.
> > not sure if this causes any problems...

> You would have to be playing your game for more than 800 days to overflow these
> integers...

How silly of me :)

> > In the end I found that while it does a great job of catching up lagging
> > frame rates, it runs into problems slowing down excessive ones.  With my new
> > monitor at 75Hz the screen movement is at the proper speed, however, it is
> > VERY choppy.  I changed the refresh rate (in Windows) to 60Hz and everything
> > moved smoothly, however, I could see a "line of choppyness" (is that the
> > scanline or something?) moving slowly down the screen.  The scanline at 60Hz
> > is (I believe) fixable by using page flipping, however, I am at a loss for
> > what to do with the choppy screen.

> This is what I use in my game (double buffering with dirty rectangles):

*snip*

> Note that I use a maximum update rate of 100fps, because with 60 it was causing
> that "line of choppyness" you said.

That may get rid of the scanline, but the thing is I don't want to go that fast.  60 times per second is what I want.  Also, as I
mentioned before, it has no problems catching up slow computers (which your code does) - the problem is slowing down fast ones.  I
think the problem is that since the screen is refreshing at 75Hz (probably 100 in your case) while the code moves at a slower pace.
When the code wants to update, the screen is already midway into the next scan and the drawing must wait until it is done drawing
(another copy of the last update) to display the new changes.  This means (to me anyway) that this approach, while good for people
having a matching refresh rate, does not work for everyone.  Unfortunately I don't know what does!