Multiple problems with latest build

Hi guys,

I have moved development onto my gaming laptop so I can work on holiday. Yes I am a very sick puppy.

So my problem with Texture2D.FromStream came back.

The offending code is in

private unsafe static Texture2D PlatformFromStream(GraphicsDevice graphicsDevice, Stream stream)

        // XNA blacks out any pixels with an alpha of zero.
        fixed (byte* b = &result.Data[0])
            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.

This code ends up ruining the display

So I downloaded the latest source code and something has gone wrong. NuGet errors out immediately, so I cannot get the dependencies and hence cannot fix the issue myself.

Can we discuss why this code has been added? It’s wrong.


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

I managed to get it to build

I deleted everything
used git bash to get everything
then ran protobuild from the command line instead of double clicking on it

don’t know why I had to do that

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.

The issue is probably the build settings on your texture processor. I believe that you can disable this behavior by setting the format to ‘no change’.

He’s using Texture2D.FromStream, which is not tied to the content pipeline.

Jjagg is correct. You don’t get an option to disable it.

I actually raised a bug about something similar in XNA 4.

Digging in the memory bank it was a problem with pre-multiplying alpha.

Paint.Net defaults to transparent white 0x00FFFFFF and when you anti-alias scaled images against a white background that used to be great.

In XNA 4 they had a bug that this got replaced with transparent black and this caused issues.

So we could leave it in if we want to emulate bugs in XNA … :yum:

However this is Monogame not XNA and I certainly hope we can get rid of bugs.

Ow and I found this bug in XNA a long time ago

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.


Very probably.

When Microsoft introduced pre-multiplied alpha it caused all sorts of problems.

They obviously did it because they wanted XNA on hand held devices that had low power GPU’s, but the way they did it was just stupid. By this time I think most people on the project knew XNA was dead.