Without even looking at your code I can tell you that the choice of GPL instead of the Allegro license will severely limit the acceptance of it...

This code is currently GPL licensed as it is part of UFO2000 project right now (which is GPL licensed itself). In the case if it becomes addon library or gets (partially?) included into allegro library, it will have allegro license of course

That's why I posted it here and wait for feedback. If no feedback is received, it will remain a part of UFO2000 (see option 3) as I don't feel like doing useless work. The scope of this code is currently fast and portable 16bpp alpha blending for mem->mem blitting of RLE sprites (needed on Nokia 770) and it seems to serve it well. Depending on community interest, it might grow into something more useful

Also my intention was to eventually make some patches ready for inclusion into allegro improving RLE sprites support. Alpha blending is slow in allegro mostly not because it is not MMX or whatever optimized, it just uses callbacks that slow everything down (see problem 1). Probably some standard blenders could be inlined into some special versions of optimized functions, alpha blender is the first candidate, but that would not serve UFO2000 well as there is no standard blender for what it needs (see problem 2). So improving performance of current allegro API would solve only some problems (but if these changes get accepted, that would be also good).

PS. Test program which verifies both performance and correctness (by comparing results of optimized and standard allegro blenders) is included, so it should not be too hard to try it.

I'll try it, thanks edit: Tried, it really speeds up the program, but only about 5% (maybe I just have a fast cpu with slow memory and memory is the bottleneck). In addition it requires 'inline' changed to 'INLINE' for BlendColorsNoEmms, otherwise it actually gets even slower ('inline' unfortunately is only a hint for gcc and it seems to ignore it):

#ifdef __GNUC__
#define INLINE inline __attribute__((always_inline))
#else
#define INLINE inline
#endif

By the way, one more improvement (but not related to alpha blending) and which is also not very portable is to add support for compiled sprites. When checking for clipping, there is a place in the code where we are sure that the sprite is not clipped at all. And it means that we can add <b>COMPILED_SPRITE member to ALPHA_SPRITE struct, initialize it for the sprites which do not have alpha channel and use them when no clipping is needed -> improve performance when no blending or tinting is required, but also increase memory requirements.

After having a second look, appears that I deceived you somewhat. Compiler seems to inline BlendColorsNoEmms() fine on normal code.

But in my 'sprite.cpp' I heavily use that '__attribute__((always_inline))' option in order to force inlining, otherwise gcc refuses to inline some of the functions containing loops, but they still affect performance much (maybe it wouldn't if used with profile guided optimization though, but that's not convenient). Anyway, in this particular source file with lots of functions with forced inline, gcc seems to take a revenge on BlendColorsNoEmms() function and DOES NOT inline it if it does not have that '__attribute__((always_inline))' That's weird.

It also by default doesnt inline most things with loops, generally because it'll make the size of the code explode to insane proportions. (since loops are unrolled..)

I'm interested and I'm going to take a look at it.
...
uhm... well, the explosion sprites I have don't have an alpha layer, so I can't use the alpha thingy, until I get a replacement from "somewhere" - sorry, that can take a while.