-
Notifications
You must be signed in to change notification settings - Fork 1
Not‐so‐frequently Asked Questions
Welcome!
Here is a bit more information about this project – some intentionally-informal thoughts, justifications, ramblings.
I searched, and what I saw was disappointing. Setting up Vulkan is big and complicated. I thought it should be simpler and clearer, with details "tucked away" and better high-level organization to start, with order-of-initialization made obvious and dependencies visibly exposed... if not compiler-enforced.
I also wanted to include the same functionality as the excellent Vulkan Tutorial (from which I took much direction myself), but with the code itself in a friendlier, more accessible form.
I endeavored to use modern language standards, encapsulate smaller reusable classes, and avoid any mega morass of monolithic C.
High-level Goals: (project/design-level)
- avoid monolithic thousand-line C files.
- instead, use OOD to encapsulate Vulkan setup phases into classes.
- incorporate RAII to expose dependencies and isolate/automate object destruction.
- strive for SOLID, use interfaces, keep components modular, reusable, and extendable.
- make using/initializing Vulkan easier, more understandable, and less intimidating for graphics beginners.
Fine-grained Goals: (code-level)
- use modern C/C++ syntax (and modern compiler: Clang).
- use "designated initializers" – Vulkan requires ubiquitous pre-initialized data structures, so streamline them (designated initializers have existed for years in Clang/GCC for C++ and since C99).
- balance self-documenting code with a "the less code, the better" approach.
- minimize code appearing on visible page (without crowding).
- of course, comment high-level concepts.
Visual Studio 2019 is required by HelloVulkanSDL, which is replete with modern C/C++ syntax. Unfortunately though, it means that this project will not build on older VS versions, which only support older C++ standards.
One example is our use of "designated initializers" to pare-down code appearing for Vulkan setup, which requires pre-initialized data structures practically everywhere. Another example appears in the next section.
Also, standardizing on Clang/LLVM allows us to truly share code cross-platform – including Linux, Mac/iOS, and Android – without myriad sloppy platform-specific #ifdefs.
I applaud Microsoft for modernizing their C/C++ support and incorporating the Clang compiler!
Per "less code == better," I use VLAs. Some devs find this controversial, because those arrays are runtime-allocated on the stack, which could potentially maybe overflow. C generally supported them (GCC, C99) but C++ has persistently resisted (like a steel boot to prevent foot-shooting) and that's understandable. This project isn't really meant for C/C++ beginners though. If that's you, please ignore my usage and avoid VLAs yourself.
I delve further into VLAs and their location in this project in a separate wiki page on VLAs.
Clang supports VLAs for compatibility, so I accept them. Their stack allocations are fast & cheap. I can avoid the overhead of std::vector (its mutability unnecessary) and the extra source code it requires. VLAs streamline a pattern you continually see in Vulkan, namely:
uint32_t numResources = 0;
vkEnumerateResource(&numResources, nullptr);
VkResource resources[numResources]; // <-- this is a variable-length array declaration
vkEnumerateResource(&numResources, resources);
When I have done this, I carefully considered the size of the Vk data structures received from Vulkan, and I'm confident that that risk to the stack is low. Under no circumstances should a large dataset (like graphics data) foreseeably be received when requesting Vulkan to populate data structures in this way.
Foremost, I don't care what anyone does with this code, or even that my name stays on it. This project is derivative itself – although not necessarily directly – but doesn't really do anything unique. Hence the Unlicense, which I posit more as a proclamation than a protection.
If per your "jursidiction" or "legal department" that's an issue, I'm sorry. Either: 1) don't use this code; or 2) feel free to globally delete my name (heck, even replace with yours) and claim this code as your own, or let that be assumed. Again, I just don't care; this code isn't that important. I'm averse to risk-paranoia and pedantic arguments (like this, respect to Andrew Gallant for his candor & patience).
Finally, while I appreciate the Unlicense, I do find its following verbiage a bit melodramatic:
...and to the detriment of our heirs and successors.
Any "heirs and successors" will be just fine, and in the spirit of sharing, may in fact benefit from a less antagonistic, but more open, "considerate of others" world.
This page is still a "work in progress," so more is probably to come.