I’d be interested to hear from people currently working w OpenGL in any capacity - what does all this mean in 2021 wrt Vulkan? By way of example, Wayland is ~12 years old, and in my (BSD) world, just starting to become interesting to me.
But IMO Vulkan is way too much for most indies, small studios and solo developers to work with. I doubt we'll see many games targeting Vulkan as "the" multi-platform API like we've seen with OpenGL in the last 15 years. Anyone having to target Vulkan will have to use Unreal/Unity3D. Or maybe someone will develop a wrapper that converts OpenGL calls into Vulkan calls.
Honestly I see Vulkan as akin to regulatory capture. It will only enrich the big players by forcing small companies to use big engines.
EDIT: To give a concrete example, we (part time indie team) have an unfinished renderer in Vulkan, and it's already almost 5x larger than the other (finished) ones. To use Vulkan effectively, even on small games means you need a substantially large abstraction layer. Sure, it doesn't matter on AAA or for commercial engines, but not everyone is on such large projects.
Despite the name, it is available as a native API, with multiple implementation. I think it is a quite good choice for an API to target today.
I would not say that at all. The biggest disadvantage of Vulkan is that it doesn't support old GPUs
I feel like in the games space, if you’re not going through Unity or Unreal then it still makes a lot of sense to target OpenGL for most games rather than going to Vulkan. I definitely still get a bunch of error reports from folks whose computers don’t have OpenGL drivers capable of a context >2.1 on Windows, and I expect that sort of problem would be even more common for Vulkan. Mac hasn’t been a problem thus far, as long as you don’t need advanced 4.x features (I’m just using a 3.3 core context)
While the ‘average’ hardware shown in the Steam hardware surveys is pretty good (better than all of my dev machines, in fact), being the support contact for my game has definitely demonstrated that the standard deviation on that hardware goes down as well as up, and sometimes by quite a lot!
I’d love to play with Vulkan someday, but I worry about support, especially on really old hardware.
(Other thoughts: in indie spaces, it probably makes a lot more sense to use Unity or Unreal or Godot rather than rolling your own. And in AAA spaces, you’d be silly not to go Vulkan instead of OpenGL. It’s really only in my unusual “I happen to have already rolled my own engine and I’m using it to make an indie game” case where OpenGL makes a lot of sense to me)
For some reason, OpenGL still works, and very well, including doing gradients in 10bit colour space.
And it actually depends on what one calls "old".
I have a laptop i bought around late 2012 with a GeForce 660M. It can run a lot of stuff, including some recent games at very low settings - but Vulkan is not supported at all since Nvidia stopped releasing new drivers for it.
Similarly i have a GPD Win 1, it can only run lightweight games because it has an Atom CPU with integrated graphics - still for many smaller indie games (including some 3D games) that hardware should be enough. But under Windows there is no Vulkan support (the hardware can support it but Intel hasn't released any drivers). There is support under Linux, but then a lot of other stuff doesn't work.
In my new engine i was considering going with Vulkan or sticking with OpenGL (with which i am already comfortable anyway) and even made a binding generator for Free Pascal but then i noticed that aside of my main PC no other computer i have in my house supports Vulkan - and i'd like to have at least an Nvidia and AMD GPU to test. So i decided to stick with OpenGL for the time being as i really want to be able to run it on my portable PCs. I might consider a Vulkan renderer in the future but that would be after Vulkan is available even on whatever is considered old low end devices at the time.
https://developer.android.com/about/dashboards#Vulkan
And if one goes into the spaghetti extension soup that Vulkan carried on from OpenGL, the picture is even more sad.
https://www.vulkan.gpuinfo.org/listdevices.php?platform=andr...
On a platform where Vulkan is nowadays the main 3D API, with a roadmap to run OpenGL on top of it.
I do, however, very much look forward to WebGPU, which seems heavily based on modern Vulkan, Metal and DirectX, but it's comperatively easy to set up and work with. Major downside is the lack of cutting-edge features because WebGPU is targeting the lowest common denominator (=smartphones, and also the lowest feature set that all backends (DirectX, Vulkan, Metal) offer), but I've got the impression that it's going to be what OpenGL and Vulkan were supposed to be but didn't really manage to become: A platform-independent modern graphics API.
Doing raw OpenGL as an indie instead of using an engine these days is unusual and likely to be ill-advised unless a big part of the point of the project is to learn more about low-level graphics programming, in which case you're not so much making games as studying programming through gamedev. It's like writing your own UI framework for your web app instead of using React / Angular / Vue. It's true that there are use cases that existing game engines don't cover perfectly, but the cost/benefit ratio just isn't gonna be there for a custom solution for most projects
They have no OpenGL job reqs. They have tons of Vulkan job reqs that they can't fill.
Vulkan is mostly Android 10+ thing in games development, even on the Switch, there are other APIs to choose from, with Unity having a big piece of the pie, 50% of the titles according to the company numbers on 2020 Unite keynote.
"Reqs" is "requisitions" and not "requirements". Sorry about not clarifying that.