PortableGL: An implementation of OpenGL 3.x-ish in clean C

In a past life, I actually worked on the Linux graphics stack full-time. I'd say my recommendations are based on years of experience and also mentorship.

> On Android, I'd say the Vulkan tools are, in fact, quite excellent.

It's possible my knowledge is out of date, but the last time I tried to debug Vulkan on Android, the official Google Android tool was known as GAPId. It was in beta and it crashed with an error message when I tried to use on our game.

It seems that Google has deprecated it (of course) and replaced it with this: https://gpuinspector.dev/ which says "Coming soon: Take a capture of a single frame to step through and profile each individual draw call.". It doesn't yet look like it's anywhere near the level of tooling provided by RenderDoc, the Xcode tools, PIX, or Razor, but I might be wrong. I admittedly haven't worked on Android in a few years, so I'd love to know updates from the tooling perspective here.

> The main problem is that "modern" graphics is only tangentially related to rendering triangles--and rendering triangles is normally what beginners really want to do.

I'm not sure I categorically agree with that. Vulkan, D3D12, and such all have ample support for drawing triangles, DrawIndexed is still a cornerstone of all the APIs. I'm, of course, very familiar with the latest advancements with Nanite and visibility buffers and all that, but these aren't things that I'd say the modern APIs are explicitly designed for. Nanite infamously uses a persistent compute shader kernel for its culling workers that is currently undefined behavior (but works on all devices, and probably will continue working for eternity).

D3D12's validation layers are much better managed than the Vulkan ones, generally tend to output more helpful messages, and aren't as slow at doing resource tracking.

Vulkan has a lot of dead weight in its APIs, and mistakes that made its way into the spec. Subpasses are over-complicated and do not provide much benefit, even on tilers. Pipeline derivatives are worthless (Qualcomm, who pushed hard for them, found they provided a 2% speedup to pipeline compilation assuming you were using them in a way that only Qualcomm could support, but caching removed the rest of the gains). Push descriptors should basically never be used (they're limited to a single dynamic descriptor, and slow on most IHVs).

These are all things that I've seen beginners stumble into, and I have to spent time explaining why these features just aren't helpful. It's harder for a new beginner to know the best course of action, and which 5 of the 7 features should be used when trying to, say, bind resources to a given draw call. I wish the spec was more active in trying to mark bad ideas as such, but the nature of multi-IHV participation means you won't get that kind of filter.

Pretty much anyone who works in 3D graphics acknowledges that Direct3D is head and shoulders above OpenGL in terms of ease of use, tooling, and support from GPU vendors, and has been for many years now. Even Carmack has come around to this perspective. Really the only reason to use OpenGL is to target Linux, Android, and formerly macOS -- and since game vendors don't really want to do that, now you know why many games and engines support Direct3D exclusively.

The thing you have to understand about Microsoft is that "Developers! Developers! Developers!" isn't just a meme to them. They really put the developer experience front and center and it shows. It shows in Direct3D, it showed in Internet Explorer back in the day, and it shows in things like Visual Studio Code today. Sometimes the Microsoft stuff is simply better.

> "Modern" graphics is mostly about creating a bunch of low-resolution "geometry buffers" and then scanning every single pixel on the screen only once while building the pixel up from some mathematical combination of those lower resolution buffers.

Pretty amazing how "modern" graphics is a fancier version of Atari 7800 graphics! The 7800 didn't have tiles and sprites as such; rather it had per-scanline display lists specifying locations in RAM where graphic bitmaps were stored; the graphics chip pulled the pixel colors from the memory pointed to by the appropriate display list entry as part of the scanout process.

That depends pretty much where one is located on the globe.

1. Never use old-school glUniforms (use UBOs)

2. Never use the old glTexImage functions (use glTexStorage)

3. Always use the new DSA stuff (don't bother with the old binding stuff, except when they forgot to make DSA replacements)

4. Don't bother using render buffers, just use textures.

5. Make sure to use the new, new, new vertex buffer system (or just move your vertex fetching to pulling), VAOs are unfortunate

6. Still too easy to accidentally stall the mainloop with accidental stalls (e.g. never call glReadPixels unless you have a PBO bound)

You still have an unfortunate thing in the case of the default FBO, which gives you a depth buffer on your scanout you probably don't want. Maybe there's a way configure out of that, I forget if e.g. eglChooseConfig lets you opt out of the depth buffer, but I don't believe it's possible on wgl/glx.

There's others I can think of but you just have to be extra careful and the number of concepts still obscures how a GPU works. Maybe I'll write more about this at some point.

I actually consider dealing with buffers and shaders to be far nicer and clearer than dealing with the old 1.x style API but I suppose for someone already intimately familiar with it that might not be the case.

I understand if someone already has an existing codebase that uses the old stuff, but if you were starting a project from scratch it really isn't that hard to use 3.3+. And once you do it once, you never have to think about the setup process again, you already have your helper functions for loading shaders and other things. You don't even have to write your own, there are so many helper libraries out there, and things like GLM to give you every math related thing you'd ever need.