Hacker News Reader

Comment by fsloth | Hacker News Reader

"Vulkan/C? Metal/ObjC†/C? "

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

View on HN

For Rust, there's [1] for OpenGL and [2] for Vulkan.

I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API.

[1] https://github.com/glium/glium

[2] https://github.com/vulkano-rs/vulkano

The sentence in the top of the readme for the github repo is: "Glium is no longer actively developed by its original author."

Which links to: https://users.rust-lang.org/t/glium-post-mortem/7063

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.

E.g. look at what Quake or Doom III does, etc.

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.

There is a better word for this.. People who use operator overloading are a bunch of shmucks (Stupid fools), as my Jewish grandfather would say :)

EA should try banning fools instead . There are many other tools that have to be used appropriately, especially in C++.

Reply on news.ycombinator.com