[11/52] OpenGL is Still Decent, Actually

I know… I promised I’d be doing more engineering. We’ll get there! But I was consuming some interesting digital creator / software engineering content the other day. There was one guy in particular (I won’t say exactly who) who tends to do pretty interesting stuff, but who can be a little bit iconoclastic. He went on a weird rant about how obscure, obtuse, and inaccessible OpenGL is. It was very strange because the critique was based on how difficult it was to get sprites or pixels up on the screen. But compared to pretty much anything else–Vulkan, Carbon, XTerminal–it’s pretty straightforward and well-established how to get up and going.

This guy is pretty experienced, and he knows what he’s doing, so it seemed strange and the comment came out of nowhere. So, naturally, it got me going and thinking, “okay, what is the simplest and shortest path to get up and going with OpenGL?” Assume you’re trying to just put up a simple animation, create a simple game, put some sprites on the screen, etc. What is the shortest path to do that? And as it turns out, unless you’re doing something platform-specific like Windows GDI, OpenGL is still a really good way to go.

There’s a few other things you need in combination with it. SDL is an absolutely fantastic library–strongly recommended, check it out if you aren’t familiar with it. There’s a lot more to it, but for getting out of the box and going with a window and an event loop and a GL context and all that, it’s fantastic. And of course GLEW is practically required for a lot of things. So today we’re going to walk through, really quick, a brief demonstration of what the “shortest path” to a working “sprites on screen” is.

Let’s Get Started

Begin with a blank C++ project. We’ll create the following files as placeholders for future content:

.gitignore

basic.f.glsl

basic.v.glsl

CMakeLists.txt

main.cpp

After initializing our git repository, we’ll also want to add some dependencies. We’ll use git submodules to do this, and in most cases these will need to come from specific branches. So, run git submodule add for the following:

https://github.com/libsdl-org/SDL.git (use branch SDL2)

https://github.com/libsdl-org/SDL_image.git (use branch SDL2)

https://github.com/Perlmint/glew-cmake.git0

You’ll notice we’re also adding SDL Image here, which is a fantastic extension to SDL that gives you out-of-the-box support for loading surfaces from a wide variety of image formats. We’re also using a specific fork of GLEW that supports inclusion via CMake, to automate the dependency inclusion within our CMake project definition. Once those dependencies are cloned and submodules initialized (recursively!), we’re ready to start populating our files.

You’ll also notice we have some shaders. If you haven’t messed with GLSL before, it’s fascinating! We’ll probably do another talk specifically about radiometry and applications to graphics programming, thermal, electro-optics, and other fields. We’ll also want a test texture; you can use any .PNG you want, but I went with a nice picture of a seagull. Cheers.

Our goal–our mission, if we choose to accept it–is to put this image up in the window. If we do this well, it should be clear how we can extend this in the future to do more sophisticated sprite models and behaviors within the context of an app or game engine.

The Main Thing

Let’s start in main.cpp with some dependencies. We’ll include the following, roughly broken into system includes and dependency includes:

Vertex Formats

Next, we’ll think about our data model. Let’s stay away with classes and focus on how the state of our application will be packed into an aggregation of bytes (a struct).

You do need to think about your vertex format! Briefly, this means thinking about what information is attached to, or defines, each vertex in the drawing sequence you will call. Since we’re focusing on a textured 2d sprite, our verts array defines a set of 4 vertices, each of which defines 4 values:

An x (position) coordinate
An y (position) coordinate
A u (texture) coordinate
A v (texture) coordinate

We’ll see how we “encode”, or tell OpenGL about, the format of this vertex sequence in subsequent calls. And since we only want to define each vertex once, we also have an index buffer to define how the vertices are combined to form a shape (in this case, two triangles).

Application State

We also need to think about what information defines the state our our application model. Let’s use the following, which includes SDL references and a healthy mix of OpenGL unsigned integers (effectively used as handles to GPU data).

Behaviors

We want to define procedures by which we initialize and free specific models within this application. Let’s define prototypes for the following:

We’ll also want some helper methods and a function to define specific loops. (In the long run, we’d want to split these loops across threads for different cadences like rendering, I/O handling, and internal updates.)

And now we have enough defined to think about how we use these behaviors in the context of a program. So let’s write our main() entry point!

The Main Main

First, let’s start up the application by allocating, loading resources, and calling our initializers.

Even though we’ve consolidated all of our state within a specific structure, you’ll notice we’ve broken out initialization into specific steps. If you’ve used THREE.js before, this model may loop familiar. In the long run, this will make it easy to extract and organize specific models within our application–like individual shader programs, complex geometry data that may be reused or even animated, and material resources that need internally-organized bindings to things like multiple texture uniforms.

(We might look at a “part two” in which we see how these models can evolve into something more… interesting, if not entirely professional yet.0)

Next we can think about our “core” loop. This is pretty straightforward:

Finally, we clear up our resources:

Initialization

When we initialize the application, what are we talking about? Since we have separate initialization for our different groups of GL data, this is largely SDL-specific. Let’s write our initApplication() to handle this top-level logic.

The big “lift” here is window management, of course, and that’s the important part SDL automates for us. Once we have an agnostic window generated, getting a GL context is straightforward. These things would be 80% of the effort (a nightmare) if we didn’t have SDL or something like it. Once you have your GL context, you’re home free and almost everything else is platform-neutral.

A Brief Break for CMake

Let’s jump over to our CMakeLists.txt for a moment to make sure we’ll be able to build this mess once we’ve finished coding. We’ll start with the standard three CMake commands: defining the version, defining the project, and defining the main build artifact (executable, in this case).

Next, we’ll assert specific options for our dependencies.

Now we can recursively include our submodules:

Now we’ll want to make sure our main build target can resolve the appropriate #include paths.

When in doubt, these are basically the library names. Some CMake projects will have their own unique library names defined (the :: is a big clue); you can always check their CMakeLists.txt for an add_library() directive. There’s also some useful logic/automation build into the find_package() directive within CMake–that might be worth going over in its own video at some point.

Finally, we’ll want to set specific runtime resources to copy into the binary folder. We’ll do this for static resources (like our image), as well as dynamic resources (like dependency DLLs). At some point, you can automate a degree of this with something like CPack, which is also probably worth its own video.

(We’re cheating a little bit here, because we know what DLLs will be generated and where they need to go.)

And that just about does it for our CMake. This is enough for us to do a basic configure test from the command line:

Back to the Source

Let’s finish our initialization. We’ve initialized the application. How are we going to initialize our shaders? There’s a basic three-step process: first, we compile the vertex shader from source; second, we compile the fragment shader from source; third, we link these two shaders into a fully-defined graphics program.

(You’ll notice we’re null-terminating our string copy from the error buffer, which isn’t a great idea in general. Don’t try this at home, kids!)

In modern graphics programming, you would not be necessarily doing this full build from source at runtime like this. Instead, you’d have an intermediate format (like SPIR-V, with Vulkan) that you would use to do a lot of the preliminary compilation. For our purposes, though, this is enough (and interesting, and useful; it also gives a transparent view into our application state and graphics pipeline.)

Note that we “know” special things about our shader program, in this case. For example, we “know” that there is a uniform variable we’ll need to bind to our texture data. We’ll look at how we set this up in the material initialization.

Geometries

Now let’s think about our geometry data. We’ve defined a set of vertices with a specific format, and some indices that define how those are mapped to specific shapes for drawing. We need to tell OpenGL how these vertices are structured. We also need to hand off (copy) the data buffers themselves. These are mostly done with buffer commands, using the “handles” (unsigned integers) we’ve defined as part of our application state to share persistent references.

That middle clause is probably the most interesting, because this is where we tell OpenGL how the vertex attributes are structured. Given a sequence of vertex attributes, each segment defines a vertex–but how is that information “packed”? There are a total of four values (or “stride”) between each segment (that is, the segment length).

The first pair of values define the “x-y” pair, or vec2, vertex attribute; these are floats and offset from the beginning of the segment by zero values

The second pair of values define the “u-v” pair, or vec, vertex attribute; these are floats and offset from the beginning of the segment by two values

Materials

With our geometry data and shader program defined, we need to pass in material data. In this case, we have a single diffuse texture that will be sampled to define the pixel (or fragment) color within our “sprite”. We do this by loading the image data from an SDL surface for OpenGL to reference as a “uniform” input to our shader program.

Most of the second block is just defining the sampling parameters for OpenGL. The most interesting call is the last line, where we pass off the actual pixel data from the SDL surface to the GPU.

Loops

We’re just about done! Let’s define our rendering pass, which is pretty straightforward because we have only one draw call.

Everything is already loaded (buffers, objects, program, etc.) so we just need a draw call. In this case, we tell OpenGL to draw six elements from our buffer (vertices), and to treat them as triangles (that is two triangles with three vertices each). Finally, we swap our buffer (I can’t tell you how much time I’ve wasted on other projects before I realized nothing was showing because I never swapped the window buffers…).

Helpers

There are a few “helper” functions we need to define, as well as freeing our application state.

Lastly, let’s define our our application state is cleaned up. This is basically in reverse order from our initialization.

Shader

We’re done! With the C++. We still need to define a very basic graphics pipeline. Let’s start with the vertex shader, which is simply forwarding the texture coordinates as a varying parameter for the fragment shader, and defining the basic position transform from our 2d space into the 4d position OpenGL expects.

Then, our fragment shader uses those texture coordinates (interpolated for each pixel) to look up the appropriate fragment color from our texture data.

Building

We have enough! Let’s compile our project using the CMake configuration we already set up.

If successful, you should see an executable show up in build/Debug/. And when you run it, you should see your sprite appear!

Stepping Back

We started this conversation off by saying “it’s actually really easy to get started with OpenGL!”… but this took a little bit of time, didn’t it?

If you think about what we were doing, none of these things were really optional–whether we’re using OpenGL or anything else. Most importantly, we’ve put ourselves in a position where it’s fairly extensible to more sophisticated to other things we might want to do. (We have image loading support, we have customizable shaders, we have structured state models, we have an extensible/threadable event loop…) Some of these came with optional dependencies (like SDL_Image) but this gave us a pretty well-organized “starter” project.

It will be very easy in our next iteration to break parts of this application structure apart into reusable models for shader programs, individual sprites, scene graph nodes with their own transforms, etc. This is the first of two big takeaways: With a little bit of help, you can get started with a sprite-based application very easily, and you can do it in a way where you make it possible to do a lot more in the future with that.

Secondly, believe it or not… well, there’s a saying attributed to Winston Churchill, roughly along the lines of “democracy is the worst form of government… except for all the others that have been tried.” OpenGL is a lot like this–trying to get started this quickly with any other approach is an absolute nightmare. OpenGL is the worst way to get started… except for all the others that have been tried. (Vulkan, Wayland, you name it.)

So, this is a little involved. But (maybe because I’ve just started at this too much over the years) everything here still makes sense. Compared to some of the more obscure setups, you’re not trying to abstract away too much of what’s going on with the GPU, you have a nicely customized graphics pipeline that you have a lot of control over but it’s still straightfowrard to setup and get something going.

This is part one of two. In part two, I’m thinking of looking at a basic 2d engine that you might put together based off of this. But this is a good way to get going, and a good way to start doing quick 2d cross-platform applications, especially if you’re new to it or just want to draw some sprites.