[…]
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?
-
pygame.display.update(s.dirtyrects)
-
pygame.display.update()
-
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 —On Friday 14 May 2004 14.43, Bo Jangeborg wrote:
