Hacker News new | ask | show | jobs
by ryandrake 205 days ago
As someone who did OpenGL programming for a very, very long time, I fully agree with you. Without OpenGL being maintained, we are missing a critical “middle” drawing API. We have the very high level game engines, and very low level things like Vulkan and Metal which are basically thin abstractions on top of GPU hardware. But we are missing that fun “draw a triangle” middle API that lets you pick up and learn 3D Graphics (as opposed to the very different “learn GPU programming” goal).

If I was a beginner looking to get a basic understanding of graphics and wanted to play around, I shouldn’t have to know or care what a “shader” is or what a vertex buffer and index buffer are and why you’d use them. These low level concepts are just unnecessary “learning cliffs” that are only useful to existing experts in the field.

Maybe unpopular opinion: only a relative handful of developers working on actually making game engines need the detailed control Vulkan gives you. They are willing to put up with the minutiae and boilerplate needed to work at that low level because they need it. Everyone else would be better off with OpenGL.

5 comments

> Without OpenGL being maintained, we are missing a critical “middle” drawing API.

OpenGL still works. You can set up an old-school glBegin()-glEnd() pipeline in as few as 10 lines of code, set up a camera and vertex transform, link in GLUT for some windowing, and you have the basic triangle/strip of triangles.

OpenGL is a fantastic way to introduce people to basic graphics programming. The really annoying part is textures, which can be gently abstracted over. However, at some point the abstractions will start to be either insufficient in terms of descriptive power, or inefficient, or leaky, and that's when advanced courses can go into Vulkan, CPU and then GPU-accelerated ray tracing, and more.

OpenGL still exists, runs and works fine on the two platforms that matter. I think its death has been overstated quite a bit.

With that said we decided to focus on DX12 eventually because it just made sense. I've written our platform layers targetting OpenGL, DX12, Vulkan and Metal and once you've just internalized all of these I really don't think the horribleness of the lower level APIs is as bad as people make them out to be. They're very debuggable, very clear and well supported.

OpenGL is still being maintained, it just isn't being updated. Since OpenGL 4.0 or something we've had vertex and pixel shaders. As a non-AAA developer, I can't imagine anything else I'd really need.

BTW: If anyone says OpenGL is "deprecated", laugh in their face.

Apple officially deprecated GL/GLES on both MacOS and iOS 7 years ago, and only ever supported up to GL 4.1 (which came out in 2010), meaning it doesn't support essential "modern" features like compute shaders (DX11 had them in 2009), or bindless textures (supported since 2012 on AMD+Nvidia, and 2015 for Intel iGPUs, massive performance win, needed for GPU driven rendering and ray tracing).
Right, and the damage Apple has done to themselves with this policy is several orders of magnitude higher than OpenGL users have suffered from not being able to use OpenGL on Mac or iOS. Apple gets: No indie games that aren't sluggish Unity or Unreal asset flips. OpenGL devs get: Now you need to pay a specialist a few $x,xxx to port your game to iOS if you ever get popular enough that you want your game on the Apple ecosystem.
Apple did that to push people towards their own walled garden of APIs rather than some deficiency of the OpenGL API.

There is no "technical" solution to this, no Even better API that would make them support it, as it's a business decision as much as anything else.

OK, maybe OpenGL is not "unmaintained" but the major OS and hardware vendors have certainly handed him his hat.
If I were starting a new project, would it be unwise to just use OpenGL? It's what I'm used to, but people seem to talk about it as if it's deprecated or something.

I know it is on Apple, but let's just assume I don't care about Apple specifically.

OpenGL is fine, it has the same issues now it had before but none of it really comes from "old age" or being deprecated in any way. It's not as debuggable and much harder to get good performance out of than the lower level APIs but beyond that it's still great.

Honestly, starting out with OpenGL and moving to DX12 (which gets translated to Vulkan on Linux very reliably) is not a bad plan overall; DX12 is IMO a nicer and better API than Vulkan while still retaining the qualities that makes it an appropriate one once you actually want control.

Edit:

I would like to say that I really think one ought to use DSA (Direct State Access) and generally as modern of a OpenGL usage as one can, though. It's easy to get bamboozled into using older APIs because a lot of tutorials will do so, but you need to translate those things into modern modern OpenGL instead; trust me, it's worth it.

Actual modern OpenGL is not as overtly about global state as the older API so at the very least you're removing large clusters of bugs by using DSA.

What do you think makes DX12 better API than Vulkan?
I've found it has less idiosyncrasies, is slightly less tedious in general and provides a lot of the same control, so I don't really see much of an upside to using Vulkan. I don't love the stupid OO-ness of DX12 but I haven't found it to have much of an adverse effect on performance so I've just accepted it.

On top of that you can just use a much better shading language (HLSL) with DX12 by default without jumping through hoops. I did set up HLSL usage in Vulkan as well but I'm not in love with the idea of having to add decorators everywhere and using a 2nd class citizen (sort of) language to do things. The mapping from HLSL to Vulkan was also good enough but still just a mapping; it didn't always feel super straight forward.

(Edit: To spell it out properly, I initially used GLSL because I'm used to it from OpenGL and had previously written some Vulkan shaders, but the reason I didn't end up using GLSL is because it's just very, very bad in comparison to HLSL. I would maybe use some other language if everything else didn't seem so overwrought.)

I don't hate Vulkan, mind you, I just wouldn't recommend it over DX12 and I certainly just prefer using DX12. In the interest of having less translation going on for future applications/games I might switch to Vulkan, though, but still just write for Win32.

OpenGL is still be the best for compatibility in my opinion. I have been able to get my software using OpenGL to run on Linux, Windows, old/new phones, Intel integrated graphics and Nvidia. Unless you have very specific requirements it does everything you need and with a little care, plenty fast.
>Maybe unpopular opinion: only a relative handful of developers working on actually making game engines need the detailed control Vulkan gives you.

If you make a game instead of a game engine, you can use one of the existing engines.

For a while I've been wondering if the push to DX12 or vulkan as the "better" APIs has been a factor in the big engines becoming a near monoculture with games development. Games are very varied in what they require, some push the limits but many releases are more modest yet lots of them are gravitating around full featured leading edge Unreal/Unity. Having a lower barrier to entry for graphics programming that lets them make something that's a closer fit to their requirements.

The other big push would be Epic cutting royalties until you're earning a significant amount, which would encourage studios not to hire or allocating as much resources to in-house.

I don't really think it is related. Graphics aren't really the most difficult part of a modern engine, and there are high quality open-source 3rd party solutions for rendering anyway.

In fact the "engine" part itself is quite small compared to the editor, and the hardest things can be done with third-party solutions, a lot open source: physics, rendering, audio, ECS, controls, asset loading, shader conversion.

The reason people gravitate towards Unity/Unreal is because of the low barrier to entry. This caused the monoculture among hobbyists.

The reason studios are gravitating to those engines is because of there is plenty of cheap labour available.