Re: [AD] al_convert_bitmap

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Fri, 2011-06-10 at 00:21 -0500, Matthew Leverton wrote:
> The current implementation bothers me because sometimes the VIDEO flag
> falls back to a memory (no display exists) and other times it does not
> (display exists).
> 
> I also think the name is a misnomer if it falls back to memory
> bitmaps, which is why I prefer the flags ANY, MEMORY, VIDEO. Now if
> you don't like messing with backward compatibility, it could be
> implemented with:
> 
> VIDEO: falls back to memory bitmap on failure, even if display exists
> (changed behavior)
> MEMORY: always returns memory (same as current behavior)
> REQUIRE_VIDEO: always returns video (new flag)
> 
> I don't really like the above names, but the important bit to me is
> that there is an option that always falls back. That currently is
> missing.

Yes. I just would have kept only two of your options (and no way to
require video).

> 
> Regarding your preference of fall back code, my suggestion doesn't
> exclude you from picking an option that falls back to memory
> automatically. In fact, right now, you cannot write it that way since
> Allegro will fail if you try to load a video bitmap that is too large.
> 
> But I agree that generally the "require video" would not be very
> useful. But to me, this makes the most sense from a naming convention:
> 
> set_new_bitmap_flags(0); // will try video first or memory as a fall back
> set_new_bitmap_flags(ALLEGRO_ANY_BITMAP); // same as above
> set_new_bitmap_flags(ALLEGRO_VIDEO_BITMAP); // only return video
> set_new_bitmap_flags(ALLEGRO_MEMORY_BITMAP); // only return memory

Yes, I agree. As for 5.0 compatibility - not sure. Probably when
updating 5.0->5.2 most ALLEGRO_VIDEO_BITMAP flags need to be changed to
ALLEGRO_MEMORY_BITMAP. Which I'd consider acceptable.

> The documentation says "Creates a bitmap that resides in the video
> card memory." The silent conversion to memory bitmaps when no display
> is present is not mentioned. So to me, changing the behavior to work
> like above will not be surprising to most people.
> 
> > Actually, another use for tags could be fonts. If I load a bitmap font
> > in another thread there currently is no way to convert it
> >
> The "convert all bitmaps" would convert them, right?

Oh, true.

> 
> But shouldn't the font addon always try to use video bitmaps
> regardless? I don't think the programmer should have to be aware of
> how the fonts are implemented. That is, to me, I don't even know if
> the font addon should respect the bitmap flags.

Since both the bitmap-font and ttf-font addon call al_create_bitmap,
they do use the bitmap flags. In the case of ttf, only at the time a new
cache is created (I believe at least it works that way). I think what we
should do in the ttf case is store the bitmap flags at the time the font
is loaded/created and then later create the glyph cache bitmaps the same
way. That way both bitmap and ttf fonts would honor the bitmap flags.

> And doesn't there need to be a clone_font() if you want to use the
> same font on multiple displays?
> 

Yes, that function is needed I'd say.

I'll make patches.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>