/* Else it's a display bitmap */

   bitmap = current_display->vt->create_bitmap(current_display, w, h);
   if (!bitmap) {
      TRACE("al_create_bitmap: failed to create display bitmap\n");
      return NULL;
   }

It apparently returns NULL.

Nothing is compatible with magic pink unless you explicitly convert that color to alpha zero. (Allegro provides a function for that.)

You could do that or you could use memory bitmaps for non-important graphics:

al_set_new_bitmap_flags(ALLEGRO_MEMORY_BITMAP)
ALLEGRO_BITMAP * foo = al_create_bitmap(1024, 1024); // Now it's a memory bitmap. 

Of course, there would be speed penalties for such.

You could always write a wrapper around al_create_bitmap that tries to create a video bitmap, and if that fails, creates a memory bitmap. Shouldn't be too difficult.

Yeah, no datafiles. But it supports Zip files, guess you can't win em all

It's not, really. Just different.

It's not like 4.3 had "bitmap management" either. I for one thoroughly endorse 4.9/5.0. It's a breath of fresh air.

Now all we need is an a5_cg module.

I'm not complaining, I was just asking whether fancy bitmap management was taking place.

Out of interest, once we're all up to speed with A5 and shoving out best-sellers like there's no tomorrow, at what level of graphics card should we expect people to have, e.g. if I write a program that requires 60mb of graphics and I expect it to all fit into video memory is it too unreasonable to abort out if they don't have it to save on a caching algorithm, or if my graphics aren't to the power of 2 and their card doesn't support it, etc

That's usually the case, or just let them play it with memory bitmaps handling the overflow and accept the low FPS. In terms of the non-power of 2 textures, A4.9 handles them automatically (by embedding them in the next highest power of 2 texture).

You can use sub-bitmaps to manually break up a big texture into little textures, but there isn't an automatic mechanism to stitch multiple bitmaps into a bigger one. That does sound like a good idea to me though (perhaps as a fancy new bitmap flag? or ALLEGRO_BITMAP al_create_atlas(int width, height, ALLEGRO_BITMAP** bmps)?).

Won't at least the OpenGL target get automatic texture swapping on account of OpenGL having automatic texture swapping? In which case maybe it would make sense to expose glPrioritizeTextures, especially as it's effectively just a hint that a driver can ignore?

An automatically generated sprite sheet. Basically, the inverse operation of creating a sub-bitmap.

Nice. Learn something new every day, heh.

A5 currently runs fine on GP2X Wiz and IPhone, so I'd say pretty low. Basically anything which claims to run either OpenGL or Direct3D will work. Performance really doesn't depend on A5 itself much, it's a very thin layer over those two.

This sounds like a good idea. It also would simplify the font addon which already does this for the glyph cache - it could then just use the normal API for it.

Maybe the API could instead be:

al_enable_texture_atlas(int width, int height);

Then while it is enabled, calls to al_create_bitmap (without MEMORY flag and not of bigger size) would instead return a sub-bitmap to a video bitmap of the given size - allocating new bitmaps when needed.

It would be the same as the ALLEGRO_BITMAP** version, except that the user wouldn't have to memory-manage an array of pointers... not sure how much of a different that makes.

Someone wants to write a patch for it? Maintaining the free space within the big textures is the main problem I see - is there any good algorithm for it? Basically it should be fast but not waste too much texture space...

Also, related to this, we might want to add a retained drawing mode. E.g. drawing a tilemap could then be done like this:

al_start_retained();
for (;;) { for (;;) { al_draw_bitmap(...); }}
al_render_retained();

Instead of issuing one glDrawArrays() command for each al_draw_bitmap, the whole tilemap could be drawn with a single glDrawArrays() in al_render_retained(). The problem is, it would only work properly if bitmaps with different textures don't overlap - but we could warn of that in the documentation.

I added this in my local git-svn branch some time ago and drawing a screen full of text ran with 2.5 times the FPS compared to without, which is nice. However, users can already optimize it themselves by using al_draw_prim() or by using OpenGL directly... so not sure we need it.

Surely it's the bin packing problem and therefore NP-hard? There's a whole bunch of heuristics, but I think most of them rely on you knowing the complete set of objects to be packed in advance... given that we can't do that without adding significant API and implementation overhead, maybe it'd be best just to explicitly adopt first fit and advocate that bitmaps to be atlassed are sorted by size prior to being passed to Allegro? Even C has qsort, so that isn't forcing too much logic into recommended practice.