Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon.
If one deploys only to OS X/IOS, Metal and ObjC, sure.
"From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†."
With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including:
Which pretty much states that Glium is not a really long term viable solution at the moment.
I've toyed with cool open source libraries for 20 years. I'm too old to get caught up with something new and shiny only to find out it wasn't structurally sound.
That is why C++ is a good choice. It has huge traction. The ecosystem is basically bullet proof. It has lot of practical libraries that are so well used that while not bullet proof themselves, it is likely they will stay alive as long as you need to compile your code.
Immediately after that, it says: "That said, PRs are still welcome and maintenance is continued by the surrounding community."
> Which pretty much states that Glium is not a really long term viable solution at the moment.
Except what that post-mortem is _really_ saying is that OpenGL is not a long-term viable solution. The whole post-mortem is about the fact that OpenGL drivers are so buggy that you can't write portable code to target it.
"OpenGL drivers are so buggy that you can't write portable code to target it."
Sure, that's why generic non-platform specific OpenGL wrapper is a bad idea, unless you have an army of engineers to apply kludges and workarounds. I'm sorry the author had to find out this the hardest way. The quality of OpenGL drivers has always been like this.
One way of writing portable OpenGL is to look at what some popular game with open source is doing, and copy their approach, because the likelihood of a) the bugs that title triggered are mostly fixed and/or b) they managed to avoid the biggest potholes.
For the several dozen EA games I worked on, in C++, all operator overloading was banned. Too many fools play dumb tricks with operator overloading, so it was declared illegal. I don't miss it, as it is a fool's tool.
Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon.
If one deploys only to OS X/IOS, Metal and ObjC, sure.
"From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†."
With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including:
https://vulkan-tutorial.com/ https://learnopengl.com/
[0] http://eigen.tuxfamily.org/index.php?title=Main_Page [1] https://glm.g-truc.net/0.9.9/index.html