0
\$\begingroup\$

I am working on re-writing an old game, and have faced some issues with the older images that were used, the first thing we done was convert all the old images and set the alpha channel on black pixels so they are transparent, and then built our image libraries. However, the animated images have had some conversion issues it appears the edges of the images were not all set to true black so the conversion never set the transparency on these pixels. The value on the edges varies between R0 G0 B1-16 we have seen but we can't be sure as there is 1000s of images.

If we use additive blending it allows us to blend without showing the noisy outline but the additive blending does not display the images exactly how they should be to reproduce the old style of the game of course.

Question is, what options are available to either fix the image, or render it properly at run time using a HLSL.

I am hesitant to run a conversion on the known black ranges as we might miss a lot out and extending the range might set stuff we should set wrongly. Has anyone faced this before and how did you solve it?

\$\endgroup\$
  • \$\begingroup\$ Hmm... this is unusual. Most games that used non-alpha transparency used a palette transparency instead, with exactly one colour entry marked as transparent. If you're seeing multiple colour values that should all map to transparent, then it sounds like you might be working from a derived version of the assets rather than the originals (eg. ones that got saved with a lossy compression somewhere along the line, or were scaled with interpolation before converting to alpha transparency). Can you include an example of the original & converted assets so we know what we:re working with? \$\endgroup\$ – DMGregory Apr 3 '18 at 9:56
  • \$\begingroup\$ I think you nailed it, I compared the old image and new image pixels but the values are the same in both, so the conversion was fine, but... They were originally 8bit images with only 256 colors, so I guess this black would have blended fine in the original as it blended with a 256 color pallete. Based on that I can modify the converion slightly to workaround this. \$\endgroup\$ – kyndigs Apr 3 '18 at 12:42
0
\$\begingroup\$

It was the default blending state used in MonoGame, I rigged up a custom one as below.

Here is how it rendered before and how I wanted it to render:

Demonstration of blend modes

var blend = new BlendState
{
     AlphaSourceBlend = Blend.InverseSourceColor,
     ColorSourceBlend = Blend.InverseDestinationColor,
     ColorDestinationBlend = Blend.One,
     AlphaDestinationBlend = Blend.One
};

The default blend state uses

ColorSourceBlend = Blend.One,
AlphaSourceBlend = Blend.One,        
ColorDestinationBlend = Blend.InverseSourceAlpha,   
AlphaDestinationBlend = Blend.InverseSourceAlpha,
\$\endgroup\$
0
\$\begingroup\$

Older games used a kind of cheap alpha blending emulation, called "additive blending", where visual effect sprite was just added to pixels in the framebuffer, instead of doing the complete blending equation.

When you see visual effects with black background, and without a hint of an alpha channel, they are meant to be blended using additive blending. You convert these images back into normal alpha-channel images by setting alpha channel to (R+G+B)/3. Similarly, converting alpha channel images into additive blended ones is done by blending on top of black background.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.