Likewise, there is a code path for loading functions exposed by ARB_direct_state_access, which is used when said extension was advertized by the GL implementation. So, when OpenGL 4.5 is reportedly available, then glCreateTextures (along with all other 4.5 functions) will be loaded. While there is no mechanism to load a function through (due to) a GL core version making that function available or through an extension, LWJGL does make this distinction in its GLCapabilities class itself by knowing which core versions and which extensions expose which functions. BackgroundĬurrently, LWJGL 3 loads function pointers for GL functions in its GLCapabilities class through the function provider, which ultimately is the platform-specific function, like e.g. It would be nice, if LWJGL could protect unintentionally using GL functions that should not (and would not) be available at runtime when requesting a lower GL core context version. And this error only occurred when the application ran on a machine which neither had OpenGL 4.5 nor ARB_direct_state_access available. In that particular case, the user optionally used some GL 4.5 functions when GL 4.5 was available, but unintentionally used other GL 4.5 functions without knowing it or guarding them.
Opengl 4.4 glfw driver#
a GL 3.3 core context, iff the driver advertized the ARB_direct_state_access extension, which also exposes this function with the same name (note: no ARB suffix). By and large it's not a wrapper library on top of OpenGL though it does provide some a small amount of functionality like this: like automatically building mip-map levels.Currently, it is possible to call GL45C.glCreateTextures(.) even when requesting e.g. This is where GLFW comes in: it provides a cross-platform library to handle the things that OpenGL doesn't handle, like creating contexts and handling mouse events.
Opengl 4.4 glfw windows#
Additionally Windows provides functions to support things like mouse events. For example Windows has its own function calls that allow the creation of OpenGL contexts that are very different from how OSX creates a context. Think of an OpenGL context as some internal data that represents the current state of the OpenGL system.ĭifferent platforms (such as Windows, Linux/X, OSX, iOS, Android) provide different mechanisms for creating contexts. The OpenGL library itself has no mechanism to create such contexts. In fact, in order to do anything with OpenGL you need what is called an OpenGL context. Because you probably want to render things visible on the screen you can't "use OpenGL on its own" because you wouldn't have anywhere to render.
OpenGL doesn't know anything about windows, or mouse events, or keyboards, or fonts and so on.
OpenGL is a library that provides services like 3D rendering but doesn't do anything like creating a window that you can render into. But it also means that you wrote something with GLFW, you could "port" it to using, e.g., freeglut, and you would only have to replace the functionality provided by glfw(.) functions, but the gl(.) woul stay the same. Which means that you could use OpenGL on its own, but it would make several things quite difficult. GLUT, GLFW and freeglut wrap around (or better extend) that OpenGL library and offer additional behavior (I read that OpenGL doesn't offer much for support for sound or dealing with input). Khronos programs the OpenGL library and specifies an API for it. I'm going to make an assumption and going to ask if it is right: Khronos owns OpenGL, but do they program a library for people to use, or do they just specify an API, like for example there are several C++ libraries ( libc++ and libstdc++) which implement the same API specified by the C++ Consortium? I don't really understand how OpenGL and GLFW (or something like GLUT) relate to each other. What I'm noticing is, that the code still contains "typical" OpenGL functions, like glColor or glVertex, but it also contains "glfw" functions like glfwSetErrorCallback. So I installed GLFW source and I'm looking at some easy examples. Now this question might sound (/ is) stupid, but I'm just getting into OpenGL.