al_create_memory_bitmap?
Jonny Cook

Hello there,

First off I just wanted to say how awesome Allegro 5 is. I know it's been out for a while, but I've only now had a chance to check it out and it's really great!

I was just wondering, I noticed that there was a _al_create_memory_bitmap function in bitmap.c, but it currently is private. Is there any specific reason why this method isn't exposed? It seems like it would be a convenient method to have every once in a while. In my case, it was exactly what I was looking for (I only wanted to create one memory bitmap so it seemed silly to change the flags.) Of course, it was easy for me to expose the method, but I'm guessing that if I wanted it it's likely that other people would as well.

Anyways, just wanted to mention it.

Evert
al_set_new_bitmap_flags(ALLEGRO_MEMORY_BITMAP);
bmp = al_create_bitmap(w, h);

Jonny Cook

Right, that's currently the only way to create a memory bitmap. But I was thinking about a use case where the user would only want to create a single memory bitmap. Right now it would be necessary to modify the flags, create the bitmap, and then restore them to the previous state. Of course that's trivial to do, but calling the al_create_memory_bitmap function directly is simpler.

Matthew Leverton

My first impression would be same as yours.

But the user can just do this:

ALLEGRO_BITMAP *create_memory_bitmap(int w, int h)
{
  ALLEGRO_BITMAP *bmp;
  int flags = al_get_new_bitmap_flags();
  al_set_new_bitmap_flags(flags | ALLEGRO_MEMORY_BITMAP);
  bmp = al_create_bitmap(w, h);
  al_set_new_bitmap_flags(flags);
  return bmp;
}

There's also loading a bitmap from disk into a memory bitmap, loading a bitmap into a memory bitmap with loading flags. And why should memory flag get special treatment?

The thing I never really liked is that the flags are set via a state function. I'd have preferred setting them on every create call.

Jonny Cook

Matthew,

Certainly, and I would have ended up creating that exact same function myself had I not found that the function already existed in the source.

I agree that it doesn't necessarily make sense to give this particular use case any special treatment. However, considering the fact that this function already is present in the library, it seems like it might as well be exposed to the user.

Being able to pass the flags directly to the creation function would be nice. Had that been the case I wouldn't have minded the absence of a special function create a memory bitmap.

Thomas Fjellstrom

A lot of the api depends on state, many of which may be stored in global GL type state, and mixing them with api that takes explicit state flags... would cause issues.

The main reason for a set/get flags api is so you only change state when needed. Instead of having to pretty much call the "set state" functions every time you call a function with state flags.

For OpenGL at least, calling those functions can incur quite the overhead.

If you wonder why not just provide it for "set_new_bitmap_flags", there's always consistency. Something we tried to attain with the new api.

beoran

Well, yes the Allegro 5 API has a lot of state setting going on. It can be a bit cumbersome in some cases, but it's very easy in the general case. For example, when drawing the default in Allegro 5 is just what you want: draw to the screen.

For example, in SDL you have to pass the pointer to the display every time. That's pretty annoying, it means you have to drag that pointer around everywhere in all your drawables. That's a big hassle.

The Allegro 5 stateful API is much easier for such cases. Just draw. Allegro knows where you want to draw. The fact that it's also faster is just the icing on the cake. :)

Elias

I sort of wish we had the same distinction between memory-bitmaps and textures though that SDL2 has. By the time the A5 API was designed we still wanted it to run on platforms which do not have textures, so creating an ALLEGRO_BITMAP was supposed to still succeed in such a case.

But thinking now, if we had al_create_memory_bitmap and al_create_texture instead, many things would be simpler. For example al_create_texture would require a display parameter to the display to create the texture for - so there'd be no issues like loading bitmaps before creating a display thus making them slow memory bitmaps :P

Evert

We can always add those functions with those arguments to encourage good behaviour.

Although I would personally find it needlessly confusing.

beoran

Well I think the "unified" ALLEGRO_BITMAP bitmap is easier to work with than having 2 different objects.

The problem of getting slow memory bitmaps at times can be solved by better documentation. Perhpas a macro wrapper around al_get_bitmap_flags() like al_is_software_bitmap() and al_is_hardware_bitmap() could be useful?

Thread #613112. Printed from Allegro.cc