Re: [AD] Improvements to the graphics drivers

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


> I agree that #1 and #3 are good. I see some usefullness in
> #2 too but
> I'd like to propose a different approach
> 
> In the original suggestion you'd have to load the source
> bitmaps
> first, then put them into the atlas which destroys the
> source to make
> it a subbitmap right?

Right.

> 
> I suggest you make a function that loads from file directly
> into an
> atlas bitmap and returns subbitmap.
> Perhaps it should return NULL if there's not enough space
> left in atlas?
> BITMAP* al_load_bitmap_into_atlas(BITMAP* atlas);

While that does sound nice, it would require the addition of 10+ functions (see the image addon), to cover each bitmap format, as well as additional complexity for the vtables... I don't think it's worth it for this. That being said, originally in allegro.cc I suggested having this be a bitmap creation flag, perhaps that would be more useful? The api/usage would look like this:

ALLEGRO_ATLAS* atlas = al_create_atlas(2048);
al_set_current_atlas(atlas);
al_set_new_bitmap_flags(ALLEGRO_ADD_TO_ATLAS);
//load/create bitmaps, which may now fail if the atlas is too crowded

The only reason you still have the atlas pointer is in case you want to delete it (e.g. after you are done with a particular level). To insert an old bitmap into the atlas, you just call al_clone_bitmap after setting the flag properly.

> As for the al_create_atlas function, I think that's
> unneccesary since
> it's just an al_create_bitmap with one parameter instead of
> two.

Not quite. The ALLEGRO_ATLAS will contain some sort of allocation table/tree to remember where the empty spots are. I think doing pixel searches might be prohibitively slow (and probably infeasible since in truecolor there are no magic colours we could use to signify those empty areas). At this time, the bitmaps don't keep track of its sub-bitmaps so that's out of the question too.

Assuming the bitmap creation flag idea is rejected, how about this then for the bitmap addition to the atlas?

ALLEGRO_BITMAP* al_add_bitmap_to_atlas(ALLEGRO_ATLAS* atlas, ALLEGRO_BITMAP* src);

A little more cludgy, but delegates the source bitmap deletion to the user, so he can take care of the sub-bitmap issues. Those issues, incidentally, only arise if the passed bitmap had sub-bitmaps of their own. Since, as I mentioned above, bitmaps don't have a list of sub-bitmaps it's impossible to transfer them to the new bitmap(same reason why al_destroy_bitmap needs to be used with care with sub-bitmaps).

Using it would work like this:
ALLEGRO_BITMAP* ret = al_add_bitmap_to_atlas(atlas, src);
if(ret) {
   al_destroy_bitmap(src); src = ret;
} else {
   //create a new atlas
}

-SiegeLord



      




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