Vulkan support?

[wiverson]

Just curious about raylib and Vulcan, and perhaps Metal.

Basically, from a hundred thousand feet, I know that Apple is officially deprecating OpenGL. Other tools (eg Godot) are moving to Vulcan for their next rev.

I'm not advocating for anything, just seeking understand and thoughts. I imagine moving to Vulcan would be an API breaking process, but that's just conjecture on my part.

[raysan5]

I'd like to jump into Vulkan at some point, not for raylib but for personal interest in learning this new API. Vulkan is way more verbose and complex than OpenGL, what can be accomplished in OpenGL in a few hundred lines of code requires a few thousand lines of code in Vulkan.

Also raylib won't benefit much of Vulkan because Vulkan is an API intended to squeeze the maximum power from the GPU, usually intended for GPU-intensive applications, like AAA games. raylib plays in a lower league, actually, it doesn't expose some advance features that came with latest OpenGL versions (4.0 and beyond).

The only interesting point about integrating Vulkan is the rlgl module replacement. Afaik, this module is unique from raylib, it maps several OpenGL versions to a pseudo-OpenGL 1.1 immediate mode drawing, it means, you can code like you coded graphics in 1992 today with raylib thanks to rlgl. If at some point I integrate Vulkan, it would be with a rlvk module doing some mapping to that pseudo-OpenGL 1.1 API. Afaik, nothing similar exist and I doubt anyone decides to follow that crazy route today...

[wiverson]

My sense is that the OpenGL support at the current level is more or less baked into macOS, iOS etc forever, given the huge number of games and apps that use it. Any thoughts on the risk that Apple might drop it to the point that raylib would be in trouble?

[assyrianic]

a good compromise I can think up: Is it possible to mix both OpenGL and Vulkan code? If so, perhaps certain parts that can benefit from Vulkan would be a boon.

[orcmid]

Based on how Vulcan tends to have wrappers that delivers a variety of APIs, including OpenGL versions (and DirectX, etc.), it strikes me that Vulcan is lower-level and it might be interesting to consider it as an OpenGL implementation case. Reaching around OpenGL for Vulcan functions strikes me as a pretty dicey abstraction leak and it would be dangerous for raylib to have functions that did that without having non-Vulcan implementations. From 80,000 feet, this smells like recurrence of the previously-unsolved problem.

PS: If the goal is simply to get around where OpenGL support is disappearing, I think @wiverson 's concern matters. And the Vulcan OpenGL delivery might fit @raysan5 's interest. Avoiding mission creep seems called-for.

[chriscamacho]

I'd suggest considering a rlgl style wrapper to BGFX as this gets you the so called "modern" api's all from one API covering a number of different platforms, that said using its C api can be ... well... interesting (read hard!)

[orcmid]

Hmm. Since BGFX is proposed to provide a wrapper for practically everything, I'm not certain who should do what to whom. The BGFX API warnings about C equivalents and the reliance on C++ namespaces are worrisome. From a distance, this seems to be at cross-purposes with the raylib sweet spot which is already rather platform-neutral in a sort of POSIX/OpenGL/C99 sense.

I'm not certain what problem would be solved, and who's problem it is, let alone who is expected to solve it.

I confess ignorance around how rlgl might be a bridge of the desired nature, unless the idea is to offer rlgl for independent use in places where OpenGL is what someone wants to (inter-)operate with apart from raylib. Is it worthy to make a big stretch beyond being sufficient for raylib and its platform and language orientation? Whose itch is it to do that?

[orcmid]

General PS: It is worthwhile to look at the open Issues and Issues history of appealing projects. Consider how one would work cross-project in such cases.