Updating to latest

We have been using openGL for years now and we are looking at possibly updating our code base to the newer libraries. We are using MFC, C++ visual studio 2019. Can anyone possibly give us some guidance on what that process would look like? are the old functions still supported for the most part ect? Thanks in advance for the help!

Nothing has been removed. In terms of libraries, nothing has been added; libopengl32.dll still only exports the OpenGL 1.1 API, requiring the use of wglGetProcAddress to obtain function pointers for any added after that version.

Most of the OpenGL 1.x API is considered deprecated, but it’s still supported (unless you specifically create a core-profile context). All of the mainstream hardware vendors (Nvidia, AMD, Intel) support the compatibility profile, so you can use both legacy and modern features simultaneously.

If you haven’t looked at anything past 1.x, the difference between legacy and modern OpenGL is large enough that you should probably just get a book on modern OpenGL (e.g. the latest edition of the red book, currently the ninth edition) and re-learn it.

we are using version 1.something. Do you feel its a good idea then to update? I’m assuming that their has been a good amount of development into the newer opengl. IE rendering speeds, animation speeds, memory utilizations?

Bear in mind that the OpenGL implementation is in the device driver and the hardware. The DLL is just an interface to that. Updating the library without changing the code won’t achieve anything; any improvements in the hardware or driver will automatically apply to any OpenGL application.

You may be able to get so performance improvement by using features in newer versions of the OpenGL API, but that could require a significant re-write. Whether you’ll get any improvement and how much depends upon exactly what the code is doing.

E.g. if you have mostly static geometry and you’re sending that to the GPU each frame using client-side vertex arrays or glBegin/glEnd, switching to vertex buffer objects (VBOs) keeps the data in video memory which avoids copying. But if you’re using display lists, the driver is probably already keeping that in video memory.

If you’re calculating vertex data in the application, you may be able to offload some or all of those calculations to the GPU by using a vertex shader.

Hello, its been a while, we are finally to the point of updating and switching to the modern opengl functions. did some research and have watched some tutorials. Im having some issues getting my createshader to work. i think it partly because we are trying to use legacy and modern gl together. We render 3 things to a CView, and we are trying to start by leaving 2 of them alone and rendering the 3rd with the modern GL calls. Im using GLFW and GLEW.

int code = glfwGetError(&description);
if (code == GLFW_NO_ERROR)
{
	if (glfwInit() != GLFW_TRUE)
	{
		const char* description;
		code = glfwGetError(&description);
	}
	glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
	glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
	glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
	glewExperimental = GL_TRUE;
	glfwSetErrorCallback(error_callback);

From here i want to use glfwMakeContextCurrent but i need to bind to an existing CView not a window. So if i try to use:

wglMakeCurrent(m_pCDC->GetSafeHdc(), m_hRC);
glewInit();
unsigned int vertex_shader = glCreateShader(GL_VERTEX_SHADER);
unsigned int  fragment_shader = glCreateShader(GL_FRAGMENT_SHADER);

i get:
Access Violation exception (on address 0x00000000)
on the glCreateShader.

Does anyone know how to make this work?

As @GClements already mentioned all GL functions newer than OpenGL 1.1 must be loaded with wglGetProcAddress/glxGetProcAddress - see also the wiki page on loading OpenGL functions and page on loading libraries.

On Windows, yes (wgl). But not on Linux (glX), at least with NVIDIA drivers. This annoyance is mainly imposed by Microsoft’s ancient OpenGL loading mechanism.

But it’s easy enough to just use something like GLEW nowadays. Then you don’t even have to care.

You’ve got your glewInit call and you’re making it after you’ve created and made your context current, so that’s great. But you’re not checking the return value from it - it should be returning GLEW_OK if GLEW initialized with no errors.

Even if it does return GLEW_OK it’s still possible that you might have gotten Microsoft’s software OpenGL 1.1 implementation - that can happen if you requested a pixel format that your GPU can’t accelerate, for example.

If you’re planning on using any part of the legacy OpenGL API, you need a compatibility profile. The whole point of core profile is that it doesn’t have the legacy features.

MFC or GLFW? Pick one. GLFW creates contexts and associates them with the windows which it creates. If you’re using MFC, GLFW probably isn’t going to be of any use to you (well, you might want to refer to its source code as a reference on context management).

For the compatibility profile, you shouldn’t need to change anything related to context management. wglCreateContext will normally give you a compatibility profile context for the highest OpenGL version supported by your hardware and drivers.

If you specifically want a core profile context, then things gets more involved. As described in the wiki page, to create a core profile context (or any context with specific options not supported by wglCreateContext) you have to use wglCreateContextAttribsARB. But that isn’t part of the OpenGL 1.1. API and so isn’t exported by opengl32.dll. So you first have to create a legacy context with wglCreateContext, use that to get the function pointer for wglCreateContextAttribsARB (either using wglGetProcAddress directly or using a loader such as GLEW), then use that pointer to create the real context.

Thanks, I think as seen below and other tutorials its also possible to use GLEW and GLFW to do some of this. Its very possible that that is what they are using under the hood, however I have no issue getting it to init and work if I want to use a separate GLwindow. As I needed the answer from above I’m not sure how to do this with an existing Cview.

I can actually init both glwf and glew with no errors. I found some code on using MFC contexts, but i am still getting an access memory violation at the shaders. this is the current state of code:

void SetContext(CDC* pCDC, HGLRC hRC)
{
	GLFWwindow* window;

	/* Initialize the library */
	const char* description;
	int code = glfwGetError(&description);
	int glfwerr = glfwInit();
	if (glfwerr == GLFW_TRUE)
	{
		glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
		glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
		glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE)
	


			m_pCDC = pCDC;
			m_hRC = hRC;
			glewExperimental = GL_TRUE;
			if (!wglMakeCurrent(m_pCDC->GetSafeHdc(), m_hRC) == FALSE)
			{
				wglMakeCurrent(m_pCDC->GetSafeHdc(), m_hRC);
				GLenum err = glewInit();
				if (err == GLEW_OK)
				{
					GLuint program = glCreateProgram();
					unsigned int vertex_shader = glCreateShader(GL_VERTEX_SHADER);

				}
			
			}
	
	}
}

Still no luck with this one. Anyone see anything thats wrong?

Of course you can. They don’t do the same thing.

GLEW is an OpenGL loading library. It exists to load OpenGL functions from a given OpenGL context.

GLFW is a tool for creating and managing an OpenGL window. MFC is a tool for creating and managing windows. See how they’re trying to do the same kind of thing? And that kind of thing has nothing to do with loading OpenGL functions.

GLFW does not work with windows owned by someone else. It creates an OpenGL context for use by a window that it also creates. MFC does not work with windows owned by someone else. It creates windows and manages the windows it creates.

These two systems aren’t going to work together.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.