Re: [AD] al_convert_bitmap

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


> 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.
>
Then why request a video bitmap if you don't really want one?

What if there is a display present, you have VIDEO set and it fails
because it's too big? You currently have to manually check and create
a memory bitmap.

Allegro has a split personality regarding this. If you try to create a
huge bitmap before a display, it will happily create a memory bitmap
of that size. It will later then try to convert it and fail. But if
you create that same bitmap after a display, it will return null.

This is why there should be three types that the program can request:

any: try video first, then memory. It does this even if there is an
active display. default behavior.
video: only try video. If no display, then this fails immediately.
memory: only try memory.

If we auto convert, then the "any" bitmaps would auto convert at
display creation. Since it would be the default flag (0), bitmap
creation would generally always succeed and always end up video
bitmaps after a display is created. (Also any "video" bitmaps that
were downgraded to "memory" due to previous display being destroyed
would also be converted.)

I don't mind if auto-conversion is the default behavior, but I would
make it optional and keep the convert-all function around. i.e.:

al_set_new_display_flags(ALLEGRO_AUTO_UPLOAD_BITMAPS, 0); // defaults to 1

Now the average user is happy because he doesn't know any better, and
the more advanced can still explicitly say when and where to convert
the bitmaps.

And I think tags can be useful, but I agree that the user could just
manage that themselves. Probably better that way since Allegro doesn't
normally get too high level like that.

--
Matthew Leverton




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