[SDL] Screen syncronizing

[David Olofson]

On Friday 14 May 2004 14.43, Bo Jangeborg wrote:
[...]
> In pygame I have three options for updating the screen. Do I
> understand you correctly if I say that none
> of these represent your s/w back buffer?
>
> 1.                    pygame.display.update(s.dirtyrects)
> 2.                    pygame.display.update()
> 3.                    pygame.display.flip()

Well, I can only guess, as I've never used pygame... Assuming that the 
first two wrap the SDL_UpdateRect*() calls, and the last one wraps 
SDL_Flip(), then yes, that's correct.

The "semitriple" buffering setup that Pig uses when supported (two h/w 
pages + one s/w shadow), is not directly supported by SDL. You have 
to implement the shadow surface yourself, on top of an SDL double 
buffered h/w display surface.

Now, do keep in mind that this setup is utterly pointless if the blits 
you are using are accelerated! Only use this if you do significant 
amounts of alpha blending to the screen, and aren't on a backend that 
accelerate alpha. (Only glSDL and DirectFB do that, AFAIK, so don't 
rely on it. Most users won't have accelerated alpha.)


> By s/w back buffer you mean a s/w surface that then get blited to
> the screen?

Yes. SDL gives you one of those if you ask for a single buffered s/w 
surface display.


> Am I correct in assuming that you can't use double buffering in a
> window ?

In theory, no, double buffering in a window *is* possible. However, 
without special (high end) hardware, it's very tricky to implement, 
so very few (if any) widely availably windowing systems support it.

Either way, I strongly recommend that you disregard the 
windowed/fullscreen property in this regard. There is no guarantee 
that a window cannot use page flipping, nor is there a guarantee that 
a target can use page flipping *at all* even in fullscreen modes. 
(Many can't - including XFree86 without DGA, meaning some 95% of the 
Linux users.)


> The real trick then is figuring out when to move the sprites. How
> do you figure out how much time has passed
> so that you know when to update the sprite the next time?

Well, in Pig, that's handled by decoupling the logic frame rate from 
the rendering frame rate. (That's the main point with the example, 
actually. :-)

The game either generates exactly one frame per monitor refresh (if 
retrace sync is possible), or it just generates frames as fast as 
possible. (That minimizes the difference between frames, thus reduces 
the tearing when animating without retrace sync.)

Before rendering each frame, the engine checks the current time 
(SDL_GetTicks()) to see how many logic frames have passed since the 
last rendered frame. (Usually 0, since the logic frame rate in Pig is 
*very* low, just to demonstrate the effect of interpolation.) Logic 
time is advanced to the right frame, rounded upwards, and then all 
graphics coordinates are interpolated from the logic coordinates from 
the last two logic frames.


> It could be that this is hard to implement in python.

As long as you have a plain SDL API binding, and not some kind of 
"smart" engine, it should be *easier* to do in just about any other 
language than C. It's the logic that is tricky to grasp.


> While Im at it, do you think your sound module could be integrated
> with pygame ?

Sure, it's just another sound engine. However, be warned that there 
will be changes in the API (cleanups) and file formats (new scripting 
engine) in the next few releases. I wouldn't hack any external code 
that relies heavily on the current "object model" of Audiality.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---