Introducing New OpenGL SDK Samples

By Evan Hart, posted Jan 03 2013 at 04:04PM

For anyone not following it, OpenGL has evolved a lot over the last few years. This isn’t to say that old favorites like glBitmap are gone, as full compatibility is still supported, but newer capabilities have come about that can make your code faster and easier to write. With all these changes, our older SDK structure wasn’t really keeping pace. We’ve heard the criticism on the staleness of the old SDK, so we’ve decided to reinvent the SDK as part of our blog posts. This means topical posts with source code all building off a common framework, as opposed to the large monolithic download of old.

As part of the effort to update the SDK, we’ve revamped the support framework. The goal was to try to simplify the dependencies, so that a single sample will depend on one dll + a collection of headers rather than three or four additional projects. We feel it will make projects easy to build and understand.

With the revamp, we intend to focus the SDK on how to best use the new capabilities in OpenGL. As a result, you won’t see glBegin, glBitmap, glActiveTexture, and other things that have been there since OpenGL 1.0. Instead, the focus will be on vertex buffers, direct state access, and path rendering.

One large change evident to anyone who has looked at our SDK in the past will be in the shaders. First, all shaders are now in GLSL, instead of the mix of languages supported previously. Additionally, we’ve moved to extensive use of shader includes, separate shader objects, and uniform buffers. Using separate shader objects simplifies mixing and matching shader stages, which previously required linking all desired combinations when using GLSL. Next, the “layout” qualifier allows our shaders to directly specify their desired environment. Previously, there was a lot of reflection required to just setup the correct bindings for textures and vertex attributes. Now, all shaders specify this explicitly in the code. Finally, and possibly most importantly, shader include plus the uniform buffer objects, allows the SDK code to share uniform data definitions not just between shaders, but also with the C++ program. By specifying the uniform buffer definition in a header and relaying on a few special type definitions, we can have a struct that directly matches the layout of our constant buffer. From here maintaining and updating state is greatly simplified.

Another big change that you’ll notice is that our UI has been converted over to path rendering. This means no more bitmap fonts that scale poorly. The new path rendering extension in the driver is really great for a lot of UI work, and you can definitely do some pretty complex text rendering with it. This isn’t to say things are fully changed over. The text has already moved, and you will see more things in our UI code move toward path rendering as we make additional updates.

Finally, we decided to stop using GLUT as the basis of the SDK. It has served us well for a long time, and we think it can continue to serve others well. We have replaced it with GLFW for windowing, as it offers a couple other things we were looking for. As you will notice, we do not use it directly, but wrap it in our custom SDK framework. The main reason here is to provide some additional portability, for when we decide to support additional platforms GLFW does not handle.

Conclusion

We already have a handful of samples queued up and lots of ideas for others’ however, we really want to hear from you the reader about what samples you will find most helpful. The bottom line is that the blog gives us a more interactive and dynamic medium to drive the SDK, and we intend to use it to serve our audience better.