This may be user error, but I've run into a little problem with alpha blending with bitmap fonts generated by BMFont.

To export, I'm using a = glyph, rgb = one. Rather than setting the entirety of the r, g, and b channels to one, this appears only to create a block of white around each glyph. This works fine when the pixel ratio is one-to-one, but if the font is scaled when rendered, dark outlines appear around the glyphs due to bleeding between the white pixels and the neighboring black pixels.

This is easy enough to fix in an image editor by filling the rgb layers with solid white, but I'm guessing there's a reason for the way it's done currently.

Am I setting things up wrong? Is there a particular reason the rgb channels aren't just set entirely to identity?

Alpha blending issue

Try using pre-multiplied alpha instead?

http://blogs.msdn.co...lied-alpha.aspx

I'm not familiar with the output of BMFont, or if the output is set up for PMA out of the box. This is just a passing suggestion.

Try using pre-multiplied alpha instead?

http://blogs.msdn.co...lied-alpha.aspx

I'm not familiar with the output of BMFont, or if the output is set up for PMA out of the box. This is just a passing suggestion.

Thanks for the reply. I'll admit I'm hoping there's another solution though :)

Pre-multiplied alpha aside, I'd like to be able to use typical 'alpha, 1-alpha' blending. Also, I'm just kind of curious as to why the images are exported in that way (it seems like simply setting the entirety of the rgb channels to white wouldn't cause any problems, and would prevent the aforementioned bleeding artifacts).

PMA is the correct way to do things. 'Typical' alpha has always been the wrong way. It just produces artifacts and incorrect results. Setting pixels to white when they are supposed to be transparent is exactly what causes the problem. Transparent pixels should be black.

PMA is the correct way to do things. 'Typical' alpha has always been the wrong way. It just produces artifacts and incorrect results. Setting pixels to white when they are supposed to be transparent is exactly what causes the problem. Transparent pixels should be black.

I don't necessarily disagree. (Or, more specifically, I don't have a strong opinion about it.) I did read the article you linked to, so I'm aware of the arguments, more or less.

Really, it's more just a practicality issue. I have a typical framework set up that uses traditional alpha-blending, it works for everything else, and I'm more interested in moving forward with other things than in making changes to the underlying framework.

I certainly understand that just because something is typically done in a certain way doesn't mean it's the right way to do it. But, 'alpha, 1-alpha' blending is nothing if not typical :) It's been used successfully in countless games and game engines, so I don't know that it's 'wrong', per se. Maybe it's not the best way to do it (as defined by some metric or other), but given the right input, it certainly works ok for many cases.

Anyway, maybe the reason the image is exported in that way is that it's intended to be used with PMA (I'm not sure - I'll have to look into it some more.)

Thanks again for the help :)

Hi,

I didn't have the intention to export the font texture this way, it's just a side effect of how I implemented it. I see no reason to keep it like this, and I'll have a look at it to see if I can change it for the next version. Maybe I'll even find the time to do it this weekend (no promises though).

Regards,
Andreas

Thanks for the reply (and thanks for BMFont as well).

I see no reason to keep it like this, and I'll have a look at it to see if I can change it for the next version.

Fixing up the images manually is no big deal, but that'd definitely be handy - thanks for considering it.

I certainly understand that just because something is typically done in a certain way doesn't mean it's the right way to do it. But, 'alpha, 1-alpha' blending is nothing if not typical It's been used successfully in countless games and game engines, so I don't know that it's 'wrong', per se. Maybe it's not the best way to do it (as defined by some metric or other), but given the right input, it certainly works ok for many cases.

You can tell when games are using the typical technique, because the artifacts it causes can be seen from a mile away. Mostly in games that have a ton of alpha blended vegetation. You can never get rid of the artifacts, you can just screw with your image to try an minimize their appearance. Like adding green around a tree leaf so that you will get an ugly green outline, instead of an ugly white one.

It's wrong because it mathematically produces the wrong result.

PMA will give you the proper results.

But outlines isn't the only area where you get bad results. Read further...

http://home.comcast....d%20alpha%5D%5D
[font="arial, helvetica"]What we think of as conventional alpha-blending is basically wrong. The SRCALPHA:INVSRCALPHA style blending where you do FB.rgb = texel.rgb * texel.a + FB.rgb * (1-texel.a) is easy to think about, because the alpha channel blends between the texel colour (or whatever computed colour comes out the pixel shader - you know what I mean) and the current contents of the framebuffer. It's logical and intuitive. It's also rubbish.

What you should use instead is premultiplied alpha. In DX parlance it's ONE:INVSRCALPHA, or FB.rgb = texel.rgb + FB.rgb * (1-texel.a) (and the same thing happens in the alpha channel). Notice how the texel colour is NOT multiplied by the texel alpha. It's a seemingly trivial change, but it's actually pretty fundamental. There's a bunch of reasons why, which I'll go into, but I should first mention that of course I didn't think of this and nor is it new - it's all in a 1984 paper T. Porter & T. Duff - Compositing Digital Images. But twenty years later, most people are still doing it all wrong. So I thought I'd try to make the world a better place or something.[/font][/quote]

You can tell when games are using the typical technique, because the artifacts it causes can be seen from a mile away. Mostly in games that have a ton of alpha blended vegetation. You can never get rid of the artifacts, you can just screw with your image to try an minimize their appearance. Like adding green around a tree leaf so that you will get an ugly green outline, instead of an ugly white one.

It's wrong because it mathematically produces the wrong result.

PMA will give you the proper results.

Hehe, don't worry, I believe you - you had me at 'pre-multiplied' :)

I'm not resistant to the idea of PMA or saying it's not better or anything like that; I just want the option of using 'a, 1-a' blending for purely practical reasons.

As far as BMFont goes, if I'm not mistaken, it already provides an export mode suitable for PMA; that is, the glyph is written to each of the channels, r, g, b, and a. (That's what you'd want for PMA, right?)

The way a = glyph, rgb = one is currently written out though doesn't really work for either PMA or 'a, 1-a', I don't think. Since PMA is already covered by another mode, I think it makes sense that a = glyph, rgb = one be written out with solid identity in the rgb channels so that it can be used with 'a, 1-a' blending and with scaled fonts.

It's not a comment on what type of blending is better; it's just about having various options available. PMA may be superior to the more typical alpha blending method, but I think it'd be a little much to say that BMFont shouldn't *support* non-premultiplied blending. Since it already does support PMA (IINM), it seems reasonable that the export mode which it seems is intended to be used with 'a, 1-a' blending be implemented in such a way that it's effective for that type of blending.

So, none of this has anything to do with what type of blending is better or should be preferred in the general case. Rather, it's just about making what I suspect is a fairly minor change to one of the export modes in BMFont so that the output for that mode is more useful (the problem being that currently the output is sort of 'in between' what you'd want for the two blending modes and therefore isn't particularly useful for either). Does that make sense?

I've uploaded a new beta version to the site with the fix for the white boxes.

Let me know if you find any problems with it.




to Daaark:

Thanks for sharing the articles on pre-multiplied alpha. I'll probably add an option for exporting the textures with pre-multiplied alpha.




Regards,

Andreas