Re: [AD] al_convert_bitmap

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


On 2011-06-13, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Sun, Jun 12, 2011 at 11:18 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > Can I summarise the new flags like this, or propose that they
> > work like this:
> >
> > ALLEGRO_ANY_BITMAP|ALLEGRO_MEMORY_BITMAP
> > ALLEGRO_ANY_BITMAP|ALLEGRO_VIDEO_BITMAP
> >
> I assumed the flags would be mutually exclusive. That's why I proposed
> ANY_BITMAP as opposed to an AUTO_CONVERT flag.
> 
> This was how I considered it:
> 
> ANY => try video first, fall back to memory. tag bitmaps as pending video
> VIDEO => try video or fail
> MEMORY => try memory or fail
> 
> Then when a display is created, if auto-convert is enabled (default
> behavior) everything tagged as pending video would be converted to
> video.
> 
> When a display is destroyed *all* video bitmaps are downgraded to
> memories and tagged as pending video. It doesn't matter how they were
> created.

That's how I saw it as well, which led to VIDEO being the same as
VIDEO|ANY.

> 
> The goal with all that is simply to make it work how people expect it
> without much fuss or complication. If somebody really wants full
> control, then can simply disable auto conversion, mark things as
> MEMORY and manually call al_convert_bitmap() later.
> 
> VIDEO|ANY doesn't mean much to me. It could be a distinction between
> destroying a bitmap upon display creation or not.

That's a good idea.  Right now there is no way to express to Allegro
that you don't care about a video bitmap after its display is destroyed,
so the most efficient way to clean up a display and its bitmaps is to
let al_uninstall_system() do it.

VIDEO (without ANY) would tell al_destroy_display() to destroy the
bitmap (as far as possible) instead of converting it.  It would probably
need to leave behind a zombie bitmap so that it does not crash when the
user calls al_destroy_bitmap().  Zombie bitmaps can simply have neither
VIDEO or MEMORY flags set.

> MEMORY|ANY only makes sense to do it while a display is created. So
> why not then just manually create a memory bitmap, do your thing, and
> then convert it? What's the use case with the MEMORY|ANY combo. You
> obviously already know in advance that you don't want a video bitmap.
> 
> I'm not against allowing ANY to be an additional tag (as it allows for
> more flexibility), but then I'd rename it to:
> 
> ALLEGRO_MEMORY_BITMAP | ALLEGRO_AUTO_CONVERT_BITMAP
> ALLEGRO_VIDEO_BITMAP | ALLEGRO_AUTO_CONVERT_BITMAP

AUTO is better than ANY, but AUTO_CONVERT seems a bit long.
It might not matter.

> The absence of VIDEO and MEMORY would indicate to try video first then
> fall back to memory. None of those three flags would mean try video,
> then memory, and set auto convert. That would mean there would be no
> way to say "I want a video or a memory bitmap but don't auto convert",
> but I don't think that's a useful combination.
> 
> If the flags work together like that, then I think it makes sense that
> VIDEO bitmaps without AUTO_CONVERT would be destroyed upon a displays
> destruction.

Yes.

Peter




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