Here's a suggestion: you can create the alpha channel out of the light intensity of every color. The equation for this is:
light = (red * 30 + green * 59 + blue * 11) / 100;
Or to speed it up:
light = (red * 77 + green * 151 + blue * 28) >> 8;
Then you can just use the light intensity as your alpha channel.

oops I meant 0x7F7F7F instead of EFEFEF of course hehe...and I haven't seen that you were about to go for 16 bit per pixel, my example were in 24 bpp...
however, use 0x7BEF as bitmask for 5:6:5 16-bit 1/1 average blending bla bla...

No, these methods dont seem to work, they give the entire glow a blackish tinge, I would suggest you download the 70k program from
http://www.geocities.com/lazy_coder/code/src.zip
it will explain the problem clearly.
note that gimp does this easily if you draw the glow on a seperate layer, then you can change the background layer as you like and gimp keeps the sprite blended with the background

hmm...what programs like gimp, psp or photoshop do when blending two layers together, is that they have a seperate alpha value for every single pixel, and then they blend the pictures pixelwise, not the whole layer with just one fixedalpha value.
I think one way to get rid of your problems would be to introduce this alpha channel to some of your sprites, allegro already has its own alpha sprite billing routines (wich are unfortunately quite slow). So things like explosions, that are transparent, would have yet another color channel, do determine wich weighting the pixels get at blitting-time, and this usually leads to the best results (for example, an explosion should look solid (alpha = maximum) in its middle, and then kind of "fade" out to the edges (alpha slopes to it's minimum)). but, as you surely can imagine, this way is slow, because of the extra data (not really a problem with 24bit color depth, where there's a nice free byte to put the alpha into, but with 16bit or 15bit color resolution it's getting quite difficult, you see..), and also because of the expensive alpha blending process per pixel.
hey, right now I'm trying to code somekind of alphablending routines that base on the quite fast but lossy method of bitshiftings etc(as seen in my 50%/50% example above). what I'm doing now is to make up a couple of similliar routines, for example 25%/70% or even 12.5%/82.5%. atm I'm at the 12.5% ones, and I make a lot of them so I get (for first testings) 6 different routines for the different weightings(plus 2 routines wich do nothing and just either pass color one or color two for the 100%/0% like cases). then I for example store their function pointers in an array with size of 8. when blitting, every pixel's alpha values could be shiftet by 8 (to loose one byte...) so it's in range of 0..8 - now it's plugged into the array and thus calls the right function for the rgb-values to be mixed. what do you think, could this be fast? I know that only 8 grades of alpha is not enough to always look convincing, the number of blending grades could easily enhanced by power of two (16 grades(I'm just working on that)...32 grades(anyone want to write all that stuff??? ...).
anyway, I'm no pro at all, it's just been some silly idea I had (and in case it's been a good one and nobody had it before, I do state now that I'll visit anyone who claims this idea to be from him/herself at night when he/she is sleeping, and I will also make some experimentations with him/her about heart-extraction from a human chest with just a chainsaw and 15 hot needles ;-)