Hello Window


Let's see if we can get GLFW up and running. First, create a .cpp file and add the following includes to the top of your newly created file.

#include <glad/glad.h>
#include <GLFW/glfw3.h>
Be sure to include GLAD before GLFW. The include file for GLAD contains the correct OpenGL header includes (like GL/gl.h) so including GLAD before other header files that require OpenGL does the trick.

Next, we create the main function where we will instantiate the GLFW window:

int main()
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
    return 0;

In the main function we first initialize GLFW with glfwInit, after which we can configure GLFW using glfwWindowHint. The first argument of glfwWindowHint tells us what option we want to configure, where we can select the option from a large enum of possible options prefixed with GLFW_. The second argument is an integer that sets the value of our option. A list of all the possible options and its corresponding values can be found at GLFW's window handling documentation. If you try to run the application now and it gives a lot of undefined reference errors it means you didn't successfully link the GLFW library.

Since the focus of this website is on OpenGL version 3.3 we'd like to tell GLFW that 3.3 is the OpenGL version we want to use. This way GLFW can make the proper arrangements when creating the OpenGL context. This ensures that when a user does not have the proper OpenGL version GLFW fails to run. We set the major and minor version both to 3. We also tell GLFW we want to explicitly use the core-profile. Telling GLFW explicitly that we want to use the core-profile means we'll get access to a smaller subset of OpenGL features (without backwards-compatible features we no longer need). Note that on Mac OS X you need to add glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); to your initialization code for it to work.

Make sure you have OpenGL versions 3.3 or higher installed on your system/hardware otherwise the application will crash or display undefined behavior. To find the OpenGL version on your machine either call glxinfo on Linux machines or use a utility like the OpenGL Extension Viewer for Windows. If your supported version is lower try to check if your video card supports OpenGL 3.3+ (otherwise it's really old) and/or update your drivers.

Next we're required to create a window object. This window object holds all the windowing data and is used quite frequently by GLFW's other functions.

GLFWwindow* window = glfwCreateWindow(800, 600, "LearnOpenGL", NULL, NULL);
if (window == NULL)
    std::cout << "Failed to create GLFW window" << std::endl;
    return -1;

The glfwCreateWindow function requires the window width and height as its first two arguments respectively. The third argument allows us to create a name for the window; for now we call it "LearnOpenGL" but you're allowed to name it however you like. We can ignore the last 2 parameters. The function returns a GLFWwindow object that we'll later need for other GLFW operations. After that we tell GLFW to make the context of our window the main context on the current thread.


In the previous tutorial we mentioned that GLAD manages function pointers for OpenGL so we want to initialize GLAD before we call any OpenGL function:

if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))
    std::cout << "Failed to initialize GLAD" << std::endl;
    return -1;

We pass GLAD the function to load the adress of the OpenGL function pointers which is OS-specific. GLFW gives us glfwGetProcAddress that defines the correct function based on which OS we're compiling for.


Before we can start rendering we have to do one last thing. We have to tell OpenGL the size of the rendering window so OpenGL knows how we want to display the data and coordinates with respect to the window. We can set those dimensions via the glViewport function:

glViewport(0, 0, 800, 600);

The first two parameters of glViewport set the location of the lower left corner of the window. The third and fourth parameter set the width and height of the rendering window in pixels, which we retrieve here from GLFW itself.

We could actually set the viewport dimensions at values smaller than GLFW's dimensions; then all the OpenGL rendering would be displayed in a smaller window and we could for example display other elements outside the OpenGL viewport.

Behind the scenes OpenGL uses the data specified via glViewport to transform the 2D coordinates it processed to coordinates on your screen. For example, a processed point of location (-0.5,0.5) would (as its final transformation) be mapped to (200,450) in screen coordinates. Note that processed coordinates in OpenGL are between -1 and 1 so we effectively map from the range (-1 to 1) to (0, 800) and (0, 600).

However, the moment a user resizes the window the viewport should be adjusted as well. We can register a callback function on the window that gets called each time the window is resized. This resize callback function has the following prototype:

void framebuffer_size_callback(GLFWwindow* window, int width, int height);  

The framebuffer size function takes a GLFWwindow as its first argument and two integers indicating the new window dimensions. Whenever the window changes in size, GLFW calls this function and fills in the proper arguments for you to process.

void framebuffer_size_callback(GLFWwindow* window, int width, int height)
    glViewport(0, 0, width, height);

We do have to tell GLFW we want to call this function on every window resize by registering it:

glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);  

When the window is first displayed framebuffer_size_callback gets called as well with the resulting window dimensions. For retina displays width and height will end up significantly higher than the original input values.

There are many callbacks functions we can set to register our own functions. For example, we can make a callback function to process joystick input changes, process error messages etc. We register the callback functions after we've created the window and before the game loop is initiated.

Ready your engines

We don't want the application to draw a single image and then immediately quit and close the window. We want the application to keep drawing images and handling user input until the program has been explicitly told to stop. For this reason we have to create a while loop, that we now call the render loop, that keeps on running until we tell GLFW to stop. The following code shows a very simple render loop:


The glfwWindowShouldClose function checks at the start of each loop iteration if GLFW has been instructed to close, if so, the function returns true and the game loop stops running, after which we can close the application.
The glfwPollEvents function checks if any events are triggered (like keyboard input or mouse movement events), updates the window state, and calls the corresponding functions (which we can set via callback methods). The glfwSwapBuffers will swap the color buffer (a large buffer that contains color values for each pixel in GLFW's window) that has been used to draw in during this iteration and show it as output to the screen.

Double buffer
When an application draws in a single buffer the resulting image might display flickering issues. This is because the resulting output image is not drawn in an instant, but drawn pixel by pixel and usually from left to right and top to bottom. Because these images are not displayed at an instant to the user, but rather via a step by step generation the result may contain quite a few artifacts. To circumvent these issues, windowing applications apply a double buffer for rendering. The front buffer contains the final output image that is shown at the screen, while all the rendering commands draw to the back buffer. As soon as all the rendering commands are finished we swap the back buffer to the front buffer so the image is instantly displayed to the user, removing all the aforementioned artifacts.

One last thing

As soon as we exit the render loop we would like to properly clean/delete all resources that were allocated. We can do this via the glfwTerminate function that we call at the end of the main function.

return 0;

This will clean up all the resources and properly exit the application. Now try to compile your application and if everything went well you should see the following output:

Image of GLFW window output as most basic example

If it's a very dull and boring black image, you did things right! If you didn't get the right image or you're confused as to how everything fits together, check the full source code here.

If you have issues compiling the application, first make sure all your linker options are set correctly and that you properly included the right directories in your IDE (as explained in the previous tutorial). Also make sure your code is correct; you can easily verify it by looking at the source code. If you still have any issues, post a comment below with your issue and me and/or the community will try to help you.


We also want to have some form of input control in GLFW and we can achieve this several of GLFW's input functions. We'll be using GLFW's glfwGetKey function that takes the window as input together with a key. The function returns whether this key is currently being pressed. We're creating a processInput function to keep all input code organized:

void processInput(GLFWwindow *window)
    if(glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS)
        glfwSetWindowShouldClose(window, true);

Here we check whether the user has pressed the escape key (if it's not pressed, glfwGetKey returns GLFW_RELEASE). If the user did press the escape key, we close GLFW by setting its WindowShouldClose property to true using glfwSetwindowShouldClose. The next condition check of the main while loop will then fail and the application closes.

We then call processInput every iteration of the render loop:

while (!glfwWindowShouldClose(window))


This gives us an easy way to check for specific key presses and react accordingly every frame.


We want to place all the rendering commands in the render loop, since we want to execute all the rendering commands each iteration of the loop. This would look a bit like this:

// render loop
    // input

    // rendering commands here

    // check and call events and swap the buffers

Just to test if things actually work we want to clear the screen with a color of our choice. At the start of each render iteration we always want to clear the screen otherwise we would still see the results from the previous iteration (this could be the effect you're looking for, but usually you don't). We can clear the screen's color buffer using the glClear function where we pass in buffer bits to specify which buffer we would like to clear. The possible bits we can set are GL_COLOR_BUFFER_BIT, GL_DEPTH_BUFFER_BIT and GL_STENCIL_BUFFER_BIT. Right now we only care about the color values so we only clear the color buffer.

glClearColor(0.2f, 0.3f, 0.3f, 1.0f);

Note that we also set a color via glClearColor to clear the screen with. Whenever we call glClear and clear the color buffer, the entire colorbuffer will be filled with the color as configured by glClearColor. This will result in a dark green-blueish color.

As you might recall from the OpenGL tutorial, the glClearColor function is a state-setting function and glClear is a state-using function in that it uses the current state to retrieve the clearing color from. Image of GLFW's window creation with <function id='13'><function id='10'>glClear</function>Color</function> defined

The full source code of the application can be found here.

So right now we got everything ready to fill the game loop with lots of rendering calls, but that's for the next tutorial. I think we've been rambling long enough here.