| > This really doesn't mean much. The second cube (or another shape) isn't going to double the line count. That's an absurd standard. "Writing an OS is easy, because once you've written enough code to get Doom to run, firing up a second copy of Doom is relatively straight-forward!" It's those first 600 lines that are the problem. There's now a steep learning curve and lots of boilerplate required for even trivial use cases, where there wasn't before. That's a loss. > The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for performance. Once you move to zero driver overhead techniques for OpenGL then Vulkan is not that much harder. Again, mad standard. "Writing Vulkan shouldn't be a problem for people who write complex zero driver overhead code for OpenGL." Great. What about the other 99% of people? I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it. In giving up OpenGL we're giving up a sane, standard way to do graphics programming, and exchanging it for a choice between (i) making everyone write mad Vulkan boilerplate for control they don't need, or (ii) choosing between a bewildering array of engines and frameworks and libraries, none of which work at all similarly, many of which are still very immature. And it's obvious which one will win - whichever proprietary, SaaS monolith emerges to clean up the mess. Losing OpenGL is a huge set back for open standards, honestly. The principal beneficiaries of depreciating OpenGL will be the shareholders of Unity, in the end. |
If you can write that OS in anything close to 600 lines then yes, it is easy.
The point is that more realistic OpenGL and Vulkan projects will have a much smaller relative size difference.
> Great. What about the other 99% of people?
They can use higher-level abstractions built on top of Vulkan. Or spend some time learning to use Vulkan directly.
> I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it.
Disagree.
> In giving up OpenGL we're giving up a sane, standard way to do graphics programming
Sane is not a word I would use to describe OpenGL. It has managed to collect many warts over the years and as I have already mentioned, what performs well is not at all intuitive.
> (i) making everyone write mad Vulkan boilerplate for control they don't need, or (ii) choosing between a bewildering array of engines and frameworks and libraries, none of which work at all similarly, many of which are still very immature.
"Oh no, so many options". A nice problem to have.
> And it's obvious which one will win - whichever proprietary, SaaS monolith emerges to clean up the mess. Losing OpenGL is a huge set back for open standards, honestly. The principal beneficiaries of depreciating OpenGL will be the shareholders of Unity, in the end.
Wild and unfounded speculation. You can already use ANGLE, which is open source, as your middleware today if you like the OpenGL API so much.