Closed gonetz closed 9 years ago
Technical issue. Hard to resolve.
Paper Mario, same issue
I thought with shaders you can resolve from multisampled render targets/FBOs. :/
Not sure how you are doing it on a technical level but: http://www.learnopengl.com/#!Advanced-OpenGL/Anti-Aliasing
is interesting at least. For my graphics stuff, I am using a FXAA shader as a postprocess for edge reduction.
Yes, it is possible. In fact you have to manually blend samples from multisampling texture in your shader. Sounds creepy, so I left it for better times.
AA breaks the rocket launcher in Conker's BFD and possibly other framebuffer effects in this game
Would it be possible to add a bruteforce method of supersampling as an alternative to combat this?
I know you can set custom resolutions for the glide plugin, eg 960x720. Add two radio buttons above the anti aliasing slider, one that says "Multisampling (default)" and the other that says "Supersampling" (that way people use the original method by default but if they run into problems they can try the alternative).
As for the feature, if Supersampling is selected it takes the multiple and then multiplies the resolution you've selected by this number. If your resolution is 960x720 and your anti aliasing value 4x it'd render at 3840x2800. Then, add a resize (like Lanczos) to that to resize back down to the initial resolution, so 960x720. That way the plugin is just rendering at a larger resolution, then resizing the output down back to the selected resolution and displaying at what the user selected.
It'd be performance intensive and I know a lot of systems could struggle with it, but high end systems could handle it and as hardware evolves it'd definitely become a standard.
I'm not sure how the current method works, nor am I sure how complicated it'd be on a programming level to do this. But would a method like that fix or help the issue?
No. Solution is to resolve MSAA'd FBOs properly.
An example pixel shader of how to resolve MSAA'ed FBOs is as follows:
uniform sampler2DMS u_framebufferTexture; uniform int u_msaaSamples; in vec2 v_texCoord;
vec4 sampleMS(sampler2DMS texture, ivec2 ipos)
{
vec4 texel = vec4(0.0);
for (int i = 0; i < u_msaaSamples; i++)
{
texel += texelFetch(texture, ipos, i);
}
texel /= float(u_msaaSamples);
return texel;
}
void main(void) { // MSAA sampling. vec2 framebufferTextureSize = vec2(textureSize(u_framebufferTexture)); ivec2 itexCoord = ivec2(framebufferTextureSize * v_texCoord); vec3 Color = sampleMS(u_framebufferTexture, itexCoord).rgb; //do shit with Color ......................... }
Removes the need for a intermediate FBO to resolve to, since MSAA resolving is done in the pixel shader.
Thanks mudlord! Yes, MSAA must be resolved in shaders and I planned to do that. Current solution with resolve to texture is temporal. Shaders code was in rework when I implemented AA, I did not want to add new level of complexity into it. I think, now it should be not hard to do.
Custom sampling is possible, but it will kill performance a bit, at least if you want to support either linear filtering or mipmaps. @mudlord Don't use "texel /= float(u_msaaSamples);", plese just generate "1/u_msaaSamples" on the CPU.
If you need any filter settings, it's likely worth to do a glBlitFramebuffer call first. Also the common MSAA resolving hardware uses better method than just averaging the samples.
Plugin does not use multisampled mip-mapped textures. The problem arises when frame buffer emulation requires to use multisampled FBO texture as input in shader program. There are cases, where resolving with glBlitFramebuffer is not enough. So the choice is between "imperfect custom sampling" and "no MSAA".
Good work figuring it out and thanks to @mudlord for their contribution!
this is fixed but #249 is not fixed
This issue is fixed, I believe, so it can be closed.
Cap Spy, Night Vision and other full-screen effects does not work with FSAA on