Is that true?

It also says that Alphabyte = 0 = Totally Transparent Pixel.
Alphabyte = 255 = Totally Opaque Pixel.
Is all that true too?

Does anyone have a line or 3 of C code (or English or BASIC or Asm or any other human readable code :) to show me how to correctly alpha blend 2 pixels together?

MegaThanx!

x and y are the source ARGB colors
z is the result ARGB color
mix is the mixing operator

z = x mix y

the mix operator is defined as:

Rz = (Rx * Ax / 255) + (Ry * Ay * (255 - Ax) / (255*255))
Gz = (Gx * Ax / 255) + (Gy * Ay * (255 - Ax) / (255*255))
Bz = (Bx * Ax / 255) + (By * Ay * (255 - Ax) / (255*255))
Az = Ax + (Ay * (255 - Ax) / 255)

I cannot test this code by now

Or does it somehow not matter in that formula?

p.s. 060 does mult in 2 cycles. :)

I am trying to accomplish 2 things:

1. I want my water texture to be somewhat transparent when it is stamped on top of my rock texture.

2. I am adding some extra layers into my game engine, using alphablended masks, so that my GfxMagi can perform feats of black magic with antialiasing, alphablended beveled edges, transparent holes so that one layer may peek thru an upper layer.  etc. etc. ad infinitum.

My general use case is that the bottom texture is always 100% OPAQUE and its alphabyte is irrelevant.

My first version needs to manipulate pixels in the native format of pc gfx cards.  Whatever that is, I can't remember.  For maximum speed on winuae.

Subtle detail: is it a 0.8bit number , or the range 0-1 scaled into 0-255.
src0+((src1-src0)*alpha)/255)  != src0((src1-src0)*alpha)>>8

I think with modern shaders passing vertex data in color values in the range 0-255 really does give you the full 0-1.0 range.

Of course the error might be acceptable, and it's unlikely a program would successively blend without having some higher precision representation somewhere
e.g. i think photoshop uses .16bit.
I've used corel painter X a fair amount you can definitely notice the difference in functionality between it's 8888 brush engine and photoshops' 16:16:16:16 . it tried to get around it with more dithering/noise options

i don't know what all the modes are called but i think photoshop cas this premultiply option you mention. Different blending modes all have their uses.

I do think the OP is right to say that this pure alpha blend (lerp src1 , src2 with alpha) is the most common. I would classify premultiply as a special case, but you're possibly right that it's more useful e.g. for its ability to lighten the image too.  The photoshop tutorials I've seen mention it's ability to handle motion blur better, and for games 'dst*alpha+src' would let you do highlights, lense-flares etc within the same 'blit' as regular opaque/translucent objects

modern graphics would use HDR floating point frame buffers and tone map the results, great if you have  huge amounts of floating point hardware and the ability to go back over your images many times.

i also wanted to mention the PS1/PS2's 'multiply 2X' blending which was used for it's vertex colors simply assuming that the input color range was 0-2 as opposed to 0-1, like a poor mans HDR, able to avoid the 'darkening' effect similar to what you mention, which shows up in some primitive openGL games. (see early quake games with multiply mode light maps... a burnt darkened look)

is Natami getting a SIMD engine :) or is blending going to be built into TAMI

All these years I just assumed that the alpha channel provided real transparency.  But you are saying it is fake transparency?

Real or unreal, fake or imaginary, rational or irrational, I don't care.  I just want the highest quality transparency fx!  Even if it is more complicated and takes longer.

If my fx is 1 pixel worse than Photoshop then my Gfx Dept. will complain at me.

you need to premultiply your textures with your transparence value and afterwards blend with alpha.

I have been studying alphablending all day long.  I came across 4 different sets of people arguing about "premultiplying".  Half the people say "You should always premultiply!  It R0xx0rz!" and the other half say "You should never premultiply! It Suxx0rz!"

I donno what this "premultiply" thing is or how to do it yet.  But I am sure that someone somewhere will be upset with me for either doing it or for not doing it. :D

Doing a simple alpha blend produces false (too dark) colors on average. We don't want that.

Correct.  We want quality.  All these years I thought you were an asm coder.  When did you become an AlphaMage?!

I think the new chunky blitter will support alpha-blending independently of SIMD or Tami.  (Though I suspect Tami will support it in some way.)

presumably any blending hardware will allow both methods.
people will only get upset if you provide less options.
the PS2 was famous for not supporting 'multiply' blend.
THAT made people upset!
the usual opengl pipeline blending modes were..

result=(src * srcFactor) + (dst*dstFactor)

srcFactor can be dstAlpha, dstColor, 1-dstAlpha,1-dstColor, 1, 0,
dstFactor can be srcAlpha, srcColor, 1-srcAlpha,1-srcColor, 1, 0,

then you can do alpha, 'add-mode', 'premultiply'(really just a combination of additive and multiply), multiply, 'screen',

more recent hardware generalizes the blend like shaders so you can do anything you want

so this means the chunky blitter will have ability to array multiply and add..
you know that to an old school coder thats' another arithmetic engine begging to be used for something other than it's intended purpose :)

.. although this topic reminds me of earlier discussions, e.g. 'is it even worth extending the blitter if there's a Tami' and/or CPU SIMD. a modern GUI can make good use of 3d acceleration, just look at Expose on the mac, it's genius.

I think I recall that CPU simd was deemed to be too big a change to the micro architecture.

Wasn't there going to be an additional DSP (robin) and thats' now replaced with a Slave 680x0?

Effectively Alpha is transparency 0 = fully transparent (=nothing drawn) 255 fully solid (replace background)

General formula for additive blending
(src is texture , dst is screen)
Rdst = (Rdst * Adst)/255 + (Rsrc * Asrc)/255 ;
Gdst = (Gdst * Adst)/255 + (Gsrc * Asrc)/255 ;
Bdst = (Bdst * Adst)/255 + (Bsrc * Asrc)/255 ;
Adst = 255; (usually)
So for example is Adst =127 Asrc=127
You will obtain a mix of 50% source (Asrc)  on 50% dest (Adst)

Often you want to use the alpha factor that is in the texture pixels
and the complementary alpha value for screen it is the GL formula
SRC_ALPHA,ONE_MINUS_SRC_ALPHA
Asrc=tex.A
Adst=255-Asrc;

if the texture dont have a per pixel alpha value (ie just want to 50% src 50% dst) then can use a precalutated table

if the texture is only used with same alpha formula
(never used as solid texture) then better to  premultiply your textures with your transparency value:

For (all texture pixels)
{
Rsrc = (Rsrc * Asrc)/255 ;
Gsrc = (Gsrc * Asrc)/255 ;
Bsrc = (Bsrc * Asrc)/255 ;
}
then do the effect
Rdst = (Rdst * Adst)/255 + Rsrc ;
Gdst = (Gdst * Adst)/255 + Gsrc ;
Bdst = (Bdst * Adst)/255 + Bsrc ;

Alain Thellier

BTW
Natami should have a new CPU instruction (3dcore) ADDMUL8 defined like that
Register UBYTE src,dst,x,y;
UWORD tmp;
  {tmp=(x*src)/255+(y*dst)/255; if(tmp<=255) dst=tmp; else dst=255; }
That can serve for several transparency effects

Saturation arithmetic, like early MMX instructions.
I wrote this almost 2 years ago..