Re: Alphablending

Okey. Now I understand a bit better. So I am slow. you actually use the
alfa channel within the picture itself for storing alfa values?

Yes, the tga file is 32 bit per pixel and there is per pixel alpha.

Ok, but when I do this in memory, my images does not use any alfa in the
imagedata itself. Is it absolutly needed? Does it speed things up? offer
more options? I am not sure I understand why you need alfa values inside
the image data.

The alpha isn't needed if it isn't used, if you use constant alpha only
then you don't need per pixel alpha. Alpha blending does not always
even use alpha as multiplier for the two colors that are being blended,
the colors can also be multipliers, then per-channel modulation is done
(red*red, green*green and so on). Both alphas and colors can also be
inversed (1.0 - value), then there are two constant multipliers: zero
and one.

For example, if you are doing additive blending you set the multipliers
to (one,one) so the formula becomes:

r = colorA * 1.0 + colorB * 1.0 = colorA + colorB

If you want to use PER PIXEL ALPHA, you want to use the source_alpha or
inverse_source_alpha as multiplier. You can also use dest_alpha or
inverse_dest_alpha but that is not so commonly needed (but still
possible).

So there are a lot of multipliers you can use:

0.0
1.0
source_alpha
source_rgb
1.0 - source_alpha
1.0 - source_rgb
dest_alpha
dest_rgb
1.0 - dest_alpha
1.0 - dest_rgb

That's ten different multipliers you can use. In the demo you can
choose the multipliers for both source and destination (buffer) colors
and see what happens, there are 100 different combinations.

Ok. So you have two (3) alfa inputs. One in the image(s) it/themself? and
one "global" (constant) modulator? Ok.

Roughly correct, there is per pixel alpha from the sprite, then per
pixel alpha from the background image (does have all pixels alpha set
to full as jpg don't store alpha). That's two. Then constant which
scales both, that's two more so in total four.


This makes more sense then.
Because I then use only the gobal modulator,
since I apply the same function to
each pixel. Is this somewhere near correct?

Sounds like what is happening. I want to point out that you probably
didn't outright notice the blending on my version as there it was
rendering quality issue, not really special effect such as transparency
(though you can get this result if you modify the alpha channel in the
leaf.tga file, make the alpha weaker and the leaf will be transluceny).
Infact the leaf IS translucent at the *edges*, the edge pixels blend
smoothly to the background so there is no sudden "cut" where the sprite
"ends" and background color "starts"

The leaf is moving too fast to really notice it, I suppose..

Okey. I think I understand more fully now. Thanks. You have actually a PER
PIXEL alpha. whereas what I use, in my code is a PER IMAGE alfa. but I
guess this can be worked in.

Yes, I use multipliers which use the sprite (leaf.tga) picture's per
pixel alpha in some ways to combine the two images.

I can email the .asm source for the alpha blending (all 100
combinations!), if you want RosAsm version if you like. The sourcecode
been Open Source for the past five years and the license states that
modifications are okay.

Btw. I worked on software rasterizers for years and alpha blending was
last stage of pixel pipeline before writing the color into the
framebuffer. There were already 100 combinations of alpha blending
alone, so there was simply too much code to write "by hand" in assembly
(!) to make renderer that does everything you want.

I solved this by writing assembler code in small pieces, then combining
the pieces to form the final code when I knew everything. I use the
"alpha blending" as example, when I knew what blending was used, I took
that piece of code and appended to the end. Ofcourse there were issues
how to keep variables in registers and so on, which were quite easy to
solve: I used "virtual registers" and allocated real registers later..
when ran out of registers I did use memory as temporary storage (this
is called spilling I know now years later as studied compilers and
worked on some ;)

This "stitching" technique is quite primitive, actually it is far
superior to compile and optimize the code after see the pixel drawing
innerloop as a WHOLE. Ofcourse, I didn't do function call per pixel,
for me the primitive was "scanline", even better primitive would been
vertical slice of the triangle but problem was that the code became a
bit too large for my tastes.

Interesting bit, if you ever doing triangle rasterizer is to keep the
outer loop simpler is to use barycentrics and solve only the varyings /
interpolators you need, this way the outer loop is identical no matter
how many interpolators you got, the only difference is the amount of
vertex values you need to store. A fixed maximum of 4 (low number, I
know) worked great back then... two texture coordinates, and two
colors.. novadays that would be ridiculously low number. (z and 1/w
were always done fixed).

Blah blah.. I am going boinkers.. this is most fun stuff to program I
ever done so sorry if get started.. just saying that is why I don't
write assembler by hand very often, heh. :)

.

Relevant Pages

  • Form background with per-pixel alpha?
    ... Is it possible to create an irregular window with per pixel alpha so that it ... blends in to the desktop at the edges? ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Does RISC still offer a significant numbercrunching advantage?
    ... Nitpick - Alpha never had two full sets of FP multipliers and adders. ... The shortage of architected register is secondary to that esp. ...
    (comp.arch)
  • Why are shadebobs and 2d alpha blends so convincing?
    ... It's an alpha blending and color rotation trick ... textures floating around (with high alpha values for a transparency ... effect (shadebobs appear to combine together but it's not an explicit ...
    (comp.graphics.api.opengl)
  • Re: Transparency fog?
    ... > Just use a vertex shader and alpha blending. ... Microsoft DirectX MVP ... reflect the official views of the Microsoft Corporation. ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: Problems with Z-buffering
    ... Thank you for the new suggestions regarding alpha blending. ... the backface culling mode is ... > before you render the object and see if it makes any difference. ...
    (microsoft.public.win32.programmer.directx.graphics)