Re: [AD] 4.3 display update methods

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 8/9/06, Chris Robinson <chris.kcat@xxxxxxxxxx> wrote:
On Wednesday 09 August 2006 07:28, Elias Pschernig wrote:
> As I understand, the retained just means that you need to call al_flip
> before graphics updates get visible. So it is retained in that al_line
> won't immediately make a line appear, but only the next al_flip.

Ah. You mean double buffering, then. When I think of retained, I think that
it's kept after use (eg. something is retained for later use). I think
AL_DOUBLEBUFFER or some such would be clearer to indicate that the commands
won't be immediately visible.

When I say retained, I mean that 'the system' (i.e Allegro + the OS)
will keep whatever you drew on the screen forever. This is like
current Allegro. For example you can make a simple drawing program
just by calling
if (mouse_b) putpixel(screen, mouse_x, mouse_y, color);
in a loop. The app doesn't need to remember which pixels are supposed
to be lit. Maybe 'maintained' is a better word?

By contrast if you have a double/triple-buffered setup, you can't
really make any guarantees about the content of the back buffer before
you start drawing to it. You have to draw everything (which in many
games is not a big deal anyway). However, this can give you a
performance boost (or that's what's suggested in the D3D docs anyway,
and I know that on my iMac, specifying a retained (my definitition)
OpenGL context makes it use the software renderer)

In  both cases you need to call al_flip to make sure the screen is up
to date with what you've drawn.

So the user has a choice of a very simple model (which might be
slower) or a slightly more complicated one (which is faster)

What I think would be a major benefit for Allegro is if concepts like
'double buffered' , 'dirty rectangles' and 'video bitmap' became
irrelevant to the end user - Allegro optimises itself to give the best
performance for what the user is doing. For example, automatically
creating OpenGL textures from bitmaps if they are frequently used as
the source for a blit operation. It's ambitious and maybe impossible
but I would like to see us move that way.

Otherwise we're not adding that much value in the graphics area -
OpenGL/D3D are already much more comprehensive APIs than Allegro could
ever be.

Pete




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/