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...)
Note that I've used the term "Graphics Programming" rather than just "Computer Graphics".
The RTR book doesn't teach you the programming side of things at all, the material is more theoretical and reads more like a reference book. Most importantly it doesn't have any examples with full source code, so it's not a friendly book to follow for beginners. The PBR book is much better in this regard, but it mainly focuses on offline ray tracing / path tracing which is bit of a distinct topic from conventional real-time rendering on the GPU.
I've heard that learning WebGPU is a pretty decent alternative, it's cross-platform, has runners that are non-web, and has some of the niceties of Metal without being platform lock-in
Nothing in real time graphics _actually_ is cross platform. You are always programming a vendor hardware.
"Cross platform" really has no value in graphics programming, honestly, when discussing the lowest level programmable api.
You always need to explicitly say which platforms you target, and then test on those platforms.
The main questions should be "on which platform will my users run it" and "can I debug and test this".
So if you are starting out - pick out the easiest api for you. Don't go looking for universality as a value on it's owm (if you want universal rendering, choose CPU rendering. if you want high perf - choose your GPU platform(s) explicitly).
Indeed, and a well regarded WebGPU guide is also trending on the front page at the same time :P
The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM. In that regard there are also some interesting projects/opportunities.
"The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM"
Having shipped non-trivial WASM code in two projects That's not a positive thing. WASM is stuck in zone between living and the dead - just good enough (barely) to merit creating production code when you need the perf in browser but not good enough to register as industrial quality tool as it's not possible really to debug a WASM application.
If you really, really need the perf in your browser app, WASM may be the only option, but it's not really a good one.
After 15 years, browsers vendors still don't care about 3D APIs on the developer tools, you need to have a native version and hope that the issue is actually on your code and not something that the browser does.
Because of its nature and the browser sandbox, you have no idea if the application is actually working on customer browsers, or even be able to have workarounds like on native APIs.
Finally it lags a decade behind hardware capabilities being surfaced on the API.
However there is nothing else on the browser.
The only positive thing is being 3D APIs designed with managed languages in mind.
Actually, at least on Chromium it's possible to use Dwarf debugging symbols in debugging your wasm files. It's a little tricky because the documentation isn't that clear but I've ran programs through that and it works. Also there a vscode extension (which I prefer over using vs the browser devtools). If you have that it's basically like using any other debugger in vscode (including CodeLLDB) only you launch the browser when you're debugging it.
The extension is "feature complete" and works. Why should it need updates when it's not broken?
It should also work for all compiler toolchains that generate DWARF debug info, which is pretty much standard across all compiled languages, otherwise gdb or lldb couldn't be used either with those languages (Microsoft of course does its own thing, as is tradition, but its not like msvc supports wasm output in the first place - Blazor oth appears to support wasm debugging in VS and VSCode)
No, it’s a combo of a post-covid slump in spend, western markets becoming saturated and an assumption from the majority of industry that wouldn’t happen. Essentially games revenue has grown incredibly over the past twenty years and it’s now crunched to a halt.
Then layer in some incredibly bad bets like Game Pass for XBox and audience tastes shifting away from splashy big budget releases making them an “inevitable” success. It’s left middle aged execs heads in a twist.
In a broader view discoverability is the big problem for everyone. People are hoping in the short term that reducing budgets and scope will save things but all that will do is make the discoverability problem worse. So everyone’s hot under the collar for codev, offshoring, “the Hollywood model*” and so on without looking at the downstream effects of everyone doing that.
AI has largely impacted games by sucking all the available money away and the discoverability problem has made what little is left extremely conservative.
* - This has been a thing for at least three decades now in games despite the obvious collapse of this model and Hollywood.
AI has augmented indies, to go to gfx fidelity only held before by AAA. So the traditional pipelines are going
Add to that a mass-rejection of the media produced by the western DEI priest caste resident in game studios (the players buy games as they used too from china, korea, japan, the slump literally only affects western studios). Nobody goes to a preachy church for escapism. Bad bets all around.
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.
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.
You're absolutely wrong here and without backing it up with strong justification.
FWIW, I work at a FAANG as a HW/SW GPU Engineer, have enough experience to not have any need to do this course but did so to confirm it's appropriate and found it of top notch quality. We don't have enough GPU engineers and recommend this as one of the initial courses when we hire from other domains.
If you want to use the learned knowledge I would recommend to use something like Sokol [0] or use the SDL-GPU API [1]. While Sokol is more higher level both can be used. Otherwise learn opengl is a really good introduction.
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.
I'm not as interested in game development but I'm one of these web/cloud people who finds graphics work extremely therapeutic. I made a box move around on the screen with various easing animations and it was some of the most fun I've ever had programming.
Well depending on transparency and depth buffer it either doesn't matter or really really does....
Also for your confusion it truely is parallel, the best kind in fact. The trivial kind, each pixel's color is independent of every other pixel so you can and thus want too do them ALL at the same time!
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.
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.
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).
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.
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.
In light of WebGPU, I respectfully disagree. Because it has us building shader modules, buffers, and pipelines up-front with descriptors, the task of figuring out why something isn't working is often front-loaded. Pair that with its eloquent warnings (in comparison to, like, gl.getProgramParameter(shader, gl. COMPILE_STATUS) ) and the ability to label all your stuff to see it referred to by name in aforementioned warnings text... I'm rambling, but, there's just a lot of helpful stuff in WebGPU that I don't think OpenGL has, that stands to really help newcomers along
Typically just find bindings for your language and adapt the startup/bootstrap to match your language syntax. Opengl calls are fairly agnostic especially when you move to the shader logic.
The biggest issue with c# dev is OS specific window management. CLR doesn't have good wayland support yet if you're trying to do this from a modern Linux distro.
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)
Im the author of vkguide.dev and i disagree. I wrote that tutorial specifically for people that have already gone through learnopengl and want to learn vulkan.
The core problem with the modern apis is that they are so incredibly complicated that they will kill any newbie on the spot. When the student still doesnt really know what a mesh is, having them setup GPU side memory allocators and graphics compute pipelines is absurd.
Opengl meanwhile is significantly easier, and will give them the important terminology and math required to do graphics. Once the student has learned opengl and wrote a small renderer with a few basic techniques, moving to vulkan or DX12 will happen far more smoothly.
In particular, learnopengl explains a lot of basics like transformation coordinates, what a mesh is, and other similar "basic knowledge", while all vulkan and dx12 tutorials skip through that because they are meant for a much more experienced audience.
The problem with most modern "how to learn graphics programming" guides is that they over index on "low level GPU programming" and under index on important foundational 3D graphics concepts. Transformations and coordinate systems, model space, world space, view space, clip space, normalized device coordinates, screen space, concepts like parallel vs. perspective projection, viewport and viewport transformation, colors, lighting, materials, reflection, blending, antialiasing, texture mapping, various buffer types, tessellation...
You want to start with OpenGL because the API is organized roughly around these high level concepts. Starting with something like Vulkan means you're dropped straight into hundreds of lines of low level boilerplate setting up VkCommandBuffers and VkRenderPasses and VkPipelines and shaders, and all this GPU programming, and it's all just bewildering if you're used to thinking about things at the high level first, or just want to draw a fucking triangle on the screen.
Webgpu is the worst of both worlds. Significantly more complicated than opengl yet not capable of many "essential" modern techniques like bindless resources.
If you must use a modern api to learn for whatever reason, go with vulkan and use dynamic rendering and buffer device addressing.
WebGPU has the issue that feature/capability-wise it is essentially 5 years behind OpenGL 4.6, which came out 8 years ago. And the other downside being that it adopted old Vulkan concepts that even Vulkan started to ditch, like render passes and static pipelines.
For beginners that's irrelevant. WebGPU has more than enough features for beginners to learn about graphics programming. Not just that, once you're used to WebGPU, going to Vulkan will be much easier than the transition from OpenGL.
I wouldnt recommend anyone going to Vulkan, though. It's pretty much the worst graphics API out there, and WebGPU is mimicking outdated Vulkan design decisions that even Vulkan is currently outphasing, like render passes and static pipelines.
The problem with OpenGL isn't so much that its programming model is outdated, but that it is an incredibly confusing and (in many places) just plain badly designed API (just look at VAOs, it's hard to come up with a more broken and useless feature - some of the problems have been salvaged on more recent OpenGL versions, but those are not portable to macOS or GLES3.x).
Another (related) problem is that the many sediment layers that have accumulated over nearly three decades are not clearly separated (and Vulkan is starting to suffer from the same problem btw, there's always at least five different ways to do the same thing, three of which are outdated or not recommended to be used on specific GPU architectures, and the other two have complicated relationships and interdependencies with other redundant or optional features, it's apparently some sort of Khronos curse to always create the biggest possible mess when it comes to 3D APIs).
On Windows (maybe even on Linux via Proton), starting with D3D11 makes a lot more sense, or on macOS with Metal v1. Both APIs are 'close enough' to modern 3D APIs to carry a lot of the knowledge over, but without being too low-level like Vulkan or D3D12, WebGPU running in browsers is also a good choice (even though it inherits some bad design decisions from Vulkan 1.0 when it comes to resource bindings, and is in some places actually slower than WebGL2).
I think the dark side of OpenGL for beginning graphics programming is that debugging can be really frustrating! I really think learnopengl.com should have a mandatory section for how to use RenderDoc (https://renderdoc.org/) - it's night and day if you know how to use it.
DX11 suffers from the problem that there aren't that much high quality material comparable to learnopengl.com - I really don't like RasterTek which just dumps code at you without explaining things properly. Same for Metal - the best way would be to just download and read the example source code from the official Apple site, but it's rather unfriendly for beginners.
> incredibly confusing and (in many places) just plain badly designed API
Thankfully Khronos has ensured Vulkan follows up in this tradition, lets see if the usability improvements from 1.4 onwards are good enough for Vulkan to stay relevant beyond Android, embedded and SteamDeck.
I do agree Vulkan is too cumbersome, but OpenGL is definitely obsolete.
The OpenGL API with its binding-based approach is also very confusing for beginners, but the replacement Direct State Access API came too late (after Apple already decided they would deprecate OpenGL, so it never got supported on macOS).
And the fact that the GLSL parser and compiler are part of the driver means there are tons of hardware-specific bugs and miscompilations. Intel integrated drivers on Windows are notorious for being especially buggy.
All of those make OpenGL a pretty poor target for learning. Personally, I would recommend WebGPU to people who want to get into graphics programming. It's very similar to DirectX/Metal, and like a more streamlined Vulkan. The WGPU implementation of WebGPU has a C API, which also has C++ headers, and a native Rust API. And you can also use WebGPU in your browser from JavaScript, if you don't know any native languages.
What is the current status of WebGPU support in browsers? I tried to get into it a while ago go, when the writing was already on the wall for WebGL. But WebGPU just wasn't there yet, so I had to stick with WebGL.
WebGPU is newer, but lacks modern functionality because it was made to support ancient smartphones. That's great if you want to support ancient smartphones, but not if you want to utilize modern desktop GPUs.
I still think that OpenGL is a better place to start learning 3D because there is so much less bookkeeping to do regarding memory and concurrency vs. Vulkan. I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going...
If you are going to use Vulkan, check out https://howtovulkan.com/ Vulkan started with a lot of compromises to make mobile hardware happy at the expense of making everything overly complicated on desktop. Over the past decade, desktop devs have managed to get a lot of features added to make Vulkan on desktop more sane. How To Vulkan covers that newer approach. This recent video "It's Not About the API" https://www.youtube.com/watch?v=7bSzp-QildA shows how simple it can be if you let it.
And, if you are on a Mac, folks who use Metal like it a lot. Don't worry about lock-in. Once you learn the basics, knowledge is easily transferable to DX12 and Vulkan. You should plan to write 3 or 4 renderers to throw away anyway :P
> I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going...
Is it the AZDO stuff? Quite interested, since there isn't really much information on the Internet about it rather than some slides and GDC videos.
Yep. It's my thesis that early GL APIs feel beginner-friendly because they are so hand-holdy, one-step-at-a-time. But, they end up more complicated when you get serious and they instill bad practices.
Instead, the "modern" APIs allow you to leverage your pre-existing knowledge of "allocate arrays of structs and start indexing them." That's not trivial. But, it is already familiar. And, it ends up a lot better in the end compared to "Invoke whole lot of functions to manipulate a hidden state machine."
OpenGL is limited to 4.1 on Apple platforms if I am not mistaken, and will not get updated ever. So you will run into missing features eventually on some platforms, e.g. SSBOs are really nice but you can't them use on Apple devices.
For me, a much stronger argument against OpenGL is that is requires a global state. This often leads to bad design, is miserable to multi-thread, and is rather tedious to port to Vulkan. I have spent several years fighting with multi-threading applications doing all sort of things in OpenGL and it is not great. Yes, Vulkan is extremely painful to set-up and you have to think about a million things you might not really care about directly, but honestly, I would also recommend against starting anything serious in OpenGL. To get your hands wet maybe, as with a couple lines you can get something running..
I think if you're trapped in the Apple ecosystem then Metal is your only production-quality option. But beginner-level learning material for it is quite sparse, so it's better to transition from OpenGL to Metal rather than learning Metal from scratch. (If you're an experienced graphics dev, you should be able to follow up on Metal by just reading their example source code)
Nope, the limitations are just too huge for actual usage. Heard Godot Engine tried to use MoltenVK for macOS but experienced too many issues so they just developed a Metal backend.
The fundamental problem is Metal 3 is just too high-level to be able to emulate all of Vulkan's behavior. The new Metal 4 API (which is more low level and similar to Vulkan in many ways) might have improved things recently, but sadly MoltenVK hasn't been rewritten to this new API yet.
Worse than OpenGL though? Haven't had the time to really look into it, probably native Metal is better, yes, but either way it might be easier to port/adapt from Vulkan than from OpenGL (due to similar concepts, no global state, etc)
Sadly, the OP is right, OpenGL is deprecated on a number of platforms and down right removed from others. Please don't learn this now. Vulkan has the shape of every modern graphics api out there, DX included. Learn this or at the very least WebGPU.
A data point: "OpenGL ES is still supported on Android, but is no longer under active feature development. Vulkan offers the following advantages over OpenGL ES" "Vulkan is the preferred Android interface to the GPU. Android 15 and up includes ANGLE as an optional layer for running OpenGL ES on top of Vulkan."
This advice is basically like a teenager wanting to play electric guitar to jam out a few rock tunes, but their parents insist on learning classical guitar instead because starting with the fundamentals is the only "real" way to become a great musician. Meanwhile the kid loses interest and moves on to something else.
This analogy doesn't work. Vulkan is more like assembling your own electric guitar from scratch, while OpenGL is a used out of shape electric guitar you found on the flea market that is long since out of production.
If you're in it for learning how to play music, the flea market guitar will serve you better.
Vulkan is garbage. It's completely needlessly overengineered. Like, you literally have to write 50 lines of code just to allocate GPU memory, which is a one-liner in other APIs like CUDA. These 50 lines include things like heap type shopping and usage flags, that are entirely pointless for modern desktop GPUs. I know there is VMA, but that is a poorly made bandaid over a badly designed API, and barely addresses one out of 100 UX issues with Vulkan. There is a reason so many are sticking with OpenGL. OpenGL is fairly bad, but at least it isn't Vulkan.
But I can agree with CUDA. CUDA is great, in a large part because it actually offers an easy to use API.
OpenGL is the only truly cross-platform graphics API out there. Vulkan isn't on Apple platforms, unless you use MoltenVK which implements it on top of Metal. Also I don't know why, but Windows games tend to use Direct3D even though afaik GPU drivers do implement Vulkan on Windows, so there must be a good reason for that.
It's also much easier to grasp than Vulkan, Metal, or Direct3D.
I've never tried developing anything for a 3D-capable console, but I've always had the feeling that their graphics APIs are bespoke, thin abstraction layers on top of the raw graphics hardware just so you don't have to poke the GPU registers directly.
Yes, they are quite low level, hence how painful Vulkan happens to be, as its design was driven by console vendors feedback, and based on Mantle, basically AMD trying to make a PC API close to how modern consoles work.
While there have some support, Playstation 3 had OpenGL ES 1.0 with Cg for shading, Wii had a GL like API with GLSL subset, and SWitch does support GL 4.6/Vulkan, they were never fully adopted by devs, rather favouring the native ones.
OpenGL is arguably still better for learning the fundamentals of computer graphics. All you really want early on is a simple vertex and fragment shader up and running so that you can learn how to move a camera around, transform objects, basic lighting and texturing, etc. Vulkan is overkill for that. If you follow the LearnOpenGL tutorials you'll get as far as HDR lighting and shadows. At that point you'll be better equipped to understand an API like Vulkan and probably a lot more successful at porting an engine over to it.
In 2026: Yes yes, please please learn this if you're beginning computer graphics. This is basically the One and Only Holy Bible of graphics programming, and dealing with a slightly outdated and weird API doesn't make it worse even a teeny bit. You will never get the same quality of fundamental education material from any of the other tutorials (especially Vulkan ones, since most of them assume you already know the basics and delve straight into writing thousands of lines of code that doesn't even perform better than OpenGL). You need to first learn the really basic things like homogeneous coordinates, matrix transforms, vertex and fragment shaders, various shading models like Phong and PBR, multi-pass rendering, etc, before actually diving into lower-level details where you want to optimize things.
Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api) - if you want to really learn the low-level details you should start diving into something like CUDA or get into graphics driver development (start by reading Mesa open source driver code - which you will then learn why Vulkan is flawed)
> You will never get the same quality of fundamental material
If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API.
> Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware
> If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API.
I've never seen a more detailed tutorial than LearnOpenGL that actually goes through the concepts of graphics programming thoroughly and actually make things other than just "learn how to use the API". That alone should be enough to cement the site's longevity.
> And OpneGL is worse
It's never late to learn Vulkan / DX12 after learning learnopengl.com! The value of learnopengl.com isn't in the APIs, it's about learning the basic concepts of graphics programming. If you start learning with Vulkan without any prerequisite knowledge, you'll be bogged in low-level details from the start that isn't really related with learning the actual fundamentals. (And you'll probably have to unlearn Vulkan and DX12 again once a new API has surfaced)
Have you actually read the linked site beyond its name? The site is about fundamentals. Yes, it contains OpenGL code, but what it covers is the fundamentals of real time graphics, not just OpenGL API.
> Have you actually read the linked site beyond its name? The site is about fundamentals.
Is it? All the fundamentals are tied to how it's done in OpenGL with somewhat sparse explanations in between. And many "fundamentals" are literally something like
Yes, it is. Most articles there are practically API-agnostic. Just because the code examples happen to be written with OpenGL it doesn't mean it's about OpenGL.
Even the code snippets start with "#version 330", if you implement these in another tech stack (say vulkan+slang) the relevant shader code would look very similar. It's quite strange to me that you think just because of "#version 330" it's not about fundamentals, tbh.
Despite the name, GLSL is still used all over the place in Vulkan pipelines. The site teaches you the shader approach (rather than the fixed function pipeline of the 90s) which is what the "modern" Vulkan stack uses too.
That was the absolute minimal example of where "fundamentals" immediately devolve into a very specific code targeting a very specific API. See also sibling comment: https://news.ycombinator.com/item?id=49027094
Mesa has Zink which translates OpenGL to Vulkan. AFAIK Asahi uses it because they only wrote a native Vulkan driver for the hardware, no native OpenGL driver.
Apple themselves also don't ship a native OpenGL driver anymore, only a layer that translates OpenGL to Metal.
> write old OpenGL and translate it on the fly to Vulkan
Apple's OpenGL on macOS and iOS has been a shim over Metal for a very long time. The feature set is stuck somewhere between GL 3.x and 4.1 though (e.g. no compute shaders), but not for technical reasons.
It is also the simplest and most widely available one[0], working from decades old PCs to whatever is latest one, not only from the official drivers but also 3rd party implementations[1] that target other lower level APIs for environments where there isn't an official implementation.
[0] on open platforms at least
[1] it most likely wont be a 100% compliant one (even SGI had trouble on that front :-P) but in practice it'd be usable
Wonder how this opinion will age. Won't be surprised if in 10 years OpenGL will be more widely supported and used than Vulkan. It's the Lindy effect after all.
All I can say for certain is that 10 years from now there will great OpenGL-to-VulcanMetalWhatever translators, at least as good as the ones already built-in to several graphics stacks today, and the learnopengl.com tutorial and examples will still work. So unless you actually intend to compete with AAA game engine designers, you may safely invest your time in OpenGL.
The anti OpenGL sentiment is so strange to me. OpenGL is basically supported everywhere even in places where Vulkan is unpopular.
Any sane person who actually wants to do low level graphics programming should rather work on the libgodot effort since it will make it much easier to use Godot as a wrapper around Metal and Vulkan by defining a custom RenderingServer without even touching the Godot scene graph or having Godot own your application lifecycle.
I still write games using OpenGL for the reasons described in the comments here. I've had very good results with it despite it being "old". It works on my MacBook, PC, and SteamDeck and it has yet to surprise me.
Relatedly: could someone recommend a Vulkan introduction for people who don't "just want to make it work"? I understand the fact that Vulkan abstracts away a lot less of the rendering device than OpenGL does – that may be a strength or a weakness, but either way I'd like to understand. It seems a lot of introductions just skip over it all while apologizing for the boilerplate.
I think I once bookmarked an article which takes an interesting approach, namely doing all rendering with Vulkan compute! Does that ring a bell to anyone? I can't find it again. It seems very appealing to me. It may not be the best way to approach graphics, but I know a lot more about computations in general than I do graphics in particular. And knowing Vulkan Compute would help me in lots of ways, so it I can also use it for graphics that's a nice bonus.
>could someone recommend a Vulkan introduction for people who don't "just want to make it work"?
Khronos has a tutorial that walks you through getting a triangle on the screen, to rendering a glTF model, all the way up to how you go about making a simple engine.
But I'm not sure what you mean by "understand". If you want to understand the graphics theory, Vulkan tutorials aren't going to teach you that.
> But I'm not sure what you mean by "understand". If you want to understand the graphics theory, Vulkan tutorials aren't going to teach you that.
I meant understand the Vulkan-specific minutiae of setting everything up for either graphics or compute. There's an order of magnitude or two more of it than for OpenGL, and lots of tutorials seem to skip it and focus on the graphics. I'd like to understand what all that setup does and why it's done a particular way.
Trying to learn Vulkan as a first API is doable, but you'll probably burn yourself out by the time you've gotten a triangle on the screen (unless you vibe code everything, in which case, you're lame).
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...)
>The one and only Holy Bible of Graphics Programming.
The textbooks Real Time Rendering and Physically Based Rendering are far more deserving of such claims.
Note that I've used the term "Graphics Programming" rather than just "Computer Graphics".
The RTR book doesn't teach you the programming side of things at all, the material is more theoretical and reads more like a reference book. Most importantly it doesn't have any examples with full source code, so it's not a friendly book to follow for beginners. The PBR book is much better in this regard, but it mainly focuses on offline ray tracing / path tracing which is bit of a distinct topic from conventional real-time rendering on the GPU.
The best selling game of all time (Minecraft) is basically GL 1.1. You really don't need much.
Nope it uses modern OpenGL and LWJGL bindings under the hood. Recently they're in the process of switching the entire thing to Vulkan.
Yes, but that was after it became famous, the point being that gameplay matters most.
I've heard that learning WebGPU is a pretty decent alternative, it's cross-platform, has runners that are non-web, and has some of the niceties of Metal without being platform lock-in
" it's cross-platform"
Nothing in real time graphics _actually_ is cross platform. You are always programming a vendor hardware.
"Cross platform" really has no value in graphics programming, honestly, when discussing the lowest level programmable api.
You always need to explicitly say which platforms you target, and then test on those platforms.
The main questions should be "on which platform will my users run it" and "can I debug and test this".
So if you are starting out - pick out the easiest api for you. Don't go looking for universality as a value on it's owm (if you want universal rendering, choose CPU rendering. if you want high perf - choose your GPU platform(s) explicitly).
as a mac user who does suffer from the insanity of compiled for Mac, but never tested on a Mac, thank you.
Indeed, and a well regarded WebGPU guide is also trending on the front page at the same time :P
The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM. In that regard there are also some interesting projects/opportunities.
"The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM"
Having shipped non-trivial WASM code in two projects That's not a positive thing. WASM is stuck in zone between living and the dead - just good enough (barely) to merit creating production code when you need the perf in browser but not good enough to register as industrial quality tool as it's not possible really to debug a WASM application.
If you really, really need the perf in your browser app, WASM may be the only option, but it's not really a good one.
> That's not a positive thing.
Quite right.
After 15 years, browsers vendors still don't care about 3D APIs on the developer tools, you need to have a native version and hope that the issue is actually on your code and not something that the browser does.
Because of its nature and the browser sandbox, you have no idea if the application is actually working on customer browsers, or even be able to have workarounds like on native APIs.
Finally it lags a decade behind hardware capabilities being surfaced on the API.
However there is nothing else on the browser.
The only positive thing is being 3D APIs designed with managed languages in mind.
Actually, at least on Chromium it's possible to use Dwarf debugging symbols in debugging your wasm files. It's a little tricky because the documentation isn't that clear but I've ran programs through that and it works. Also there a vscode extension (which I prefer over using vs the browser devtools). If you have that it's basically like using any other debugger in vscode (including CodeLLDB) only you launch the browser when you're debugging it.
> as it's not possible really to debug a WASM application
...as others have said, this is a solved problem and has been for quite a while:
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
I might even go that far and say that this solution is on average more robust and more responsive than debugging native code in Xcode.
Hmm I never could get the DWARF debug information to hook up properly, must give this a try next time I need to return to the topic.
If you don't mind - what's your specific setup when debugging Sokol, I might start from replicating that workflow?
Basically this, just with code-generated launch.json which starts a regular node https server (eg fewer extensions needed than in this blog post):
https://floooh.github.io/2023/11/11/emscripten-ide.html
> Last updated 27/09/2023
And only "works" for specific languages.
The extension is "feature complete" and works. Why should it need updates when it's not broken?
It should also work for all compiler toolchains that generate DWARF debug info, which is pretty much standard across all compiled languages, otherwise gdb or lldb couldn't be used either with those languages (Microsoft of course does its own thing, as is tradition, but its not like msvc supports wasm output in the first place - Blazor oth appears to support wasm debugging in VS and VSCode)
Microsoft isn't the only platform doing its own thing, although this is irrelevant for this specific case.
Given how bad most of WebAssembly tooling still is to this day, versus native languages, I was kind of sceptic.
Idk maybe you were working on far more complex things but personally I didn't feel this way.
Then again perhaps the devx was just not as bad as I expected given how often I had heard this warning.
> but the game industry is imploding right now...
Why is that? Is it because of AI automating many steps of game creation?
No, it’s a combo of a post-covid slump in spend, western markets becoming saturated and an assumption from the majority of industry that wouldn’t happen. Essentially games revenue has grown incredibly over the past twenty years and it’s now crunched to a halt.
Then layer in some incredibly bad bets like Game Pass for XBox and audience tastes shifting away from splashy big budget releases making them an “inevitable” success. It’s left middle aged execs heads in a twist.
In a broader view discoverability is the big problem for everyone. People are hoping in the short term that reducing budgets and scope will save things but all that will do is make the discoverability problem worse. So everyone’s hot under the collar for codev, offshoring, “the Hollywood model*” and so on without looking at the downstream effects of everyone doing that.
AI has largely impacted games by sucking all the available money away and the discoverability problem has made what little is left extremely conservative.
* - This has been a thing for at least three decades now in games despite the obvious collapse of this model and Hollywood.
AI has augmented indies, to go to gfx fidelity only held before by AAA. So the traditional pipelines are going
Add to that a mass-rejection of the media produced by the western DEI priest caste resident in game studios (the players buy games as they used too from china, korea, japan, the slump literally only affects western studios). Nobody goes to a preachy church for escapism. Bad bets all around.
Modern gaming hardware is getting increasingly inaccessible and the micro transaction infected mobile gaming market is the only one make money.
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.
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
There's no need to pay for questionable courses. Here's an excellent free alternative that covers all the basics:
https://haqr.eu/tinyrenderer/
>> need to pay for questionable courses
You're absolutely wrong here and without backing it up with strong justification.
FWIW, I work at a FAANG as a HW/SW GPU Engineer, have enough experience to not have any need to do this course but did so to confirm it's appropriate and found it of top notch quality. We don't have enough GPU engineers and recommend this as one of the initial courses when we hire from other domains.
I have done both. Personally, I've found the the pikuma.com course to be extremely more valuable and more in-depth.
The author of this course is among the best professors I’ve had back in university, I’m happily surprised to see his work shared here
That course was posted just yesterday, in case you are interested in the discussion about it: https://news.ycombinator.com/item?id=49022038
If you want to use the learned knowledge I would recommend to use something like Sokol [0] or use the SDL-GPU API [1]. While Sokol is more higher level both can be used. Otherwise learn opengl is a really good introduction.
[0] https://github.com/floooh/sokol [1] https://wiki.libsdl.org/SDL3/CategoryGPU
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.
I'm not as interested in game development but I'm one of these web/cloud people who finds graphics work extremely therapeutic. I made a box move around on the screen with various easing animations and it was some of the most fun I've ever had programming.
Lol.. I am the same. My day job is Rust + car headunit development. My drugs of choice are tikz and openscad..
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
> executes on all pixels sequentially
or in parallel?
Now that I think about it, parallel makes more sense since it's GPU accelerated, but now I'm back to being confused lol
Well depending on transparency and depth buffer it either doesn't matter or really really does....
Also for your confusion it truely is parallel, the best kind in fact. The trivial kind, each pixel's color is independent of every other pixel so you can and thus want too do them ALL at the same time!
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.
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.
Cem Yuksel's lecture videos for Interactive Computer Graphics at the University of Utah are another free and fantastic resource. https://www.youtube.com/playlist?list=PLplnkTzzqsZS3R5DjmCQs...
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.
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).
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.
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.
OpenGL is still the simplest way to start learning hardware accelerated rendering, and it runs on all modern platforms.
In light of WebGPU, I respectfully disagree. Because it has us building shader modules, buffers, and pipelines up-front with descriptors, the task of figuring out why something isn't working is often front-loaded. Pair that with its eloquent warnings (in comparison to, like, gl.getProgramParameter(shader, gl. COMPILE_STATUS) ) and the ability to label all your stuff to see it referred to by name in aforementioned warnings text... I'm rambling, but, there's just a lot of helpful stuff in WebGPU that I don't think OpenGL has, that stands to really help newcomers along
Game consoles aren't modern platforms?
Any recommendations on how to use OpenGL from the CLR (.Net/C#) please?
Typically just find bindings for your language and adapt the startup/bootstrap to match your language syntax. Opengl calls are fairly agnostic especially when you move to the shader logic.
The biggest issue with c# dev is OS specific window management. CLR doesn't have good wayland support yet if you're trying to do this from a modern Linux distro.
I can recommend OpenTK [0]. I've used it recently to create a 3D renderer, and I have not run into any issues.
[0] https://opentk.net/
Could you please give some advice on whether there are options as good as Metal for targeting Windows and Linux platforms separately?
How does this compare to The OpenGL Programming Guide?
Many years ago, I used Learn OpenGL to learn about graphics. It's good to see that it's getting some love now.
Is it possible to complete this course on an M1 Mac?
Yes, OpenGL 4.1 is available, just deprecated. It's emulated through Metal, and so will work on M chips.
Should be, OpenGL still runs on MacOS.
The old primitive API was the best. Who invented the new shader API? They ruined my life.
If you want to use glBegin() / glEnd() - like immediate API with modern OpenGL, I reecommend using a library called RLGL (https://github.com/raysan5/raylib/blob/master/src/rlgl.h), from Raylib. You'll feel straight at home!
Same sentiment here. My litmus test is - after creating a window - "how many lines of code does it take to render a triangle?".
With the old OpenGL API you could do this in like 10 lines of code (probably even less with SGI's GL).
With the new/shader-based API, well... https://learnopengl.com/Getting-started/Hello-Triangle
Vulkan - I don't even want to know.
> Vulkan - I don't even want to know
Almost 1000: https://github.com/Overv/VulkanTutorial/blob/main/code/15_he...
(From Chapter 15 of the Vulkan Tutorial from vulkan-tutorial.com)
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)
Im the author of vkguide.dev and i disagree. I wrote that tutorial specifically for people that have already gone through learnopengl and want to learn vulkan. The core problem with the modern apis is that they are so incredibly complicated that they will kill any newbie on the spot. When the student still doesnt really know what a mesh is, having them setup GPU side memory allocators and graphics compute pipelines is absurd.
Opengl meanwhile is significantly easier, and will give them the important terminology and math required to do graphics. Once the student has learned opengl and wrote a small renderer with a few basic techniques, moving to vulkan or DX12 will happen far more smoothly.
In particular, learnopengl explains a lot of basics like transformation coordinates, what a mesh is, and other similar "basic knowledge", while all vulkan and dx12 tutorials skip through that because they are meant for a much more experienced audience.
The problem with most modern "how to learn graphics programming" guides is that they over index on "low level GPU programming" and under index on important foundational 3D graphics concepts. Transformations and coordinate systems, model space, world space, view space, clip space, normalized device coordinates, screen space, concepts like parallel vs. perspective projection, viewport and viewport transformation, colors, lighting, materials, reflection, blending, antialiasing, texture mapping, various buffer types, tessellation...
You want to start with OpenGL because the API is organized roughly around these high level concepts. Starting with something like Vulkan means you're dropped straight into hundreds of lines of low level boilerplate setting up VkCommandBuffers and VkRenderPasses and VkPipelines and shaders, and all this GPU programming, and it's all just bewildering if you're used to thinking about things at the high level first, or just want to draw a fucking triangle on the screen.
> The core problem with the modern apis is that they are so incredibly complicated that they will kill any newbie on the spot.
I would agree if by modern you mean DX12 or Vulkan, but WebGPU (and maybe even Metal) are quite decent.
Webgpu is the worst of both worlds. Significantly more complicated than opengl yet not capable of many "essential" modern techniques like bindless resources.
If you must use a modern api to learn for whatever reason, go with vulkan and use dynamic rendering and buffer device addressing.
WebGPU has the issue that feature/capability-wise it is essentially 5 years behind OpenGL 4.6, which came out 8 years ago. And the other downside being that it adopted old Vulkan concepts that even Vulkan started to ditch, like render passes and static pipelines.
For beginners that's irrelevant. WebGPU has more than enough features for beginners to learn about graphics programming. Not just that, once you're used to WebGPU, going to Vulkan will be much easier than the transition from OpenGL.
I wouldnt recommend anyone going to Vulkan, though. It's pretty much the worst graphics API out there, and WebGPU is mimicking outdated Vulkan design decisions that even Vulkan is currently outphasing, like render passes and static pipelines.
Without any sort of proper debugging tools.
OpenGL is not obsolete and is totally fine for many use cases. Vulkan is way too complicated and cumbersome for many.
Even if OpenGL doesn't get new features what exists now will continue to work for decades.
The problem with OpenGL isn't so much that its programming model is outdated, but that it is an incredibly confusing and (in many places) just plain badly designed API (just look at VAOs, it's hard to come up with a more broken and useless feature - some of the problems have been salvaged on more recent OpenGL versions, but those are not portable to macOS or GLES3.x).
Another (related) problem is that the many sediment layers that have accumulated over nearly three decades are not clearly separated (and Vulkan is starting to suffer from the same problem btw, there's always at least five different ways to do the same thing, three of which are outdated or not recommended to be used on specific GPU architectures, and the other two have complicated relationships and interdependencies with other redundant or optional features, it's apparently some sort of Khronos curse to always create the biggest possible mess when it comes to 3D APIs).
On Windows (maybe even on Linux via Proton), starting with D3D11 makes a lot more sense, or on macOS with Metal v1. Both APIs are 'close enough' to modern 3D APIs to carry a lot of the knowledge over, but without being too low-level like Vulkan or D3D12, WebGPU running in browsers is also a good choice (even though it inherits some bad design decisions from Vulkan 1.0 when it comes to resource bindings, and is in some places actually slower than WebGL2).
I think the dark side of OpenGL for beginning graphics programming is that debugging can be really frustrating! I really think learnopengl.com should have a mandatory section for how to use RenderDoc (https://renderdoc.org/) - it's night and day if you know how to use it.
DX11 suffers from the problem that there aren't that much high quality material comparable to learnopengl.com - I really don't like RasterTek which just dumps code at you without explaining things properly. Same for Metal - the best way would be to just download and read the example source code from the official Apple site, but it's rather unfriendly for beginners.
> incredibly confusing and (in many places) just plain badly designed API
Thankfully Khronos has ensured Vulkan follows up in this tradition, lets see if the usability improvements from 1.4 onwards are good enough for Vulkan to stay relevant beyond Android, embedded and SteamDeck.
I do agree Vulkan is too cumbersome, but OpenGL is definitely obsolete.
The OpenGL API with its binding-based approach is also very confusing for beginners, but the replacement Direct State Access API came too late (after Apple already decided they would deprecate OpenGL, so it never got supported on macOS).
And the fact that the GLSL parser and compiler are part of the driver means there are tons of hardware-specific bugs and miscompilations. Intel integrated drivers on Windows are notorious for being especially buggy.
All of those make OpenGL a pretty poor target for learning. Personally, I would recommend WebGPU to people who want to get into graphics programming. It's very similar to DirectX/Metal, and like a more streamlined Vulkan. The WGPU implementation of WebGPU has a C API, which also has C++ headers, and a native Rust API. And you can also use WebGPU in your browser from JavaScript, if you don't know any native languages.
What is the current status of WebGPU support in browsers? I tried to get into it a while ago go, when the writing was already on the wall for WebGL. But WebGPU just wasn't there yet, so I had to stick with WebGL.
As always, a decade behind current hardware capabilities andnl browser vendors refuse to have debugging tools.
You need a native build for proper GPU debugging, or do shader printf debugging style.
However, it is what is available.
> Personally, I would recommend WebGPU to people who want to get into graphics programming.
Unfortunately WebGPU is like 5 years behind OpenGL 4.6, which is already 8 years old. WebGPU is pretty ancient.
WebGPU only got started in 2021, so Im not sure what you mean. Could you explain? (Or are you thinking of WebGL?)
WebGPU is newer, but lacks modern functionality because it was made to support ancient smartphones. That's great if you want to support ancient smartphones, but not if you want to utilize modern desktop GPUs.
Thanks, that makes sense
I still think that OpenGL is a better place to start learning 3D because there is so much less bookkeeping to do regarding memory and concurrency vs. Vulkan. I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going...
If you are going to use Vulkan, check out https://howtovulkan.com/ Vulkan started with a lot of compromises to make mobile hardware happy at the expense of making everything overly complicated on desktop. Over the past decade, desktop devs have managed to get a lot of features added to make Vulkan on desktop more sane. How To Vulkan covers that newer approach. This recent video "It's Not About the API" https://www.youtube.com/watch?v=7bSzp-QildA shows how simple it can be if you let it.
And, if you are on a Mac, folks who use Metal like it a lot. Don't worry about lock-in. Once you learn the basics, knowledge is easily transferable to DX12 and Vulkan. You should plan to write 3 or 4 renderers to throw away anyway :P
> I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going...
Is it the AZDO stuff? Quite interested, since there isn't really much information on the Internet about it rather than some slides and GDC videos.
Yep. It's my thesis that early GL APIs feel beginner-friendly because they are so hand-holdy, one-step-at-a-time. But, they end up more complicated when you get serious and they instill bad practices.
Instead, the "modern" APIs allow you to leverage your pre-existing knowledge of "allocate arrays of structs and start indexing them." That's not trivial. But, it is already familiar. And, it ends up a lot better in the end compared to "Invoke whole lot of functions to manipulate a hidden state machine."
You can find a little info on Modern OpenGL at https://github.com/fendevel/Guide-to-Modern-OpenGL-Functions, https://juandiegomontoya.github.io/modern_opengl.html, https://ktstephano.github.io/, https://patrick-is.cool/posts/2025/on-vaos/
OpenGL is limited to 4.1 on Apple platforms if I am not mistaken, and will not get updated ever. So you will run into missing features eventually on some platforms, e.g. SSBOs are really nice but you can't them use on Apple devices.
For me, a much stronger argument against OpenGL is that is requires a global state. This often leads to bad design, is miserable to multi-thread, and is rather tedious to port to Vulkan. I have spent several years fighting with multi-threading applications doing all sort of things in OpenGL and it is not great. Yes, Vulkan is extremely painful to set-up and you have to think about a million things you might not really care about directly, but honestly, I would also recommend against starting anything serious in OpenGL. To get your hands wet maybe, as with a couple lines you can get something running..
I think if you're trapped in the Apple ecosystem then Metal is your only production-quality option. But beginner-level learning material for it is quite sparse, so it's better to transition from OpenGL to Metal rather than learning Metal from scratch. (If you're an experienced graphics dev, you should be able to follow up on Metal by just reading their example source code)
There are a few nice books, they are a bit out of date though.
MoltenVK is pretty good I've been told
Nope, the limitations are just too huge for actual usage. Heard Godot Engine tried to use MoltenVK for macOS but experienced too many issues so they just developed a Metal backend.
The fundamental problem is Metal 3 is just too high-level to be able to emulate all of Vulkan's behavior. The new Metal 4 API (which is more low level and similar to Vulkan in many ways) might have improved things recently, but sadly MoltenVK hasn't been rewritten to this new API yet.
Worse than OpenGL though? Haven't had the time to really look into it, probably native Metal is better, yes, but either way it might be easier to port/adapt from Vulkan than from OpenGL (due to similar concepts, no global state, etc)
Yes, hence there is now a new layer, KosmicKrisp.
Sadly, the OP is right, OpenGL is deprecated on a number of platforms and down right removed from others. Please don't learn this now. Vulkan has the shape of every modern graphics api out there, DX included. Learn this or at the very least WebGPU.
A data point: "OpenGL ES is still supported on Android, but is no longer under active feature development. Vulkan offers the following advantages over OpenGL ES" "Vulkan is the preferred Android interface to the GPU. Android 15 and up includes ANGLE as an optional layer for running OpenGL ES on top of Vulkan."
https://developer.android.com/games/develop/vulkan/overview
Android smartphones are notorious in having low-quality Vulkan drivers full of bugs and spec violations... (I'm looking at you Qualcomm!)
A data point: SDL3-GPU maintainers announced that they will not give a shit about Android support, since there's just too many devices that haven't properly implemented the Vulkan spec. (https://github.com/libsdl-org/SDL/issues/12652#issuecomment-...)
Another data point: the current maintainer of the renderer portion of the Godot engine suffering through all the bug reports from Android devices (https://github.com/godotengine/godot/issues?q=is%3Aissue%20s...)
Is the GL driver any better? (It sounds like it is?) It's Direct3D on windows all over again :-(
Nope, as Google has moved to use Angle on top of Vulkan.
Ironically, the Vulkan discord always complains about the bad support of Vulkan on mobile devices, and how OpenGL ES is still better supported.
Google has moved Android to having only Vulkan, with OpenGL ES on top via Angle, exactly to force OEMs to actually care about Vulkan support.
Until now it has been pretty much only usable on Google and Samsung phones.
This advice is basically like a teenager wanting to play electric guitar to jam out a few rock tunes, but their parents insist on learning classical guitar instead because starting with the fundamentals is the only "real" way to become a great musician. Meanwhile the kid loses interest and moves on to something else.
This analogy doesn't work. Vulkan is more like assembling your own electric guitar from scratch, while OpenGL is a used out of shape electric guitar you found on the flea market that is long since out of production.
If you're in it for learning how to play music, the flea market guitar will serve you better.
Except that Vulkan is the classic guitar here, you will suffer with it before your first triangle while with OpenGL you can jam almost instantly.
Vulkan is garbage. It's completely needlessly overengineered. Like, you literally have to write 50 lines of code just to allocate GPU memory, which is a one-liner in other APIs like CUDA. These 50 lines include things like heap type shopping and usage flags, that are entirely pointless for modern desktop GPUs. I know there is VMA, but that is a poorly made bandaid over a badly designed API, and barely addresses one out of 100 UX issues with Vulkan. There is a reason so many are sticking with OpenGL. OpenGL is fairly bad, but at least it isn't Vulkan.
But I can agree with CUDA. CUDA is great, in a large part because it actually offers an easy to use API.
OpenGL is the only truly cross-platform graphics API out there. Vulkan isn't on Apple platforms, unless you use MoltenVK which implements it on top of Metal. Also I don't know why, but Windows games tend to use Direct3D even though afaik GPU drivers do implement Vulkan on Windows, so there must be a good reason for that.
It's also much easier to grasp than Vulkan, Metal, or Direct3D.
Contrary to urban myths, OpenGL never was a big thing on game consoles.
Windows official API is DirectX, OpenGL and Vulkan use a plugin API, ICD, which is nonetheless DirectX underneath.
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
> OpenGL never was a big thing on game consoles.
I've never tried developing anything for a 3D-capable console, but I've always had the feeling that their graphics APIs are bespoke, thin abstraction layers on top of the raw graphics hardware just so you don't have to poke the GPU registers directly.
Yes, they are quite low level, hence how painful Vulkan happens to be, as its design was driven by console vendors feedback, and based on Mantle, basically AMD trying to make a PC API close to how modern consoles work.
https://github.com/sigmaco/mantle-docs
https://ir.amd.com/news-events/press-releases/detail/466/amd...
While there have some support, Playstation 3 had OpenGL ES 1.0 with Cg for shading, Wii had a GL like API with GLSL subset, and SWitch does support GL 4.6/Vulkan, they were never fully adopted by devs, rather favouring the native ones.
OpenGL is deprecated and version locked on Mac/iOS.
OpenGL is arguably still better for learning the fundamentals of computer graphics. All you really want early on is a simple vertex and fragment shader up and running so that you can learn how to move a camera around, transform objects, basic lighting and texturing, etc. Vulkan is overkill for that. If you follow the LearnOpenGL tutorials you'll get as far as HDR lighting and shadows. At that point you'll be better equipped to understand an API like Vulkan and probably a lot more successful at porting an engine over to it.
In 2026: Yes yes, please please learn this if you're beginning computer graphics. This is basically the One and Only Holy Bible of graphics programming, and dealing with a slightly outdated and weird API doesn't make it worse even a teeny bit. You will never get the same quality of fundamental education material from any of the other tutorials (especially Vulkan ones, since most of them assume you already know the basics and delve straight into writing thousands of lines of code that doesn't even perform better than OpenGL). You need to first learn the really basic things like homogeneous coordinates, matrix transforms, vertex and fragment shaders, various shading models like Phong and PBR, multi-pass rendering, etc, before actually diving into lower-level details where you want to optimize things.
Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api) - if you want to really learn the low-level details you should start diving into something like CUDA or get into graphics driver development (start by reading Mesa open source driver code - which you will then learn why Vulkan is flawed)
> You will never get the same quality of fundamental material
If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API.
> Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware
And OpneGL is worse
> If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API.
I've never seen a more detailed tutorial than LearnOpenGL that actually goes through the concepts of graphics programming thoroughly and actually make things other than just "learn how to use the API". That alone should be enough to cement the site's longevity.
> And OpneGL is worse
It's never late to learn Vulkan / DX12 after learning learnopengl.com! The value of learnopengl.com isn't in the APIs, it's about learning the basic concepts of graphics programming. If you start learning with Vulkan without any prerequisite knowledge, you'll be bogged in low-level details from the start that isn't really related with learning the actual fundamentals. (And you'll probably have to unlearn Vulkan and DX12 again once a new API has surfaced)
> It's never late to learn Vulkan / DX12 after learning learnopengl.com!
Why would you do that? Why would you want to learn an API for graphics cards from the 90s instead of an API for the graphics card from the 2010s?
> The value of learnopengl.com isn't in the APIs, it's about learning the basic concepts of graphics programming.
Then you should learn concepts of graphics programming that isn't defined with code snippets like
?> And you'll probably have to unlearn Vulkan and DX12 again once a new API has surfaced
Strange. You "have to unlearn a newer API when an even newer one has surfaced, but you should learn this ancient API anyway".
Edit. See also another comment: https://news.ycombinator.com/item?id=49027094
Have you actually read the linked site beyond its name? The site is about fundamentals. Yes, it contains OpenGL code, but what it covers is the fundamentals of real time graphics, not just OpenGL API.
> Have you actually read the linked site beyond its name? The site is about fundamentals.
Is it? All the fundamentals are tied to how it's done in OpenGL with somewhat sparse explanations in between. And many "fundamentals" are literally something like
Yes, it is. Most articles there are practically API-agnostic. Just because the code examples happen to be written with OpenGL it doesn't mean it's about OpenGL.
https://learnopengl.com/PBR/Lighting
Even the code snippets start with "#version 330", if you implement these in another tech stack (say vulkan+slang) the relevant shader code would look very similar. It's quite strange to me that you think just because of "#version 330" it's not about fundamentals, tbh.
It's not just because of that. Everything is steeped in OpenGL API. All the "fundamentals" are about OpenGL.
Another link floated to the top of HN discussion just now, and every sibgle link there is better than these "fundamentals": https://news.ycombinator.com/item?id=49022038 E.g. "Computer Graphics from Scratch" https://gabrielgambetta.com/computer-graphics-from-scratch/ or Mathematics for Computer Graphics https://www.amazon.co.uk/Mathematics-Computer-Graphics-John-...
Here's the Vulkan version of that:
Despite the name, GLSL is still used all over the place in Vulkan pipelines. The site teaches you the shader approach (rather than the fixed function pipeline of the 90s) which is what the "modern" Vulkan stack uses too.That was the absolute minimal example of where "fundamentals" immediately devolve into a very specific code targeting a very specific API. See also sibling comment: https://news.ycombinator.com/item?id=49027094
>covers is the fundamentals of real time graphics
It does not cover all the fundamentals. It hardly explains the necessary math.
> And OpneGL is worse
I disagree. OpenGL is truly bad, but there is no API in this world as bad as Vulkan.
It's so much easier than Vulkan or writing shaders and the performance is more than good enough for a lot of applications.
I wonder if somebody has written a adapter layer to write old OpenGL and translate it on the fly to Vulkan?
Mesa has Zink which translates OpenGL to Vulkan. AFAIK Asahi uses it because they only wrote a native Vulkan driver for the hardware, no native OpenGL driver.
Apple themselves also don't ship a native OpenGL driver anymore, only a layer that translates OpenGL to Metal.
> write old OpenGL and translate it on the fly to Vulkan
Apple's OpenGL on macOS and iOS has been a shim over Metal for a very long time. The feature set is stuck somewhere between GL 3.x and 4.1 though (e.g. no compute shaders), but not for technical reasons.
> It's so much easier than Vulkan or writing shaders
Even if you use OpenGL you still need to write shaders.
OpenGL 1.x is older than the hills.
It is also the simplest and most widely available one[0], working from decades old PCs to whatever is latest one, not only from the official drivers but also 3rd party implementations[1] that target other lower level APIs for environments where there isn't an official implementation.
[0] on open platforms at least
[1] it most likely wont be a 100% compliant one (even SGI had trouble on that front :-P) but in practice it'd be usable
Shaders aren't the issue with Vulkan. Writing 50 lines of code for things that should be one-liners is.
Wonder how this opinion will age. Won't be surprised if in 10 years OpenGL will be more widely supported and used than Vulkan. It's the Lindy effect after all.
All I can say for certain is that 10 years from now there will great OpenGL-to-VulcanMetalWhatever translators, at least as good as the ones already built-in to several graphics stacks today, and the learnopengl.com tutorial and examples will still work. So unless you actually intend to compete with AAA game engine designers, you may safely invest your time in OpenGL.
The anti OpenGL sentiment is so strange to me. OpenGL is basically supported everywhere even in places where Vulkan is unpopular.
Any sane person who actually wants to do low level graphics programming should rather work on the libgodot effort since it will make it much easier to use Godot as a wrapper around Metal and Vulkan by defining a custom RenderingServer without even touching the Godot scene graph or having Godot own your application lifecycle.
I still write games using OpenGL for the reasons described in the comments here. I've had very good results with it despite it being "old". It works on my MacBook, PC, and SteamDeck and it has yet to surprise me.
Relatedly: could someone recommend a Vulkan introduction for people who don't "just want to make it work"? I understand the fact that Vulkan abstracts away a lot less of the rendering device than OpenGL does – that may be a strength or a weakness, but either way I'd like to understand. It seems a lot of introductions just skip over it all while apologizing for the boilerplate.
I think I once bookmarked an article which takes an interesting approach, namely doing all rendering with Vulkan compute! Does that ring a bell to anyone? I can't find it again. It seems very appealing to me. It may not be the best way to approach graphics, but I know a lot more about computations in general than I do graphics in particular. And knowing Vulkan Compute would help me in lots of ways, so it I can also use it for graphics that's a nice bonus.
>could someone recommend a Vulkan introduction for people who don't "just want to make it work"?
Khronos has a tutorial that walks you through getting a triangle on the screen, to rendering a glTF model, all the way up to how you go about making a simple engine.
But I'm not sure what you mean by "understand". If you want to understand the graphics theory, Vulkan tutorials aren't going to teach you that.
> But I'm not sure what you mean by "understand". If you want to understand the graphics theory, Vulkan tutorials aren't going to teach you that.
I meant understand the Vulkan-specific minutiae of setting everything up for either graphics or compute. There's an order of magnitude or two more of it than for OpenGL, and lots of tutorials seem to skip it and focus on the graphics. I'd like to understand what all that setup does and why it's done a particular way.
>I'd like to understand what all that setup does and why it's done a particular way.
That's something you'll only understand after trying to build something non-trivial with an older graphics API like OpenGL.
Nonsense. Man-made things can be explained by humans without needing to experience what came before.
Sure, it can be. Doesn't mean you'll take much away from it unless you're deeply familiar with the old ways of doing things.
Trying to learn Vulkan as a first API is doable, but you'll probably burn yourself out by the time you've gotten a triangle on the screen (unless you vibe code everything, in which case, you're lame).
OpenGL works fine, I'm using it in my hobby game engine (shaders, not the old fixed-function OpenGL)
it also will run just fine on windows or Linux using Proton with no issues
if I had to learn Vulkan from scratch instead, that would have been a whole different animal...
[dead]