Full sampler state defined in shader is applied, not only set properties

[vchelaru]

Setting GraphicsDevice.SamplerStates[0] = SamplerState.PointClamp; results in point filtering applied in XNA 4.0 PC, but the same code/shader result in linear filtering in Desktop GL.

To reproduce the bug:

1. Download https://drive.google.com/file/d/1U-JU5iEKw-fEAXOLDuqDxcjxIDhvTKkU/view?usp=sharing
2. Unzip the file to a Windows 10 machine (XNA will be required to compare XNA behavior)
3. Open XnaCompare.sln (located in the root of the unzipped folder)
4. Run the project
5. Observe that the rendered quad has point filtering (hard edges between pixels)
6. Open DesktopGlShaderTest/DesktopGlShaderTest.sln
7. Run the project
8. Observe that the rendered quad has linear filtering (smoothed pixels)

Note: Both projects use the same shader file, but the shader file is added directly as an XNB file to the DesktopGL project (due to a missing feature of linked files in the content builder). I did try building the shader with the latest dev build of the content pipeline tool - I don't know if the bug is caused by the pipeline tool or MonoGame runtime.

This was tested on a Windows 10 machine with the following hardware:

• i7-8550U CPU @ 1.80GHz
• 16.0 GB ram
• 64 bit OS
• NVIDIA GeForce 940MX

What version of MonoGame does the bug occur on:

• MonoGame 3.7.0.1657

What operating system are you using:

• Windows

What MonoGame platform are you using:

• DesktopGL, compared against Microsoft XNA 4.0

[harry-cpp]

I came across something that is probably related to this bug, calling:

_spriteBatch.Begin(samplerState:SamplerState.PointClamp);
_spriteBatch.End();

has an effect on how all future shaders get rendered..

[harry-cpp]

Turns out, some other stuff leak from SpriteBatch besides PointClamp, yikes.

[vchelaru]

For what it's worth, in this case I'm not using SpriteBatch anywhere in the project, so...maybe not the same bug?

[Jjagg]

@cra0zy SpriteBatch is not supposed to reset graphics state after ending a batch. It doesn't do that in XNA either.

[harry-cpp]

@cra0zy SpriteBatch is not supposed to reset graphics state after ending a batch. It doesn't do that in XNA either.

Interesting, I never realized that... well at least that explains why the "workaround" is working.

[Jjagg]

I couldn't reproduce the issue. What's likely happening here is the sampler is assigned to another slot than what's expected.

That said the order of samplers sometimes gets messed up when you have multiple of them in an effect. I don't think that issue is actually logged so I'll open a new one.

[Jjagg]

Nope, I was wrong. The issue is actually that we override the sampler state with whatever sampler state is set in the effect file (if any). While XNA only overrides the properties that are set from the effect file, we also override the others with default values. Note that this issue occurs on both DX and DesktopGL.

[vchelaru]

Thanks for looking into that @Jjagg . I was concerned when you said you couldn't reproduce it, as I have a linked project that reproduces it for me.

[Jjagg]

I tested first with a new project which did not set a sampler state in the effect file.

[mattj1]

I know this is late, but I had a similar issue and I seemed to fix it by rendering everything to a separate target first.