| Re: [AD] al_convert_bitmap |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, Jun 15, 2011 at 1:19 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>
> They should be 0x0 bitmaps without any data associated.
>
> We should allow al_create_bitmap to create 0x0 bitmaps anyway
> (if we don't already).
>
Yes. Still, you have to call al_destroy_bitmap on them or you leak the
ALLEGRO_BITMAP struct when the display is re-created. So the
difference is just that with the zombification the user can destroy
them after al_destroy_display - else we'd force them to destroy them
before al_destroy_display (or not at all as we'd do it in
al_destroy_display - just the pointers would get invalidated that
way).
>
> I don't care for auto-conversion anyway so I'm still hoping you will
> remove it from al_create_display and retract
> al_convert_all_video_bitmaps...
>
Well, my problem is always that personally I don't care too much
either as I'm mostly using Allegro through my wrapper which doesn't
support multiple windows and already handles on-demand re-loading and
on-demand texture-uploading of bitmaps.
But for someone new to Allegro I feel it's hard to understand why the
order of al_create_bitmap/al_create_display should matter. And on
secondary thought why calling al_destroy_display followed by
al_create_display would cause a massive slow-down for no apparent
reason. We shouldn't expose technical details to the API that way.
I kinda would see an appeal in if we had gone a really low-level route
from the beginning. Do not keep a list of bitmaps in each display.
Have al_create_bitmap return NULL if there is no ALLEGRO_MEMORY flag
but no display. Get rid of the ALLEGRO_NO_PRESERVE_TEXTURE flag and
have the user handle their list of video bitmaps whenever they
re-create a display or get an ALLEGRO_EVENT_DISPLAY_LOST message. But
the way it is in 5.0 we already made things quite user-friendly, just
leaving that one issue where bitmaps can sometimes silently end up as
memory bitmaps.