26 comments

[ 86.0 ms ] story [ 996 ms ] thread
I've gotten through the Getting Started section and found it to be quite good overall. A few times it seems to make some jumps back and forth between slightly different setups, which might lead to some problems debugging.

I definitely recommend it to anyone interested! Honestly one of the biggest things it helps with is explaining the setup boilerplate for OpenGL.

Man, this takes me back! I made a Minecraft clone called Mindacraft in Java using LWJGL (the same framework Minecraft uses) about 6 or 7 years ago using this tutorial. I vividly remember this tutorial being the most useful resource for OpenGL by an order of magnitude, and that was with it being written in a language that actually had pointers and buffers! (Using OpenGL in Java is very weird because you have to use pointers and buffers through a bunch of wrapper classes, and it makes things a lot weirder. It's like using unsafe in Rust if unsafe wasn't even in Rust).
Any recommendations on how to use OpenGL from the CLR (.Net/C#) please?
In 2026: Please don't learn this; it's obsolete. Learn Vulkan (Or another modern API; or how to build engines on top of them; or how to write shaders; or how to do GPU compute using CUDA etc)
The old primitive API was the best. Who invented the new shader API? They ruined my life.
The one and only Holy Bible of Graphics Programming. If you're starting to learn computer graphics, just study through the entire site and do the examples one by one. It doesn't matter one bit that it uses a slightly outdated API called OpenGL - you're supposed to learn how to render things first, not about some weird obscure hardware / driver details!

After you've learned it, you can start learning CUDA if you want to do some more low-level compute stuff on the GPU (sorry, but you should just buy an NVIDIA card, CUDA is just that good). Or if you actually want to just make things but want to use a nicer cross-platform graphics API than OpenGL, then I recommend SDL3. (Or use Metal if you want to make macOS exclusive apps - it's actually a quite nice API)

Vulkan or DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware anymore. (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api). However if you want a computer graphics career (either in the game industry or in other niche domains) having experience with these APIs will be beneficial since these are what many production apps are currently stuck with - though honestly the job market for graphics really suck nowadays. (The biggest sector was triple-A game companies with their own engines, but the game industry is imploding right now...)

> but the game industry is imploding right now...

Why is that? Is it because of AI automating many steps of game creation?

The best selling game of all time (Minecraft) is basically GL 1.1. You really don't need much.
Working through every example in order is the real advice here - the site clicks once you've actually debugged your own framebuffer, not just read the chapter. The math only sticks after you've drawn something wrong a few times.
Honestly, in 2026 I would not really bother with OpenGL. Just start with WebGPU, it's much nicer. You can use it easily on most modern browsers or better can even use native libraries like Dawn or WGPU.
At this point GL is an interface, implementations will come and go, but the interface refuses to die. It's still the simplest way to get started, and the browser (WebGL) demands portability for code written against the API.
Shaders used to not make any sense to me. The tutorial writes a simple expression and boom the screen is displaying all kinds of funky things.

Then I realized you're just writing code that executes on all pixels sequentially. That made it easier to understand

I remember learning OpenGL back in the day with the NeHe tutorials, coding for the Dreamcast :)
That's a name I haven't heard in a long time. It was NeHe and the red book for me.
I cannot imagine a field more rewarding than programming with opengl when you grew up playing games. I'm talking about hobbyist engine type of development. It is almost like therapy for any dev that does web/cloud stuff during a day job.
Lol.. I am the same. My day job is Rust + car headunit development. My drugs of choice are tikz and openscad..
If you really want to learn from first principles, I'd recommend writing a software renderer without any graphics API. If you're looking for a course, see [1]. Next up, extend the software renderer to render a 3D character model (an obj file will suffice) which [1] covers and animate that 3D model with skeletal animation all the while on the CPU. Use quake's md5mesh and md5anim files to render the skeletal animation from [2]. This just lays down a clear foundation of what a rendering pipeline looks like.

Then pick up something like Modern OpenGL and you'll easily intuit if you've put in the hard yards above, which parts of this pipeline are fixed and which are programmable on a hardware designed specifically to do 3D. It just so happens that the same is reusable for compute and there you go with all the D/ML jazz. After this, read up on the HW architecture of GPU's (the literature is sparse as these are vendor locked) but realtimhrendering books has chapters on it and you can find out why Vulkan, DX12, Metal are in vogue now and OpenGL has been deprecated.

[1] https://pikuma.com/courses/learn-3d-computer-graphics-progra...

[2] http://tfc.duke.free.fr/coding/md5-specs-en.html

How does this compare to The OpenGL Programming Guide?
Could you please give some advice on whether there are options as good as Metal for targeting Windows and Linux platforms separately?
Many years ago, I used Learn OpenGL to learn about graphics. It's good to see that it's getting some love now.
I fear that in the future, opengl will be made obsolete and GPU vendors will stop supplying drivers for it, because it won't be worth it for them. Of course there are layers to be put on top of vulkan, but I don't know if they're reliable enough and can support 100% of opengl.

I would say that's one thing that the "stop killing games" movement would not see coming. I am not expert enough in graphics programming.

I am wary because lately, I realized I could not run blender 4.5 on a thinkpad from 2014, on windows, I had to use a 3.x version because that thinkpad has a chipset.

Generally in software, making things work for a long time doesn't generate profits, and it feels like opengl is getting a bit old already. I hope it won't happen and people can contradict me here.