Re: [AD] 4.3 display update methods

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

I meant FLIP aka RETAINED. We can always implement one as the other, if
ever that would be needed.

> -----Original Message-----
> From: alleg-developers-bounces@xxxxxxxxxx [mailto:alleg-
> developers-bounces@xxxxxxxxxx] On Behalf Of Peter Hull
> Sent: Wednesday, August 09, 2006 1:26 PM
> To: Coordination of admins/developers of the game programming library
> Allegro
> Subject: Re: [AD] 4.3 display update methods
> 
> Bob, sorry, can you just explain exactly what you mean by
> FLIP/RETAINED and FLIP/UPDATE?
> 
> Pete
> 
> 
> On 8/9/06, Robert Ohannessian <ROhannessian@xxxxxxxxxx> wrote:
> > Double-buffering isn't the only update mode. When you "flip", the
> > current render buffer content should be undefined. In debug mode, we
can
> > even clear it to some garbage (random?) value to catch apps that do
the
> > wrong thing.
> >
> >
> > > -----Original Message-----
> > > From: alleg-developers-bounces@xxxxxxxxxx
[mailto:alleg-
> > > developers-bounces@xxxxxxxxxx] On Behalf Of Chris
Robinson
> > > Sent: Wednesday, August 09, 2006 11:55 AM
> > > To: Coordination of admins/developers of the game programming
library
> > > Allegro
> > > Subject: Re: [AD] 4.3 display update methods
> > >
> > > On Wednesday 09 August 2006 08:59, Peter Hull wrote:
> > > > 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.
> > >
> > > Which is a flaw, IMO. It's currently needed because on DOS you
could
> > > assume
> > > that nothing would interfere with the graphics memory, so when you
> > drew
> > > to 'screen', it would stay. There was no need for a talk-back
> > mechanism.
> > > Then
> > > X and Windows came along, where your 'screen' could be dirtied by
> > other
> > > processes at any time, but Allegro had no way of letting you know,
and
> > > apps
> > > that aren't aware of such a thing would become problematic, so it
had
> > to
> > > keep
> > > a backup copy of what you did.
> > >
> > > Now that we have a chance to design the API to be nice with
resource
> > > sharing,
> > > we shouldn't try to emulate what is essentially a hack that kept
older
> > > programs working. Let it be known that if you're not double
buffering
> > and
> > > updating regularly, that the screen may be invalidated, and for
such,
> > they
> > > should watch for screen invalidation events. This won't be a
problem
> > for
> > > most
> > > people as they'll be hapilly double-buffering at 'ZOMG 1000 FPS',
but
> > the
> > > corner cases need to be handled properly by the user. Keeping
Allegro
> > > clean
> > > of this responsibilty directly will help make sure that users get
the
> > > performance benefits from accelerated drivers that they expect,
along
> > with
> > > the control to do it how they want.
> > >
> > > > 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?
> > >
> > > Examples using the current API to describe new API behavior don't
> > really
> > > work,
> > > as the semantics are different and what is currently normal
operations
> > can
> > > become corner cases (or simply not possible). But still, if
'screen'
> > is
> > > the
> > > front buffer, then I don't believe it should be Allegro's job to
> > maintain
> > > the
> > > screen's cleanliness for you. The back buffer, sure, but the front
> > buffer
> > > should be considered potentially volatile.
> > >
> > > > 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)
> > >
> > > Makes sense, since the only way to efficiently retain the back
buffer
> > and
> > > show
> > > it on the front buffer is to copy it instead of the faster way of
page
> > > flipping. Accelerated OpenGL implementions don't gaurantee the
state
> > of
> > > the
> > > back buffer after a flip (since they don't need to and it provides
> > > potential
> > > performance benefits), so you'd have to use a specialized
(software)
> > > implementation to get otherwise undefined behavior.
> > >
> > > > In  both cases you need to call al_flip to make sure the screen
is
> > up
> > > > to date with what you've drawn.
> > >
> > > If you draw to the front buffer, you should not call al_flip, as
that
> > will
> > > overwrite the front buffer with with whatever was in the back
buffer.
> > An
> > > al_flush command would be more suited to making sure the display
> > target is
> > > up
> > > to date (in both the front and back buffers) without changing
them.
> > > al_flip
> > > should just make the back buffer contents visible on the front
buffer,
> > and
> > > leave the back buffer's contents undefined.
> > >
> > > > 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.
> > >
> > > Proper dirty rectangles is very different from double buffering,
and
> > you
> > > can't
> > > really abstract the two away in an efficient manner. The best way
to
> > go
> > > would
> > > be to support double buffering (interacting with the back buffer),
but
> > > allow
> > > the user to interact with the front buffer at their own peril.
> > >
> > >
> >
------------------------------------------------------------------------
> > -
> > > Using Tomcat but need to do more? Need to support web services,
> > security?
> > > Get stuff done quickly with pre-integrated technology to make your
job
> > > easier
> > > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > >
> >
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > > --
> > > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> >
------------------------------------------------------------------------
> -----------
> > This email message is for the sole use of the intended recipient(s)
and
> may contain
> > confidential information.  Any unauthorized review, use, disclosure
or
> distribution
> > is prohibited.  If you are not the intended recipient, please
contact
> the sender by
> > reply email and destroy all copies of the original message.
> >
------------------------------------------------------------------------
> -----------
> >
> >
------------------------------------------------------------------------
> -
> > Using Tomcat but need to do more? Need to support web services,
> security?
> > Get stuff done quickly with pre-integrated technology to make your
job
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> >
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > --
> > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> >
> 
>
------------------------------------------------------------------------
-
> Using Tomcat but need to do more? Need to support web services,
security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers