Opacity w/Transparency Map??

[capesdev]

Is there any way to plot a surface with a global opacity AND a alpha level opacity ? In other words, I have a sprite that has an alpha map I use to call AlphaBltFast(). However, I want to plot that sprite at increasing levels of fading..to make a 'trail' effect. There seems to be no opacity flag for any of the AlphaBlt*() routines. Would I have to modify the alpha map prior to each call to make this effect?? If so... Johan, if you're reading this thread, pleeeeeaaaasssssse add the dwOpacity multiplier to your AlphaBlt() routines in a future release

Any suggestions ??
Thanks.

[capesdev]

I figured I can make a copy of the alpha map and FillRect() it with black color at varying level to produce the effect...I think I'm losing cycles over just multiplying the alpha and dwOpacity values together tho.

[Johan]

Hi,

I'll add it to my list for 1.1...

Please note though that AlphaBlt is way slower than plain BltFast, since each non-masked pixel have to be multiplied six times (since you don't have the quick 50% opacity mode available).

/Johan

[capesdev]

Johan-
Thanks for the reply. I understand that AlphaBltFast() is slower than BltFast() but I do not know any other way to achieve the effect of per pixel alpha bledning. My game will not involve a large # of surfaces being blitted so I think I'll be ok using a lot of AlphaBltFast() calls. So far, your routines are proving more than fast enought

Regards,
Jeff.

[billcow]

sbl:
You said six multiplies per pixel. I used a significant optimization over this a while back in a DOS program I wrote. You may have already thought of a reason not to do things this way, but here goes:

the optimization comes in three parts:
a.) Re-arrange the equation: a*alpha + b*(1-alpha) becomes b + ((a - b) * alpha). This reduces the number of multiplies by half.

b.) Operate on the red and blue components at the same time. The problem with this part is that it reduces the precision of the blend to 6 bits as opposed to 8. Since the red and blue colors are only 5 bits each, this shouldn't degrade the quality very much, if at all. This also reduces the number of shifts and masks to perform.

c.) Since (I think) all the PPC processors have single-cycle multiplies, this one won't help much, but on other machines (with slower multiply instructions) it might help. Basically, you would take the 2nd step a little bit further; you shift and bitwise the green component to the top 16-bits of the number. The integer would contain the color as follows: 00000gggggg00000rrrrr000000bbbbb. The zero bits would be padding for the multiply. This step wouldn't help much on the PPC, though, since the additional shifts and masks might cancel out the gain from removing one multiply. Also, this would

Like, I said, you may have already tried this and decided it doesn't work. For that matter, I might not be taking into account some obvious limitation of this approach (I do that a lot ). Still, even if you don't use it, someone else might see it and find it useful. And if it does work, two multiplies is a lot faster than six.

[Johan]

Hi Billcow!

Thanks for the feedback! I guess I was too much into avoiding floating point calculations for pixel operations...

Since I don't use FP now, the first equation becomes B*MAX_ALPHA + (a-b) * alpha. Which is probably why I never bothered looking into it in the first place. I guess I don't have any real excuse for not multiplying two color elements simultaneously though..

I'll add it to the V1.1 core, which should increase the speed of all alphas considerably. Please feel free to email me your name/email and I'll add you to the list of contributors! Unless you want me to put "billcow".

Thanks,

Johan