OpenGL on Linux

Question

i'd like to learn how to integrate OpenGl and C++ on Linux, but i'm very disappointed with the tutorials i found online... I'd like to learn the whole process, how to compile, how to set thing up etc etc... It's been two days since i started googleing, and there are plenty of tutorials, but no one does what i like...i found tutorials of openGL only, but i'd like to use them with c++. I found tutorials with c++, but they start by using cmake already configured to build everything, so i don't get at all the first steps... I mean, it's so hard to find something that guides you from scratch, explaining nicely what the various included libraries do and so on? If you know something, please tell me. (don't link me something like the official site of open gl, i'd like a simple but complete guide to ease me into this world)

Answer 1

Well, OpenGL itself is a language agnostic API, however the defacto standard API to which everything boils down is made available for the C language. For every language but C and C++ this means that custom bindings have to be created. But for C and C++ you just

#ifndef __APPLE__
#include <GL/gl.h>
#else
#include <OpenGL/gl.h>
#endif

and tell the linker to link with opengl32 (Windows, 32 and 64 bit versions), GL (non MacOS X *nixes, like Linux, the BSDs, Solaris, etc.) or -framework OpenGL (on MacOS x).

As far as getting your program to be able to talk to OpenGL is concerned, that's it. Since OpenGL has been specified to be part of the standard operating system APIs in Windows and MacOS X, there's no need to install extra libraries to use it. In the *nix-es like Linux, OpenGL support there is optional, but usually if there's a graphical environment like X.org or Wayland installed, so is OpenGL support.

A few words on OpenGL and C++. Many people (including me, actually several times) have attempted to find a universal mapping from OpenGL into OOP constructs and failed. There's always one aspect of OpenGL, that will throw a wrench into OOP gears (most importantly the thread-local but scope-global state, which is almost impossible to track correctly from just OOP). If you constrain yourself to certain aspects that a OOP-ification will may be attainable, to some degree. However I strongly suggest against doing so! Why? Because it disguises OpenGL as something it isn't. So instead of trying to OOP-ify OpenGL you should instead OOP-ify your renderer and directly use the "naked" OpenGL API with that. I should also point out, that with the design of the new Vulkan API the obstacles for OOP-ification are no longer there (most importantly there's no longer a thread-local scope-global state).

Here's a quick glance at what the various things you'll find around OpenGL do.

The OpenGL API interface library

OpenGL is not a library. OpenGL is a API specification and the actual thing is done in a so called implementation. Implementations are vendor specific and ship as part of the graphics driver. In Windows there's a standard interface (library) you link your programs against with, that the driver implementation is hooked into. On *nix-es (except MacOS X) the interface library is shipped as part of the driver (which is a huge mess, because it means you can't directly use multiple GPUs that require different OpenGL drivers). MacOS X is similar, but there the OpenGL driver and implementation ships as part of the operating system.

Anyway, all your program has to care about is, that this library is there. The exact variant of that library doesn't matter, as doesn't if it's just an interface or the actual implementation. What matters is, that for each OpenGL entry point, that has been pinned down on the OS's base ABI specification can be found in that library.

Which brings us to

OpenGL versions

OpenGL is a grown specification and as such you can find a huge variety of implementations out there. The one thing you can rely on (and it's the only thing) is the minimum OpenGL version supported on a certain operating system.

In Windows you can safely expect to be able to use OpenGL-1.1; if there's no graphics driver installed you'll get a (slow) software fallback.

In Linux (and the other *nix-es except MacOS X follow it) you can expect that if there's a libGL.so around it will give you at least OpenGL-1.2; due to Wayland they're working on a new ABI and last thing I heared is, they want to bump the minimum version requirement to either 1.4 or 2.1, depending on shader support should be optional or not; These days 2.1 would make sense.

In MacOS X the minimum OpenGL version available is also the maximum, and it depends on the actual version of MacOS X installed. Which means, that if you have certain requirements on OpenGL this also imposes a minimum MacOS X version. This is in contrast to Windows and Linux where GPU and/or driver upgrade suffices.

Which means that while on MacOS X everything works out of the box, on Windows and the other *nix-es the API library will give you only 1.1 or 1.2 OpenGL support. So how do you use later OpenGL versions there? Using the

OpenGL extension mechanism

OpenGL always provisioned for a way for vendors to extend the functionality with their own stuff, so called extensions. But the same mechanism that's being used to access vendor extensions is also used to expose later versions of OpenGL; in that case you don't access extensions, but standard functionality, but the functions being used for doing so are the same. It usually goes like this:

• Check if a OpenGL extension or a certain OpenGL version is supported on the system (by parsing the output of glGetString(GL_EXTENSIONS) or glGetString(GL_VERSION) – there are also other methods, but that'd get too long here).
• Use a system specific function to retrieve entry points
• Provide an additional header/include file to declare additional tokens/symbols

Now since the above steps are tedious to do manually, they have been nicely wrapped into extension loader/wrappers that do the whole thing by the call of a single function. The most popular out there is probably GLEW.

Last but not least to use OpenGL you first have to create something to draw onto (a drawable) and a OpenGL context you use to draw with. Both drawable and context creation are annoying to code; not difficult, but just plain annoying, because the APIs involved have been designed for maximum flexibility. However the majority of people just want an ordinary window with a off-the-mill OpenGL context attached to it. So there exist a number of

Frameworks and Libraries for OpenGL window/context management

The most popular library for simple OpenGL demos and tryouts is probably GLUT. GLUT itself is no longer maintained, but there's FreeGLUT which is safe to use.

If you want more control over event management there's GLFW.

Originally not intended for OpenGL, but OpenGL support having found its way into it pretty soon there's SDL, which is very popular among game developers (also AAA ones).

Very popular among C++ folks is SFML

They all have in common that creating a OpenGL window has been reduced from a task that takes over 300 lines of C code (if done properly) to less than 20 lines.

Answer 2

There is no such thing as an integration of OpenGL in C++ - it is a C API, so C++ application code would just call the C functions and link the C libraries. If you can make OpenGL C examples work then they "should just work" when compiling for C++.

HTH, Pete