Jump to content
Posted 24 March 2011 - 03:37 PM
Posted 25 March 2011 - 03:47 PM
Thanks for the reply. I'll admit I'm hoping there's another solution though :)
Try using pre-multiplied alpha instead?
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.
Posted 25 March 2011 - 03:56 PM
Posted 25 March 2011 - 04:19 PM
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.
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.
Posted 25 March 2011 - 09:30 PM
Posted 25 March 2011 - 10:17 PM
Fixing up the images manually is no big deal, but that'd definitely be handy - thanks for considering 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.
Posted 26 March 2011 - 04:24 AM
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.
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.
Posted 26 March 2011 - 12:49 PM
Hehe, don't worry, I believe you - you had me at 'pre-multiplied' :)
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.
Posted 27 March 2011 - 01:16 PM