I'm doing semi-transparent windows in my game, and i just wonder if i can optimize this code.. cause it kinda slows down the FPS when drawing many windows at the same time ...
i'm using 16bit colormode

code:
void WINDOW::draw_16(int x, int y, int width, int height,
int color, int alpha_start, int alpha_end)
{
int virtual_offset = x + y * 640;
int virtual_offset_add = 640 - width;
short X;
short Y;

int r;
int g;
int b;

int new_r;
int new_g;
int new_b;
float alpha_div;
float alpha = alpha_start;
float alpha_factor = ((float)alpha_end - (float)alpha_start) / (float)height;
// default-values for a good-looking blue-blended window
// int alpha = 100;
// int color = makecol16(0,0,255);
// extract rgb components
new_r = getr (color);
new_g = getg (color);
new_b = getb (color);
// lock bitmap
acquire_bitmap (virtualscreen);
// get pointer
short dst = (short) virtualscreen->dat;
// process all pixels
for(Y = 0; Y < height; Y++)
{
for(X = 0; X < width; X++)
{
r = getr(dst[virtual_offset]);
g = getg(dst[virtual_offset]);
b = getb(dst[virtual_offset]);
alpha_div = alpha / 255;
dst[virtual_offset++] = makecol(
r + (new_r - r) * alpha_div,
g + (new_g - g) * alpha_div,
b + (new_b - b) * alpha_div);
}
alpha += alpha_factor;
virtual_offset += virtual_offset_add;
}
// release bitmap
release_bitmap (virtualscreen);

// draw border
rect(virtualscreen, x, y, x + width - 1, y + height - 1, makecol(120, 120, 120));
rect(virtualscreen, x+1, y+1, x + width - 2, y + height - 2, makecol(255, 255, 255));
rect(virtualscreen, x+2, y+2, x + width - 3, y + height - 3, makecol(120, 120, 120));
}

any idea how to speed things up?

yeah of course .. releasing after the rect should do something .. how silly of me .. but anyhow, is there a better (faster ) way than going pixel by pixel?

OK, but hey, plz ppl tell me about mmx and sse!! I don't really know how they work ( or I have some idea but I'm sure it's not as powerful thingy as u can offer ) So does anyone know something about them??

your inner loop has this code:
code:
r = getr(dst[virtual_offset]);
g = getg(dst[virtual_offset]);
b = getb(dst[virtual_offset]);
alpha_div = alpha / 255;
dst[virtual_offset++] = makecol(
r + (new_r - r) * alpha_div,
g + (new_g - g) * alpha_div,
b + (new_b - b) * alpha_div);

some changes to make:
1. The most obvious: move the line "alpha_div = alpha / 255;" out of the
inner loop. A good compiler might do this for you in this example, but in more
complicated examples the compiler might not have enough information.
2. Nit-picky details... since you seem to be hardwired to 16bpp anyway (though that
could also work on 15bpp...), you can replace the getr, getg, getb, and makecol
with their 16bpp specific versions.
3. Maybe I'm confused, because it's been a little while since I've done much with
Allegro, but I think that your acquire_bitmap and release_bitmap pair
aren't doing much... they're supposed to only do things if it's a video bitmap, and
your direct memory stuff won't work on video bitmaps anyway, so they are never
useful in this code. If you want to make this able to write to video bitmaps you need
to do extra stuff like bmp_select, bmp_write_line, bmp_write16, etc.
4. In that loop you multiply by alpha_div 3 times... which isn't too expensive... but
using the results in a makecol() call converts them to ints right afterwards. You
might be better off starting with ints, and doing something like this instead:
code:
//second to innermost loop
int new_r2, new_g2, new_b2, alpha2;
new_r2 = (int)(new_r * 256 * alpha / 255.0);
new_g2 = (int)(new_g * 256 * alpha / 255.0);
new_b2 = (int)(new_b * 256 * alpha / 255.0);
alpha2 = (int)((255-alpha) * (256.0/255.0))
//now the innermost loop
for(X = 0; X < width; X++)
{
r = getr16(dst[virtual_offset]);
g = getg16(dst[virtual_offset]);
b = getb16(dst[virtual_offset]);
dst[virtual_offset++] = makecol16(
(new_r2 + r * alpha2) >> 8,
(new_g2 + g * alpha2) >> 8,
(new_b2 + b * alpha2) >> 8);
}

actually, on second thought... maybe that's kinda complicated... I think I premultiplied
the new color, used a little fixed point math, and got everything into integers
before the inner loop. I haven't tested this code... (BTW, the >>8 just means a
division by 256... it's really fast, but it only works on integers... it also rounds
slightly differently than the normal division if the integers are negative, but
that shouldn't happen here)
5. Anyway, it can be done faster with MMX (I don't know SSE, but maybe that also), but
you're probably better off just using FBlend or whatever.
[ October 17, 2001: Message edited by: orz ]
[ October 17, 2001: Message edited by: orz ]

Thanks a lot for all intelligent answers ...
I'll get right to the optimizations
korval:
uh.. do all cards support it? if so, how do I do it? is it in the allegro docs?
Graphicprogramming isn't really my table :/

I assumed that hardware blitting would support alpha transparency if avaliable.

And, I also assumed that if it didn't, then Allegro would use an assembly optimized blitting loop.

This thread is a nightmare to read.

1. If there's a way for me to edit my post, I don't see it.
2. Um... when I wrote that message, there were a few more line breaks in it,
at least in the code section at the top...
It would be nice if the editor displayed things with some resemblance to how they are
going to appear. Or at least offered a preview button.

I see a message icon at the top left of each post, but it's not a link.
I see a few more icons to the right of that, one of which looks like a pencil with a paper,
but that's the reply button... nothing else I see looks anything like that.

yes, I feel stupid now. I coulda sworn I tried that button several and used it to reply...
anyway, I've fixed the obnoxious formating of my post.