Hacker News new | past | comments | ask | show | jobs | submit login

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.



Vulkan is really hard and is not really a "true" replacement for OpenGL. It's too low level, and not a good API for people making "games" to interact with. Sure, big engines and AAA games are definitely going to be implementing it, but it will always be alongside D3D and Metal.

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.



> Vulkan is way too much for most indies

I would not say that at all. The biggest disadvantage of Vulkan is that it doesn't support old GPUs


WebGPU is a much more manageable API, if you are looking to be cross-platform but want to write your own graphics code.

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’m working with OpenGL in an indie game across Windows/Mac/Linux.

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)


> especially on really old hardware

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.


You just have to look at Android, where Google had to make compulsory on Android 10 as no one was caring, and still it looks like this after 2 OS releases:

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 have a problem with Vulkan on linux. Vulkan wont work on Intel drivers if the display is using 10 bit colour.

For some reason, OpenGL still works, and very well, including doing gradients in 10bit colour space.


With some libs and tutorials, setting up a modern OpenGL pipeline has become reasonably easy, and extensions give you access to some state of the art features, sometimes even before DirectX (64bit atomics just made it into DirectX in december, but I've already used them in OpenGL 2018). I don't feel like switching to Vulkan, mainly because of all the reviews of others who said that it's incredibly cumbersome to use and after looking at certain aspects of Vulkan, I can see why. I don't really want to take the effort of diving into another badly designed graphics API at that point.

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.


OpenGL is like learning to ride a bike. Vulkan is like flying a fighter jet. Lots more work and not much benefit if you're just trying to go a mile or two.


I do some projects that require WebGL and a good understanding of OpenGL makes life so much easier. WebGL from what I understand is based on OpenGL ES 2.0, and knowing how to write custom vertex and fragment shaders is important for my work


Most DIYs and commercial indies (and companies like Blizzard, Capcom, Namco, Square Enix, Rare, etc... for that matter) are using third party engines that handle the rendering for them. OpenGL will continue to be relevant as long as it's the API of choice for at least some subset of use cases in those engines. I would be very surprised to see any game company that uses cutting edge graphics to sell its games or the hardware they run on (Rockstar, Guerilla, etc) use it for a new project

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


OpenGL is still the only library natively available everywhere (at least in some capacity). Vulkan can't run on low-end mobile hardware nor on macOS.


MoltenVK allows you to run Vulkan on Metal (MacOS).


Vulkan is low level, so I think it will be mostly used with intermediate libraries, that ease its usage.


If you watch any of the video game developers conferences they are (or, were, before Covid) in unanimous agreement:

They have no OpenGL job reqs. They have tons of Vulkan job reqs that they can't fill.


Because everyone is busy targeting DirectX 11/12, NVN, Metal and LibGNMX.

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.


Job reqs? Are you saying lots of people are looking for vulkan jobs and they can't be hired because there's no need, or lots of open positions requiring vulkan skills?


I read it clearly as the latter; "open reqs" as in "open positions" they (the hiring companies) can't fill.


Lots of positions requiring Vulkan skills and no positions looking for OpenGL ones.

"Reqs" is "requisitions" and not "requirements". Sorry about not clarifying that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: