I'm trying to find out whether or not I want to switch from Java to c++ for my OpenGL game programming. I now have setup a test project in VS 11 professional, with GLUT. I created my windows with GLUT, and I can render OpenGL primitives without any problems.

Now my question: What library(s) is/are used mostly in the indie/semi professional industry for using OpenGL in c++?

With 'using OpenGL' I mean:

  • Creating and managing an OpenGL window
  • Actually using the OpenGL API
  • Handling user-input (keyboard/mouse)
  • 1
    \$\begingroup\$ You could use SDL for that. Your question is off-topic for the site, as it is a "which tech to use" question. See help: gamedev.stackexchange.com/help/on-topic \$\endgroup\$
    – Lasse
    Nov 9, 2013 at 22:51
  • \$\begingroup\$ There isn't an easy way to answer this question since the professional industry will largely be using proprietary frameworks. So the answer then is, unique in-house libraries. \$\endgroup\$ Nov 9, 2013 at 22:54
  • \$\begingroup\$ Definitely not off-topic, as this has nothing to do with what technology to use. It's about what library to use for certain requirements, in this case what libraries are used mostly. \$\endgroup\$
    – Basaa
    Nov 9, 2013 at 23:04
  • \$\begingroup\$ I don't know what is the difference between what library to use and what technology to use :) they are basically the same question. regardless free GLUT, SDL is used alot between hobbyists, Win32 or any other platform specific window system is usually used in professional industry. \$\endgroup\$
    – concept3d
    Nov 9, 2013 at 23:17
  • \$\begingroup\$ SDL for handling window and input(2.0 version for modern OpenGL). CEGUI for GUI. Perhaps STB for Image loading. Bullet for collision detection/handling(tough that has java bindings too). Fmod/OpenAL for audio. ENet for networking. \$\endgroup\$
    – akaltar
    Nov 9, 2013 at 23:49

1 Answer 1


Qt, SFML, GLFW, SDL, GLUT. All do Windowing and Input. I've got more in depth descriptions and links here.

Qt is the only one that handles some of the OpenGL API itself (as opposed to just making the OpenGL context), but I'm not sure I would want to use it over native OpenGL and afaik it's only some things like shaders (and maybe a simple scene graph). Qt is also fairly heavy if you just want a basic game as it's a whole Widget toolkit.

As for directly interacting with OpenGL API there's not too much.

You will probably want an extension loader like GLEW. Also some support libraries that don't directly interface with OpenGL like GLM for matrix functions, assimp for mesh loading, and stuff like texture loading.

Other than that there are some C++ bindings that wrap the older raw C OpenGL API. I know of 2.

OOGL gives full object orientated bindings. However there are problems with OOP and OpenGL. One example is you can often set things like buffer attributes for your entire scene then just draw all the meshes with the same settings. With OOP it's not possible to do that and so you take an efficacy hit. There are also problems with side effects, for example some commands require things to be binded so a seemly simple command to change a shader property could change your active shader, Direct State Access, glProgramUniform (as opposed to glUniform*) and similar functions could help avoid that to some degree but in the real world you will likely need fallbacks for older systems and they are probably still less efficient than doing things in bulk. There's also issues surrounding multiple OpenGL contexts.

The other library doesn't bother with OOP but just takes the C api and adds things like proper C++ types for type safety. Not sure it's worth the dependency though. I think OGLplus works that way (but I'm not %100 sure).

Realistically you would be better off targeting higher functionality and just using raw OpenGL under the hood. Instead of dealing with raw shaders/programs, deal with materials. And instead of directly calling the OpenGL API in the objects its probably better to put things into some kind of a render pipe (like a command list, but you can do things like sort meshes by material and draw them in one go). I haven't seen any libraries that just do that.

Otherwise you can go the next level and start looking at an engine and avoid directly deraling with OpenGL at all. For example Gameplay 3D

  • \$\begingroup\$ I think GLFW is what he's looking for. \$\endgroup\$ Nov 10, 2013 at 0:44
  • \$\begingroup\$ @CPP_Person I started with GLFW myself, but it is quite limited in terms of window handling. For example you cannot change from windowed to fullscreen mode without destroying the OpenGL context. So I head over to SFML which works good for me. It also does some multi media handling like loding images and playing audio on a basic level, which is another plus in my opinion. \$\endgroup\$
    – danijar
    Nov 10, 2013 at 17:16

Not the answer you're looking for? Browse other questions tagged .