As verbose as Vulkan may be, it's a well-designed vanilla C API. Some of the future helper libraries may also be in vanilla C, in which case it's not difficult to version and ensure relative stability.
I hope this is a easy to use high level library that wraps Vulkan apis. That would help solve one big complaint that Vulkan is too low level for normal programmers.
I really like how vulkan tries to model modern hardware--reminiscent of C. I spent a few weekends writing a toy renderer with it and learned quite a bit about the modern graphics pipeline.
Writing vulkan for a quick hobby project is probably a bit much, but it seemed like a great choice where extra control is needed. Hopefully more libraries will mature take care of the dirty work (thousands of lines of initialization).
Whoa now that is cool! Are there any games out there that currently use this C++ API of Vulkan? Very curious to know if there are any major issues with using it versus the direct C API.
I'm not very knowledge regarding Vulkan so hopefully that isn't a stupid question but I want to brush up on my C++ skills and play with this!
Also how similar is Vulkan to SDL? I used to use SDL quite a bit back in the day and it was awesome but I'm assuming Vulkan is far more comprehensive?
Vulkan is a breath of fresh air compared to OpenGL. The documentation is great, it runs everywhere, and if it passes validation I get consistent results on whatever hardware I want to run it on.
I'm not sure why I would want to target 4+ proprietary API's instead of one modern, open API which is well-designed and performs great.
yep... I was just dunking a hobnob while writing some good old imperative C. Did anybody notice that Vulkan, "the future" of graphics APIs, doesn't f*ck around with OO or Functional?
Can someone knowledgeable tell me if Vulkan is a good API? I've heard that OpenGL is a bit of a mess (maybe DirectX is too?), did they get it right this time?
Console APIs are nice and clean compared to Vulkan though, since they are tailored to the underlying hardware. Vulkan is a weird compromise between a low-level API and covering fairly different GPU architectures.
Vulkan was always designed to be extremely low level API and with an idea in mind, that libraries would be required to get it up to level of OpenGL/DX11 and others. So in this respect, extensively using libraries on top of it is very normal, just like you don't write your software against syscalls these days.
All the current major game engines are C++. C hasn't been widely used since the Quake 3 days.
While yes the Vulkan & OpenGL APIs are pure C, that's very, very little of what you actually code against. You very quickly abstract that or use a middleware like bgfx or whatever. In the case of Vulkan while the spec API is C, there's first-class C++ wrappers/bindings provided as well: https://github.com/KhronosGroup/Vulkan-Hpp
And other than Vulkan & OpenGL, you'll find that most other APIs/libraries in the space are C++, not C. Valve's libraries are C++. Dear ImGui is C++. Bullet & PhysX are C++. Microsoft's glTF SDK is C++. etc...
You can argue endlessly about how "true C++" those all are or if they're just "C with namespaces" but that's largely irrelevant - they aren't C and they need a C++ compiler.
I had a really good time writing a Vulkan renderer for a project I did. There's _A LOT_ of boilerplate, but there are helpful error messages every step of the way and the API makes sense because everything is explicit, unlike OGL.
reply