// XNA blacks out any pixels with an alpha of zero.
fixed (byte* b = &result.Data)
for (var i = 0; i < result.Data.Length; i += 4)
if (b[i + 3] == 0)
b[i + 0] = 0;
b[i + 1] = 0;
b[i + 2] = 0;
This is incorrect. I have checked as I still have a machine with XNA 4 on it and I don’t have this problem with XNA.
Managed to get the latest from git, and it installs the dependencies… but does not build
Severity Code Description Project File Line Suppression State
Error NU1105 Unable to find project information for 'C:\Research\Monogame\MonoGame\MonoGame.Framework.Content.Pipeline\MonoGame.Framework.Content.Pipeline.csproj'. Inside Visual Studio, this may be because the project is unloaded or not part of current solution. Otherwise the project file may be invalid or missing targets required for restore. MonoGame.Tests.WindowsDX C:\Research\Monogame\MonoGame\Test\MonoGame.Tests.WindowsDX.csproj 1
We’re changing a lot of things in the MG build process, so a thorough clean is probably necessary if you upgrade.
Removing the code that blacks out alpha pixels fixed your issue?
I really don’t understand why we do that. It did improve consistency with XNA, the change came with a unit test and FNA also has the code so I’m pretty sure XNA does something like it.
But I think it’s stupid that we throw away user data. I don’t understand when that could ever be a good thing. The code essentially seems to assume alpha channel is gonna be used for transparency so it doesn’t matter.
You probably mean that Texture2D.FromStream does not premultiply alpha. It makes sense not to do it, because it really depends on your use case if you want to premultiply. If you don’t you’d have to convert back and going back and forth would waste CPU time. But the black alpha pixel thing, I really think we should not keep that behavior.