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?

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.

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 :)

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.

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?