No no, the framebuffers do fully support alpha (if there's such a thing).
The alpha on the circle edge is lower than expected because that's how LÖVE's alpha blend mode works if you blend something (translucent) twice. In this case from an image to a framebuffer and the framebuffer to the screen.
It comes down how the pixels are added together with the blend equation.
Let's say we have the already existing pixel A on the screen, the to be drawn pixel B from the image and the pixel C, which will be the result of A and B blended together. They all have the members r, g, b, and a for the color and alpha values and can reach from 0 to 1 as floating point (instead of 0 to 255).
The alpha blend mode does now the following to calculate the result:
Code: Select all
C.r = (A.r * (1 - B.a)) + (B.r * B.a)
C.g = (A.g * (1 - B.a)) + (B.g * B.a)
C.b = (A.b * (1 - B.a)) + (B.b * B.a)
C.a = (A.a * (1 - B.a)) + (B.a * B.a)
A transparent pixel A does have an effect on a translucent pixel B. This is why the circles have those rough edges once they're drawn to the screen.
We need a new blend mode that blends an already blended source with the destination without affecting the alpha of the source.
There's already a ticket
in the issue tracker by cadahl that proposes such a blend mode. He also linked to this
blog that explains premultiplied blending.
The premultiplied equation looks like this:
Code: Select all
C.r = (A.r * (1 - B.a)) + B.r
C.g = (A.g * (1 - B.a)) + B.g
C.b = (A.b * (1 - B.a)) + B.b
C.a = (A.a * (1 - B.a)) + B.a
Drawing the framebuffer to the screen with this mode gives us the image that we want.
Let the developers know that you want that mode and post a message on the issue
(I don't actually know what I'm talking about. Anyone, please correct me if I'm talking nonsense)