Re: [AD] al_convert_bitmap

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Thu, Jun 9, 2011 at 8:10 AM, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Wed, Jun 8, 2011 at 9:11 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>> I think the documentation is lacking justification for why you might
>> want to create pseudo-video bitmaps before creating a display.
>>
> I think it has more to do with loading things in separate threads.
>

Well, it basically is the same concept, except current SVN has a set
of three tags:

MEMORY
VIDEO
MEMORY-TAGGED

And al_convert_all_video_bitmaps is the same as the more general
al_convert_bitmaps_with_tag(MEMORY-TAGGED, VIDEO)

>> Here's an idea: what if we introduce bitmap 'tags', where every bitmap
>> is tagged with the current tag when it is created.
>>
> That might make the transition (forward compatibility) go more
> smoothly if only tagged bitmaps were ever converted.
>

I almost think the tags would be overkill. I can't think of any
possible use case where I'd need two separate pools of convertible
bitmaps (unless maybe I have two (incompatible) displays, but someone
doing that likely is better off managing things manually - it's not
that hard to maintain a list).

> For 5.2, I think I would prefer if there were three flags:
>
> ALLEGRO_ANY_BITMAP = 0
> ALLEGRO_VIDEO_BITMAP
> ALLEGRO_MEMORY_BITMAP
>
> The default behavior (ANY) would create a video bitmap if possible,
> otherwise it would fall back to a memory bitmap. The VIDEO flag would
> fail if a video bitmap couldn't be created. (To maximize compatibility
> that flag could be called REQUIRE_VIDEO with the old one being
> deprecated, although personally I don't think it would be important
> to.)

One thing which needs thought is when i call al_load_bitmap with the
new VIDEO flag - it will return NULL and I'd have to load the same
bitmap a second time.

>
> The tagged concept would make converting less ambiguous. Allegro
> wouldn't have to keep track of which memory bitmaps were supposed to
> be video bitmaps. Basically, Allegro would never auto upload any
> memory bitmaps at any point.
>

I forgot what was all said in previous discussions since we stretched
it out over so much time - but auto upload sounds like a good idea to
me now. Like in the following:

1. create bitmap X (will end up as memory, but tagged as video)
2. create display (converts X to video)
3. use bitmap
4. destroy display (converts X back to memory, tagging it again)
5. create display (converts X to video again)
6. use bitmap

In current SVN the change would be simple, remove
al_convert_all_video_bitmaps again but do what it does in
al_create_display instead. This just is most user friendly I think.
Users of Allegro (who typically don't understand the difference
between video and memory bitmaps at first, and can't blame them) just
create bitmaps whenever they feel like it and the bitmaps will always
draw fast. At the same time even some display-less bitmap conversion
code will work without having to set flags.

Special cases (bitmaps too big to fit into a texture, loading from a
separate thread, using multiple displays) would still cause problems -
but at least the simple case would be very simple.