RasterizerState.MultiSampleAntiAlias not implemented

[renaudbedard]

Hi Ethan,

Looks like toggling RasterizerState.MultiSampleAntiAlias has no effect in FNA, it's not used by the GL renderer.

[renaudbedard]

I tried doing similar handing as the scissor test locally, in ApplyRasterizerState :

if (rasterizerState.MultiSampleAntiAlias != multisamplingEnable)
{
     multisamplingEnable = rasterizerState.MultiSampleAntiAlias;
     ToggleGLState(GLenum.GL_MULTISAMPLE, multisamplingEnable);
}

...which should work, and doesn't crash or anything, but it has no effect on my end. Could be my usage of it though?

Edit : Maybe related to this : https://www.opengl.org/discussion_boards/showthread.php/172025-glDisable(GL_MULTISAMPLE)-has-no-effect

[flibitijibibo]

For whatever reason GL_MULTISAMPLE is a best a hint and at worst a complete waste of time depending on what driver and hardware you're using. We're both on NVIDIA hardware which completely ignores this value.

I looked into items that are related to this (glSampleCoverage and its related enable/disable enums), but it seems like it really is down to the FBO attachments.

The only obvious way we can resolve this is to actually use the texture instead of the renderbuffer that is part of the RenderTarget object; since RasterizerState is checked every draw, we could try to find a way to verify the attachments when RasterizerState.MultiSampleAntiAlias is toggled, and attach the right item at SetRenderTargets() depending on the current RasterizerState. But, keep in mind that we would still need to resolve what's on the renderbuffer, so you'd have to deal with merging the antialiased with the aliased. This could mean not only resolving from the renderbuffer to the texture, but also from the texture to the renderbuffer should the game decide to go back-and-forth before finally unsetting the target. glBlitFramebuffer's kinda cheap, but that many blits can add up fast.

I'm not sure who decided that an essential GLenum wasn't worth actually following, but hopefully they don't work anywhere important anymore.

[flibitijibibo]

Something else to consider is just reallocating the renderbuffer storage to not be multisampled when multisampling is disabled, but A: I don't want to think how slow that'd be to resolve and reallocate for each change, and B: I dunno if the driver would be smart enough to handle the data being realloc'd for the current attachment handle.

[flibitijibibo]

For completion reasons I've at least added the GL toggle to the OpenGLDevice...

https://github.com/flibitijibibo/FNA/commit/54dc08f55a7159f1f18126d454d0ddfb93788a57

... so at least this way it is 100% the vendors' fault and not ours. I'd like a real solution though.

[flibitijibibo]

Oh god I just thought of something really stupid.

If you can find a game on Windows that used glDisable(GL_MULTISAMPLE) for their MSAA support, you might be able to rename the executable to that of the game, and it'll actually work like it's supposed to.

Maybe doom3.exe can save us yet again? EDIT: Well, not Doom 3 anyway. Checked the GPL release and it's not there.

[sulix]

Have you set the SDL_GL_MULTISAMPLE{BUFFERS,SAMPLES} attributes before creating the context? Not that I can think of any time that's actually worked, but maybe you'll be lucky.

[flibitijibibo]

We actually don't use the backbuffer for any multisampling; all of that rendering is done exclusively with renderbuffers either in the RenderTarget or in the faux-backbuffer.

The funny thing is that it has the exact opposite problem as the real backbuffer in that it's almost impossible to disable multisampling, whereas the backbuffer requires voodoo magic to enable at context creation (as you pointed out).

[flibitijibibo]

This issue has been discontinued in favor of the new repository:

https://github.com/FNA-XNA/FNA/issues/3