So, I'm trying to embed some small graphical resource files (in .bmp form) into my executable. The only way I've found to do this is with resource scripts, and loading the bitmaps into the program with the windows.h function LoadBitmap(). The problem is, the LoadBitmap() function returns a HBITMAP handle. And the Allegro library uses its own data type, ALLEGRO_BITMAP *. So, is there any way to load this embedded bitmap using Allegro, or do I have to use external files for my graphical resources?

You'll have to write a function to convert an HBITMAP into an ALLEGRO_BITMAP*. Allegro 4 has these functions, named convert_hbitmap_to_bitmap and convert_bitmap_to_hbitmap. You should take a look at the Allegro 4 source code for these functions to see how they did it, and then adapt them to use Allegro 5 instead.

That seems like an awfully important thing to "forget" to port to Allegro 5...

Anyway, thanks. This should help a lot!

EDIT: Wait... is there any documentation that shows the source code, or am I just going to have to download Allegro 4 and comb through the source?

I've come to the conclusion that for most of your graphics, you should keep your bitmaps separate from your executable. For compactness may want to keep them in a dat or zip file. This can easily be done with the PhysicsFS addon.

The exception I've seen is if you want to set up some kind of system where you get a default fallback when the bitmap you're trying to access is missing. This can make sprint programming easier - a default_sound, default_font, default_bitmap, etc. In this case, you'd want to embed the image in the program.

For windows-specific programs you can do this relatively easily, but for cross-platform code you'll want to embed binary code. Here's an example where I embedded some binary, and loaded it as a memfile.

This is a small 15x15 image. Larger binary data will quickly bloat using this technique. I've experimented with encoding/compressing/decompressing larger images with some success.

for more, search with something like "embed binary image in c++".

That code looks promising... I've already tried loading in images with XPM files, and I already have the code for it (no points for guessing what it's a picture of):

Is there a good way to load in XPM files with the same method?

I don't think there is a native allegro function for loading xpm files. But it doesn't look like it would be to hard to write.

Okay, that leaves one question: how does al_load_bitmap_f load the bitmap from the memfile? Is the memfile just an array of contiguous memory? Does each "cell" in the array represent the color of one pixel? What values should I assign to them to get different colors?

I guess that was more than one question.

If you're going to go the "use only built-in stuff" route, then just convert the xpm to a png or some other supported format and put the array of bytes in your code. If you want to use xpm, then you'll have to write a loader which you can register with the image addon.

Allegro (and most other graphics stuff) pack pixels into (most commonly) 16 or 32 bits per pixel. The easiest way to load that image you have there, assuming you want spaces to be blank and Os to be white, is to do something like that:

const char *myimage = {
   0x200, 0x0, // put width here (this shows 16 bit little endian format)
   0x200, 0x0, // height
   // your xpm here
   0, 0, 1, // continue for all bytes (I'm assuming it's monochrome here, see below)
};

When you load the image, read the width and height then you get to the pixels. If it's monochrome then each byte could represent the color. If you want lots of colors, say 32 bit color, then you'd use 4 bytes per pixel. Look up "endianness" on wikipedia for all the info about storing multibyte patterns in memory. I'll assume you're using monochrome images here.

Allegro let's you grab a memory buffer for an image and read/write to it as an array of bytes which represents the colors. Probably the easiest format to read and write is ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE. Here's some code for loading an image as described above.

Voila, you've loaded a bitmap (though the code is untested). You can simplify it by using al_put_pixel but that's significantly slower if you're using a lot of these bitmaps.

Yes. No. You can't.

That's a png file (which was created using photoshop, and then later viewed as binary in hex in a hex editor). I typed the hex into an array, put it into a virtual file, and then tell allegro to open it like it was png file. You can't just change a value and change a pixel, it's a little more intricate than that.

Since you know the width and height of your image and you know exactly what images you're going to use, there's no need to include that in any new image format you may come up with. And you also wouldn't need to come up with any color definitions, either.

In your case, probably easiest to just make an array of chars, where each char represents a color, getting those colors in a function:

inline ALLEGRO_COLOR get_color_from_char(char c)
{
   switch(c)
   {
      case 'x': return al_color_name("green");
      case 'y': return al_color_name("orange");
      case '#': return al_map_rgba_f(0.5f, 0.5f, 0.5f, 0.5f);
      // etc //
      default: return al_color_name("black");
   }
}

And compose your image with something like this (also untested):

actually.... I profiled some different methods a while back and found that al_put_pixel performed as fast (marginally faster) than packing the bits manually (you have to lock the bitmap other wise it's slow as molasses, obviously). I had a thread on it some time back.

No matter what the performance was too slow for real-time use beyond 10,000pixels/frame or so if I recall correctly. I would only use it for loading and such.

         al_put_pixel(x, y, get_color_from_char(array[x+y]));

Shouldn't that be array[y*width + x] there?

The functions are in allegro\src\win\gdi.c on lines 505-535 and 539-568. They use several helper functions though, so you'll have to look those up yourself. I suggest using grep for windows to do it.

Dangit! I made that same mistake a week ago and it took me ~15 min to debug!

Thanks for all the help! You were right; I already know the size of the bitmap in question, only one bitmap will be loaded at a time, and it's only got two colors, one of which is transparency. So it's pretty simple, I just needed to know how to load it in.

Thanks again!

This won't really help you much but I just had to write some ALLEGRO_BITMAP to HBITMAP code.

I think you can get by with using GetDIBits to go in the other direction, along with some supporting code similar to what I've linked above.

There is a simple way of doing this with WindowsAPI. But LennyLen's code should work for you and his is cross platform load_PE_bmp. It opens PE files and should also get the bitmap data from the executable. He has posted an example of using it and the source is also included so you can see how he done it.

That's quite not possible since al_put_pixel packs the bits itself and then you have the extra function call overhead. If done right (and I've benchmarked this too), manual locking and packing is quite a lot faster. And even if it was inline, you have to pack and unpack pixels into ALLEGRO_COLORs on top of it.