[Not a bug] Incorrect transparency using the software driver

[Nalin]

There is a problem with transparency and the EDT_SOFTWARE driver. To illustrate this, I'm going to use the CGUITTFont class found on the forums, or right here.

The class has a workaround for the transparency issues. Here is a snippet from the 'void CGUITTFont::draw()' function (overloaded from IGUIFont):
http://irrlicht.pastebin.com/f47546137

The workaround the class provides is to draw each glyph pixel by pixel on the software driver, manually applying the transparency.

Here is what it looks like with the OpenGL driver:
http://nalin.suckerfree.org/public/font_opengl.png

Now with the software driver:
http://nalin.suckerfree.org/public/font_software.png

Now with the software driver, commenting out the workaround so it goes through the normal draw2DImage function:
http://nalin.suckerfree.org/public/font ... around.png

When you create a new font glyph from FreeType, it returns an alpha mask. The class takes the color black and applies the mask to it. After that is done, it calls:
Driver->createImageFromData(video::ECF_A8R8G8B8, ...);

Then it converts the IImage into a texture. That texture is then used to draw the font. For some reason, the software renderer isn't drawing the texture correctly when it is passed through draw2DImage().

[hybrid]

The SW renderer has no blending, so it cannot do any better than cropping the pixels at some threshold. It's not really a bug, but a limitation of that renderer.

[Nalin]

Well, that is good to know. It was a little confusing because it sent the execution to different places depending on if it was to use alpha blending or not.

I guess the workaround will have to stay.

[hybrid]

Actually, the SW driver only has one alpha bit (as it uses 16bit textures with A1R5G5B5), hence this very limited version of alpha blending.