We Might Never See A New OpenGL Version, At Least Not For A Long Time

[LinuxID10T]

You are fundamentally wrong, as always.
Game designers don't start from scratch by writing a game engine, they always take something already done now and expands on that, be it a library or a full-blown engine.

SDL2 supports Vulkan for example, most third party game engines support Vulkan or are adding support now.

It will be interesting to see how well these 3rd party game engines will support Vulkan. Without writing for Vulkan (or any other low level API) from the ground up, you lose a lot of the advantages.

[starshipeleven]

It will be interesting to see how well these 3rd party game engines will support Vulkan. Without writing for Vulkan (or any other low level API) from the ground up, you lose a lot of the advantages.

afaik for decent multiplatform game engines (and even good emulators for that matter) the whole rendering backend is a module (as they support OpenGL and Dx already and also may have platform-specific modules for OpenGL), so adding true support for any rendering API is easier than adding true Vulkan support to your average in-house Dx-only engine which is much more integrated.

And you can bet your sorry backside that third party game engines have good incentive to do a good job, as the main reason they get chosen/funded/bought/whatever over others is because they are better or on par with others with $latest_and_most_used APIs.

[DMJC]

I remember writing this very thing on here when Vulcan was coming out, I was slammed by everyone as being full of shit/not knowing etc, and now here we are. It's kind of obvious really, Khronos is an effort to take down Microsoft's monopoly on gaming. Of course they don't want to split resources between their new API and their old one. They put the old one on ice and put everything into the new one. What does this mean for Linux/open source users specifically? It means that we are pretty screwed, under OpenGL strong progress was/is being made on getting up to 4.5 compatibility. There's open source Intel, NVIDIA, AMD drivers which all have OpenGL 4.3 support and rapidly approaching 4.5 support. This doesn't just affect Linux. This means that ReactOS, AROS, any other Open Source Operating system can use the documentation/source to implement a native 3D accelerated graphics driver for reasonably modern hardware. Now that's all being set back by years. If they want to be compatible with the current standard they have to reverse engineer a lot more stuff. Vulcan is years away from a Nouveau release, and I'm yet to see anything suggesting it'll drop on Intel or AMD in the next two years. This essentially turns graphics cards back into black boxes of proprietary code. If you want to run Vulkan in any meaningful way right now, you're running NVIDIA Binary, or AMD Binary drivers.

[s_j_newbury]

I remember writing this very thing on here when Vulcan was coming out, I was slammed by everyone as being full of shit/not knowing etc, and now here we are. It's kind of obvious really, Khronos is an effort to take down Microsoft's monopoly on gaming. Of course they don't want to split resources between their new API and their old one. They put the old one on ice and put everything into the new one. What does this mean for Linux/open source users specifically? It means that we are pretty screwed, under OpenGL strong progress was/is being made on getting up to 4.5 compatibility. There's open source Intel, NVIDIA, AMD drivers which all have OpenGL 4.3 support and rapidly approaching 4.5 support. This doesn't just affect Linux. This means that ReactOS, AROS, any other Open Source Operating system can use the documentation/source to implement a native 3D accelerated graphics driver for reasonably modern hardware. Now that's all being set back by years. If they want to be compatible with the current standard they have to reverse engineer a lot more stuff. Vulcan is years away from a Nouveau release, and I'm yet to see anything suggesting it'll drop on Intel or AMD in the next two years. This essentially turns graphics cards back into black boxes of proprietary code. If you want to run Vulkan in any meaningful way right now, you're running NVIDIA Binary, or AMD Binary drivers.

Where have you been? Intel has a open source Vulkan driver (ANV) which works quite well on gen8 upwards and works somewhat on gen7. Then there's RADV for AMD which is very rapidly getting up to speed, I'd actually be surprised if it doesn't surpass the proprietary driver quite quickly, especially once AMD starts contributing. Nouveau is another matter, unfortunately, they just lack the manpower.

[DMJC]

Got a Vulkan Matrix like Mesamatrix.net to show the current status of Vulkan on different vendors?

[c117152]

Why should there be new OpenGL changes if Vulkan lets you have direct memory control? The moment mobile SoCs came out with Vulkan support, OpenGL went EOL.

In fact, you can safely chop off most of the OpenGL support and leave just the direct memory controls and the ISA and no one will shed a tear.

[smitty3268]

Slapping high level abstractions on top of Vulkan will get you back to OpenGL.

No, it will be something better (and almost certainly higher level) than OpenGL. That's the point - GL is difficult to use, and developers want something better. Vulkan should provide the flexibility to provide that.

Contrary to your belief, ease of use is what makes or breaks a framework. Otherwise the whole world would be programming in C with the occasional ASM routine here and there.

Agreed. Which is why developers use game engines which abstract all the low-level graphics API stuff for them. That's why Unity exists. Meanwhile the small minority of people writing those engines do tend to like using very low-level code, like assembly.

[dungeon]

Really? I find that hard to believe.

It is hard but true, maybe only if you have i7-4790K overclocked and imagine everybody in the world has that too

[stqn]

It is hard but true, maybe only if you have i7-4790K overclocked and imagine everybody in the world has that too

I’m not familiar with Supertux but it seems to me it’s a really simple 2D platformer. If it is CPU-bound, either it’s not using the GPU (using SDL1?), or there is something stupid in the code that could be optimized.
Maybe this: https://github.com/SuperTux/supertux/issues/625
They are drawing each tile one by one.

[stqn]

Oh I can’t edit, but don’t take "stupid" litteraly… I mean something that is well known to be slow. Of course there are always good reasons to write bad code .