2013-04-11 18:18:46 +00:00
|
|
|
/*!
|
|
|
|
|
2013-05-27 15:10:34 +00:00
|
|
|
@page context Context handling guide
|
|
|
|
|
|
|
|
@tableofcontents
|
|
|
|
|
|
|
|
The primary purpose of GLFW is to provide a simple interface to window
|
|
|
|
management and OpenGL and OpenGL ES context creation. GLFW supports
|
|
|
|
multiple windows, each of which has its own context.
|
|
|
|
|
|
|
|
|
|
|
|
@section context_object Context handles
|
|
|
|
|
|
|
|
The @ref GLFWwindow object encapsulates both a window and a context. They are
|
|
|
|
created with @ref glfwCreateWindow and destroyed with @ref glfwDestroyWindow (or
|
|
|
|
@ref glfwTerminate, if any remain). As the window and context are inseparably
|
|
|
|
linked, the object pointer is used as both a context and window handle.
|
|
|
|
|
|
|
|
|
|
|
|
@section context_hints Context creation hints
|
|
|
|
|
|
|
|
There are a number of hints, specified using @ref glfwWindowHint, related to
|
|
|
|
what kind of context is created. See
|
|
|
|
[context related hints](@ref window_hints_ctx) in the window handling guide.
|
|
|
|
|
|
|
|
|
|
|
|
@section context_current Current context
|
|
|
|
|
|
|
|
Before you can use the OpenGL or OpenGL ES APIs, you need to have a current
|
|
|
|
context of the proper type. The context encapsulates all render state and all
|
|
|
|
objects like textures and shaders.
|
|
|
|
|
|
|
|
Note that a context can only be current for a single thread at a time, and
|
|
|
|
a thread can only have a single context at a time.
|
|
|
|
|
|
|
|
A context is made current with @ref glfwMakeContextCurrent.
|
|
|
|
|
|
|
|
@code
|
|
|
|
glfwMakeContextCurrent(window);
|
|
|
|
@endcode
|
|
|
|
|
|
|
|
The current context is returned by @ref glfwGetCurrentContext.
|
|
|
|
|
|
|
|
@code
|
|
|
|
GLFWwindow* window = glfwGetCurrentContext();
|
|
|
|
@endcode
|
|
|
|
|
|
|
|
|
|
|
|
@section context_swap Swapping buffers
|
|
|
|
|
|
|
|
See [swapping buffers](@ref window_swap) in the window handling guide.
|
|
|
|
|
|
|
|
|
|
|
|
@section context_glext OpenGL extension handling
|
2013-04-11 18:18:46 +00:00
|
|
|
|
|
|
|
One of the benefits of OpenGL is its extensibility. Independent hardware
|
|
|
|
vendors (IHVs) may include functionality in their OpenGL implementations that
|
|
|
|
expand upon the OpenGL standard before that functionality is included in a new
|
|
|
|
version of the OpenGL specification.
|
|
|
|
|
|
|
|
An extension is defined by:
|
|
|
|
|
|
|
|
- An extension name (e.g. `GL_ARB_debug_output`)
|
|
|
|
- New OpenGL tokens (e.g. `GL_DEBUG_SEVERITY_HIGH_ARB`)
|
|
|
|
- New OpenGL functions (e.g. `glGetDebugMessageLogARB`)
|
|
|
|
|
|
|
|
Note the `ARB` affix, which stands for Architecture Review Board and is used
|
|
|
|
for official extensions. There are many different affixes, depending on who
|
|
|
|
wrote the extension. A list of extensions, together with their specifications,
|
2013-05-27 15:10:34 +00:00
|
|
|
can be found at the [OpenGL Registry](http://www.opengl.org/registry/).
|
2013-04-11 18:18:46 +00:00
|
|
|
|
2013-05-27 15:10:34 +00:00
|
|
|
To use a certain extension, you must first check whether the context supports
|
2013-04-11 18:18:46 +00:00
|
|
|
that extension and then, if it introduces new functions, retrieve the pointers
|
|
|
|
to those functions.
|
|
|
|
|
|
|
|
This can be done with GLFW, as will be described in this section, but usually
|
|
|
|
you will instead want to use a dedicated extension loading library such as
|
|
|
|
[GLEW](http://glew.sourceforge.net/). This kind of library greatly reduces the
|
|
|
|
amount of work necessary to use both OpenGL extensions and modern versions of
|
|
|
|
the OpenGL API. GLEW in particular has been extensively tested with and works
|
|
|
|
well with GLFW.
|
|
|
|
|
|
|
|
|
2013-05-27 15:10:34 +00:00
|
|
|
@subsection context_glext_header The glext.h header
|
2013-04-11 18:18:46 +00:00
|
|
|
|
|
|
|
The `glext.h` header is a continually updated file that defines the interfaces
|
|
|
|
for all OpenGL extensions. The latest version of this can always be found at
|
|
|
|
the [OpenGL Registry](http://www.opengl.org/registry/). It it strongly
|
|
|
|
recommended that you use your own copy, as the one shipped with your development
|
|
|
|
environment may be several years out of date and may not include the extensions
|
|
|
|
you wish to use.
|
|
|
|
|
|
|
|
The header defines function pointer types for all functions of all extensions it
|
|
|
|
supports. These have names like `PFNGLGETDEBUGMESSAGELOGARB` (for
|
2013-05-27 15:10:34 +00:00
|
|
|
`glGetDebugMessageLogARB`), i.e. the name is made uppercase and `PFN` and `PROC`
|
|
|
|
are added to the ends.
|
2013-04-11 18:18:46 +00:00
|
|
|
|
|
|
|
|
2013-05-27 15:10:34 +00:00
|
|
|
@subsection context_glext_string Checking for extensions
|
2013-04-11 18:18:46 +00:00
|
|
|
|
|
|
|
A given machine may not actually support the extension (it may have older
|
|
|
|
drivers or a graphics card that lacks the necessary hardware features), so it
|
2013-05-27 15:10:34 +00:00
|
|
|
is necessary to check whether the context supports the extension. This is done
|
2013-04-11 18:18:46 +00:00
|
|
|
with @ref glfwExtensionSupported.
|
|
|
|
|
|
|
|
@code
|
|
|
|
if (glfwExtensionSupported("GL_ARB_debug_output"))
|
|
|
|
{
|
2013-05-27 15:10:34 +00:00
|
|
|
// The extension is supported by the current context
|
2013-04-11 18:18:46 +00:00
|
|
|
}
|
|
|
|
@endcode
|
|
|
|
|
|
|
|
The argument is a null terminated ASCII string with the extension name. If the
|
2013-05-27 15:10:34 +00:00
|
|
|
extension is supported, @ref glfwExtensionSupported returns non-zero, otherwise
|
|
|
|
it returns zero.
|
2013-04-11 18:18:46 +00:00
|
|
|
|
|
|
|
|
2013-05-27 15:10:34 +00:00
|
|
|
@subsection context_glext_proc Fetching function pointers
|
2013-04-11 18:18:46 +00:00
|
|
|
|
|
|
|
Many extensions, though not all, require the use of new OpenGL functions.
|
|
|
|
These entry points are often not exposed by your link libraries, making
|
|
|
|
it necessary to fetch them at run time. With @ref glfwGetProcAddress you can
|
|
|
|
retrieve the address of extension and non-extension OpenGL functions.
|
|
|
|
|
|
|
|
@code
|
|
|
|
PFNGLGETDEBUGMESSAGELOGARB pfnGetDebugMessageLog = glfwGetProcAddress("glGetDebugMessageLogARB");
|
|
|
|
@endcode
|
|
|
|
|
|
|
|
In general, you should avoid giving the function pointer variables the (exact)
|
|
|
|
same name as the function, as this may confuse your linker. Instead, you can
|
|
|
|
use a different prefix, like above, or some other naming scheme.
|
|
|
|
|
|
|
|
Now that all the pieces have been introduced, here is what they might look like
|
|
|
|
when used together.
|
|
|
|
|
|
|
|
@code
|
|
|
|
#include "glext.h"
|
|
|
|
|
|
|
|
#define glGetDebugMessageLogARB pfnGetDebugMessageLog
|
|
|
|
PFNGLGETDEBUGMESSAGELOGARB pfnGetDebugMessageLog;
|
|
|
|
|
2013-05-27 15:10:34 +00:00
|
|
|
// Flag indicating whether the extension is supported
|
2013-04-11 18:18:46 +00:00
|
|
|
int has_debug_output = 0;
|
|
|
|
|
|
|
|
void load_extensions(void)
|
|
|
|
{
|
|
|
|
if (glfwExtensionSupported("GL_ARB_debug_output"))
|
|
|
|
{
|
|
|
|
pfnGetDebugMessageLog = (PFNGLGETDEBUGMESSAGELOGARB) glfwGetProcAddress("glGetDebugMessageLogARB");
|
|
|
|
if (pfnGetDebugMessageLog)
|
|
|
|
{
|
|
|
|
// Both the extension name and the function pointer are present
|
|
|
|
has_debug_output = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void some_function(void)
|
|
|
|
{
|
|
|
|
// Now the extension function can be called as usual
|
|
|
|
glGetDebugMessageLogARB(...);
|
|
|
|
}
|
|
|
|
@endcode
|
|
|
|
|
|
|
|
*/
|