C++11 friendly graphics library

Question

After several years of developing in other languages, I'm getting back into C++ because of some of the nice features being introduced with ISO C++11. Are there any libraries (DirectX/OpenGL based) that make use of these new features in their public API (shared ptrs, lambda friendly, etc)?

EDIT: The library can be in beta status too as I don't expect any library to be commercially-ready on a spec that isn't fully released yet.

Jamarjamb

Since this has led to a debate in the comments below: are you interested in 3D graphics? 2D? … – Overcareful

At this point, I'm just looking to get into some kind of game development using all the new standards. Either 2D or 3D libraries are fine with me. – Jamarjamb

Answer 1

As far as I know, there's still no complete C++11 compiler. G++ is pretty close but isn't there yet. I'd suggest to wait. It makes sense to study the language (even if it isn't available), but I think it'll take few years for dust to settle down.

As far as I know, there's little place to use any "advanced" language features (that even includes everything that was present in c++03) in any graphic library. Trying to fully utilize hardware resources isn't the place where it makes sense to use "programming kung-fu" - you'll end up being worried about other things, and KISS principle takes priority. Its either that or you end up diving into some kind of very specific mind-destroying trigonometric nightmare, where KISS principle takes priority once again.

As far as I know, changing graphical API because of single language is not worth it, because availability in multiple languages is more important. That's especially true about OpenGL, but even DirectX had some "fan-made" bindings.

At the moment you're free to use whatever features you want while developing custom frameworks that operate on top of existing 3d API. Shared/weak pointers are useful in resource managment. However, there's no reason to utilize C++11 for that, because functionality is available in boost.

--EDIT--

Qt 5 is said to have C++11 support. It is technically a graphical library that uses OpenGL...

Unimproved

You don't need the x after C++11 (probably mixing it up with C++0x) :) . – Wingspread

Qt 5 looks to be the most promising library for c++11, but as a whole, it doesn't look like many libraries are looking at the new standard. – Jamarjamb

@JonathanDunlap: That's because there's no fully compliant compiler. There won't be many libraries until at least several C++11 compilers appear. I think this will take a while. – Unimproved

Answer 2

From the README:

Magnum is 2D/3D graphics engine written in C++11/C++14 and modern OpenGL. Its goal is to simplify low-level graphics development and interaction with OpenGL using recent C++11/C++14 features and to abstract away platform-specific issues.

Subdivision

Answer 3

Nothing prevents you from using eg. lambdas, auto and initializer lists in any code.

Gtkmm and relatives (you may enjoy Cairo C++ bindings) have clean C++ interfaces, which allow you to use lambdas and autos when you see fit. It is quite useful to be able to use a lambda as a signal handler, and to use auto when initializing a variable from a Gtk smart pointer.

Also, graphical code is often a quite minor part of an application, and for the other parts, you can use proper C++ with its full blown standard library.

Other than that, support for C++11 is not quite there (Visual studio is far behind, g++'s support is not yet complete), and thus libraries designed for C++11 are not yet here.

Nothing prevents you from trying and making your own :)

Laboratory

Answer 4

The closest to what you want is probably SFML which is a quite clean object wrapper around OpenGL that uses modern C++ idioms more or less throughout.

It’s not using C++11, however, and it’s much too large to be just ported over (it includes sound, networking and lots more in addition to graphics).

I think it could serve as a good basis for an incremental API update to C++11 however.

Overcareful

SFML is in no way, shape, or form a wrapper around OpenGL. It wraps sprite rendering, but OpenGL can do a lot more than that. – Crinite

@Nicol SFML does way more than “sprite rendering”. It may not encompass the complete feature set of OpenGL … but hey, that’s huge. – Overcareful

They categorically refused to implement sRGB framebuffers, on the grounds that a linear color pipeline and color-accurate rendering was not "an important feature." Also worthy of quoting, "Most people using SFML are beginners, or write 2D games." These are the makers of the library saying this, not me. So I'll defer to their opinion of what SFML is. – Crinite

What good is an incomplete wrapper? It just means you'll have to peak under the hood to do the interesting stuff at some point, thus making it not only incomplete, but leaky. – Crinite

@Nicol Almost every wrapper is incomplete. Heck, the .NET framework still doesn’t completely wrap WinAPI; for the same reason, it’s also leaky (but as Joel said, every abstraction is leaky). So what? You (or rather, they) are right about their target group. Again: so what? For 2D graphics this is possibly the best free C++ library. They intentionally do not address 3D. This is a completely valid design decision. If you want 3D, SFML is not for you. If you don’t … well, maybe. – Overcareful

It's not a valid design decision for a wrapper library. It's a valid design decision for a 2D rendering library that uses OpenGL as its basis. There's a difference between those two concepts. The purpose of a wrapper is to expose the old API in a new form. The purpose of a 2D rendering library is to let you render 2D stuff. SFML is not an OpenGL wrapper; it's a 2D renderer that uses OpenGL. – Crinite

@KonradRudolph: "that’s huge" If you're talking about SFML, then huge != useful. I could never comprehend why somebody decided to make another library when SDL is already available. Sounds like pointless waste of human resources to me. IMO it would have been better if devs implemented something else instead. "this is possibly the best free C++ library" I'd advise to avoid ever saying "the best" about anything related to programming. It starts flamewars. – Unimproved

@NicolBolas: Your definition of the term "wrapper" is not universally agreed upon, but that's beside the point, since the OP didn't ask about a wrapper. SFML is a clean Open-GL based library that uses modern C++ idioms more or less throughout. – Teacake

@NicolBolas: I was surprised at your insistence on your answer here and in other places on this question coupled with your obvious lack of knowledge in the field. There are hundreds of c++ wrappers on Open GL and DirectX. Ogre3D has a huge following in the free world. Major c++ game engines like Gamebryo build top selling games like Fallout and Elder Scrolls. I really don't know where you are coming from, but it's clear you can make assertions without knowing. – Juline

@Unimproved SDL doesn’t have a modern C++ interface; SFML does and consequently makes using it much easier than SDL. That’s really all the motivation that’s necessary. It’s the same rationale that fuels Boost.Format, Boost.MPI, Boost.uBLAS and even Boost.Spirit (after all, there’s lex/yacc). It certainly isn’t a “pointless waste of human resources”. – Overcareful

@KonradRudolph: I'm not convinced. If the code looks "more modern" it doesn't mean it is more useful. OpenGL doesn't have "modern C++ interface" either, and people still use it. Same applies to DirectX. – Unimproved

@Unimproved I doubt a single AAA game studio codes to raw DX or OpenGL for most of their code. And your “more modern != more useful” argument, while generally true, is a straw-man: how would you apply it to SFML (say) without also applying it to the other libraries I mentioned? Would call those pointless too? The productivity gain by having a clean interface that takes care of managing resources for you (which is most of what these libraries do) is a huge boon. – Overcareful

@KonradRudolph: "without also applying it" It also applies to libraries you mentioned to some extent. I'm not a big fan of Boost, although there are portions I use (libraries you mentioned aren't one of them). Boost gives impression that its developers wanted to create the most sophisticated solution possible, instead of simplest possible solution. Going after "extensibility" is a very dangerous path - it is quite easy to get carried away and spend a lot of time simply modifying class hierarchy without actually doing something useful that improves software... – Unimproved

@KonradRudolph: (continued) a good example of this problem is boost.polygon. It is very extensible, but its performance is horrible compared to Clipper library - which isn't extensible at all. As for authomatic resource management, it can be taken care of using few very thin wrappers, that certainly do not require separate full-blown libraries. Once you have thin wrappers, you can concentrate on more important things. – Unimproved

@KonradRudolph: Also, regarding SFML: a correct (IMO) solution would be to build it on top of SDL or another existing cross-platform framework, and then add whatever API was missing, and maybe few wrappers (if you're that fond on "modern interfaces"). Instead it looks like they reimplemented the damn thing from scratch. This is what I call a waste of human resources. In addition to SDL there was already Allegro library, so no matter how you look at it, SFML looks like a waste of development time to me. – Unimproved

@Unimproved Regarding the precise design decisions of SFML it sounds like I would agree with you. SFML certainly reinvented the wheel at least in some parts and its design is therefore questionable. – Overcareful

Answer 5

Well, no on OpenGL because it is a C compatible API.

As far as DirectX goes, they certainly aren't going to go and change the API all over the place just to include neat language features like lambdas when it isn't necessary. C++11 compilers are still not in common use compared to previous revisions of the standard, so it would be very silly to create an API that only a small portion of developers can use.

There are broad implications to changing your API when thousands/millions of people use it. It would be hugely irresponsible of them to add lambdas to API functions just because they're neat and shiny. On top of that, it's not like you can just go around breaking your API with each new version if you care about people actually using it.

EJDIT:

I misunderstood the question at first. C++11 is so new that there are likely no API changes to existing libraries as of yet because it would severely limit their userbase (there is no fully featured C++11 compiler out at this time as far as I am aware, and even if there were most of us wouldn't be using it yet).

As some of the commenters rightly pointed out, I was too narrow in my initial response. You added that a beta version would be acceptable. I am still unaware of any libraries which have drastically modified their API's to include new features in C++11, and my previous point still stands.

Changing API function signatures is dangerous because you break backward compatibility. If/when these changes do arrive I would expect them to be additions to the API, not modifications. Perhaps someone around here knows of very recent changes to existing libraries that I am unaware of.

At

DirectX is also a C friendly API. Or at least their coding practices in their tutorials and books are very c-like. – Infusive

Uhm, the OP asked for DirectX/OpenGL-based libraries. – Waterway

I think this answer completely misses the point. You can write a C++11 friendly wrapper around DX or OpenGL. – Overcareful

This answer sounds bitter more than anything. – Cumin

@Konrad: Yes, but who's going to bother? The reason to code directly to GL or D3D is performance. And you don't use a wrapper, even a thin wrapper, if performance matters to you. – Crinite

@Mranz: Bitter? Really? Ok... I suppose I did overlook the OpenGL/DirectX based libraries bit, but what serious projects use wrappers around DirectX and/or OpenGL? Why would I introduce unnecessary obscurity and abstraction to my performance critical code (I wouldn't). That is tangential to the question though, and I don't have experience with libraries that essentially wrap OpenGL or DirectX. – At

@KonradRudolph: As I just said, sure you can, but no serious game dev house is going to use them. – At

@EdS.: "Why would I introduce" To deal with resource management, and implement game features you want. OpenGL doesn't have "multi-material mesh" or "skeletally animated mesh" or "bsp level", DirectX9 had such mesh, but only as a part of extension library and it wasn't that good. It is also easier to deal with custom thin wrappers than IDirect3DTexture9/GLuints directly. – Unimproved

@EdS.: "but what serious projects use wrappers" All of them. They're called "game engines". – Unimproved

@SigTerm: Right, which are either developed in house or they use a proven engine. These are custom, they are not publically available wrappers and don't bring along with them the problems associated with using an abstraction you didn't write and may not have the source to. The answer is still no here, no one at this point will have built an engine using C++11 features. At least, if they have, no serious development house will use them. – At

@EdS.: Umm, I suggest to do reality check. You do know that quake/doom (including 3) source code was released for free, right? There were tons of commercial projects that used SDL, and there are plenty of game engines that come with source code. Wrappers are common. Aside from performance, you have to worry about development time/resource leaks, so using wrappers makes sense. – Unimproved

@SigTerm: I think you missed the "may or may not" bit... pretty key. Anyway, I wouldn't consider a game engine a wrapper for a graphics library anyway. It uses a graphics library, and certainly it abstracts that away from you, but it adds on a ton of functionality. If we're going with your definition, then you may as well call RoR an HTTP wrapper. – At

@EdS.: Moving the goalposts? When wrapper is part of engine it is no longer a wrapper? I'm out of here. – Unimproved

@SigTerm: Calling a game engine a graphics engine wrapper is just wrong. It does a lot more than that. You seem to conveniently ignore certain things that I say, for example: "[a game engine] uses a graphics library, and certainly it abstracts that away from you, but it adds on a ton of functionality" – At

Who's even talking about "serious game dev houses" here? Do you realize how popular SDL is? No AAA title uses it, but you seriously need to reassess what the OP is even asking for. – Vespasian

@ildjarn: I think you're right about that, I initially thought he was asking if OpenGL or DirectX had modified their API. Talk about "serious dev houses" came from me after it turned into a debate. – At

@Nicol That is unsubstantiated and just plain not true. The whole of STL is a wrapper. It has no performance overhead in many situations over hand-coded loops. Heck, even DX and OpenGL are a wrapper around the graphics driver. Are you seriously telling me that no game developer is using them because of their speed impact? – Overcareful

The DX API is actually pretty easy to use, thanks to C++11. Custom deleters on smart pointers make dealing with COM objects a breeze. – Searcy

@Konrad: "The whole of STL is a wrapper." std::list is not a wrapper around a linked list; it is a linked list. Every std::list provides it's own implementation of a linked list. Every std::map provides its own implementation of a balanced binary tree. And so on. The only standard container that you could call a wrapper is vector. Unless you're telling me that every library is a wrapper (in which case the word has no meaning). – Crinite

@Konrad: "Are you seriously telling me that no game developer is using them because of their speed impact?" There are a fair number of game developers who want to code directly to the driver. They can't, because the various OS's do not let them. They use D3D and OpenGL because they have to, because they are the lowest level APIs available to interface with the GPU. – Crinite

DirectX Tool Kit uses a number of C++11 constructs as well. Microsoft::WRL::ComPtr is the way to go for a COM object smart pointer. – Chandrachandragupta