Converting OpenGL 3.1 code for Multi-sampled Framebuffers to be OpenGL 2.1 compatable

Started by
3 comments, last by tmason 9 years, 9 months ago
Hello,

I have the following code which works well for creating multi-sampled framebuffers for anti-aliasing.

It works great for OpenGL 3+

What can I change to get a multi-sampled framebuffer object for OpenGL 2.1?

Specifically I know I need to use extensions but I couldn't find what extensions I need to use for "glTexImage2DMultisample" as an example that would work on most systems that use OpenGL 2.1.

Thank you for your time.

	glGetIntegerv(GL_MAX_SAMPLES, &NumOfSamples);

	glGenTextures(1, &g_MultiSampleTexture_ID);
	glBindTexture(GL_TEXTURE_2D_MULTISAMPLE, g_MultiSampleTexture_ID);
	glTexImage2DMultisample(GL_TEXTURE_2D_MULTISAMPLE, NumOfSamples, GL_RGBA, l_TextureSize.w, l_TextureSize.h, false);
	glGenFramebuffers(1, &g_MultiSampleFrameBufferObject_ID);
	glBindFramebuffer(GL_FRAMEBUFFER, g_MultiSampleFrameBufferObject_ID);
	glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D_MULTISAMPLE, g_MultiSampleTexture_ID, 0);
	glGenRenderbuffers(1, &g_MultiSampleColorRenderBufferObject_ID);
	glBindRenderbuffer(GL_RENDERBUFFER, g_MultiSampleColorRenderBufferObject_ID);
	glRenderbufferStorageMultisample(GL_RENDERBUFFER, NumOfSamples, GL_RGBA, l_TextureSize.w, l_TextureSize.h);
	glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, g_MultiSampleColorRenderBufferObject_ID);
	glGenRenderbuffers(1, &g_MultiSampleDepthBufferObject_ID);
	glBindRenderbuffer(GL_RENDERBUFFER, g_MultiSampleDepthBufferObject_ID);
	glRenderbufferStorageMultisample(GL_RENDERBUFFER, NumOfSamples, GL_DEPTH24_STENCIL8, l_TextureSize.w, l_TextureSize.h);
	glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, g_MultiSampleDepthBufferObject_ID);
	glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT, GL_RENDERBUFFER, g_MultiSampleDepthBufferObject_ID);
	g_DrawBufferStatusCheck_ENUM = glCheckFramebufferStatus(GL_DRAW_FRAMEBUFFER);

	if (g_DrawBufferStatusCheck_ENUM != GL_FRAMEBUFFER_COMPLETE) {
		switch (g_DrawBufferStatusCheck_ENUM)
		{
		case GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT:
			break;
		case GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT:
			break;
		case GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT:
			break;
		case GL_FRAMEBUFFER_UNSUPPORTED:
			break;
		default:
			break;
		}

		glBindRenderbuffer(GL_RENDERBUFFER, NULL);
		glBindTexture(GL_TEXTURE_2D, NULL);
		glBindFramebuffer(GL_FRAMEBUFFER, NULL);
		return false;
	}
Advertisement

I believe this is the document you need:

https://www.opengl.org/registry/specs/ARB/texture_multisample.txt

Looks like this particular extension is part of the first wave of "core extensions", meaning the functions are designed to require no code changes between extension and core forms. All you have to do is load the functions (which GLEW will do magically) and enjoy.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Promit, on 07 Jul 2014 - 7:01 PM, said:

I believe this is the document you need:
https://www.opengl.org/registry/specs/ARB/texture_multisample.txt
Looks like this particular extension is part of the first wave of "core extensions", meaning the functions are designed to require no code changes between extension and core forms. All you have to do is load the functions (which GLEW will do magically) and enjoy.


Thank you very much; I saw this extension but within the "Dependencies" section of the document there is this:

Dependencies

This extension is written against the OpenGL 3.1 specification.

How do I interpret that? I was thinking I couldn't use that because it was dependent on a later version of OpenGL rather than the version I wanted to support.

Am I wrong?

Thanks again for your time.

The key is to understand that extensions are fundamentally written as two pieces:

1) An overall synopsis explaining what the extension does and what the motivations behind the extension are.

2) A diff that explains how the extension modifies the core spec

The "written against" part is part of #2, explaining what differences the extension creates against that particular spec version. It doesn't mean that version is required; as a practical matter it just tells you when the extension was actually written. You just need the specific spec version in order to have precise definitions of all the behavioral modifications of that extension.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

The key is to understand that extensions are fundamentally written as two pieces:

1) An overall synopsis explaining what the extension does and what the motivations behind the extension are.

2) A diff that explains how the extension modifies the core spec

The "written against" part is part of #2, explaining what differences the extension creates against that particular spec version. It doesn't mean that version is required; as a practical matter it just tells you when the extension was actually written. You just need the specific spec version in order to have precise definitions of all the behavioral modifications of that extension.

Ahhh, I get it. Thanks again.

This topic is closed to new replies.

Advertisement