Re: [AD] No more video/system bitmaps

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


On Tuesday 21 June 2005 21:02, Robert Ohannessian wrote:
> Why can't we just use AL_BITMAPs everywhere?

Well, I'll need some time to come up with a detailed answer. The short 
answer is that the two are, in my opinion, at least logically distinct 
objects. DISPLAYs can be an event source, but I hardly think that wouldbe 
appropriate for BITMAPs.
I also have objections to the idea of having an update method associated 
with, in principle, any type of bitmap.

Of course there can be different kinds of bitmaps, some that have update 
methods and events associated with them and some that do not, but at this 
point you have exceptions and special cases piling on top of eachother, 
and the discussion becomes more semantic anyway: one might as well call 
the BITMAP that has events and an update method a DISPLAY.

> AL_DISPLAY introduces 
> uneeded complexity in those nasty corner cases (which basically makes
> the hard part even harder). Using AL_BITMAPs everywhere gives us bounded
> complexity: We already know how to handle it because that's what Allegro
> is currently doing!

The discussion is then really wether you want one big one-object-fits-all 
sort of thing, which is what Allegro BITMAPs currently are, or a 
seperation between BITMAPs and DISPLAYs that cleans this up a bit.

I personally far prefer the latter and think it will make things 
considerably easier in the long run.

Of course, BITMAPs can be associated or derived from a DISPLAY, and the way 
the graphics API is now it is through the associated BITMAP that DISPLAYs 
are updated. I think this makes logical as well as programme technical 
sense. The suggested proposal sortof mixes this up by making it possible 
to associate a BITMAP which is not part of a DISPLAY with a newly created 
DISPLAY.
As I said, I think the idea is fascinating and I'd like to look at it a 
bit. But I still think the two should be logically seperate entities.

Evert




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