Auto-Vk-Toolkit
Auto-Vk-Toolkit copied to clipboard
Getting serious about Vulkan development with this modern C++ framework, battle-tested in rapid prototyping, research, and teaching. Includes support for real-time ray tracing (RTX), serialization, an...
*Problem Description* Traditionally, header files in C++ projects are compiled with every translation unit that includes them. As projects grow, the recompilation of header files adds up and slows down...
Clear values are implemented in an immutable way a.t.m.. Support shall be added to `renderpass_t` to support changing them. Would be very nice if they could be set somehow through...
...because we're going back to being explicit and more true to raw Vulkan. Therefore, remove all of the following: ``` /** General image usage that can be used for transfer...
...because this: ``` mImageUsage = avk::image_usage::color_attachment | avk::image_usage::transfer_destination | avk::image_usage::transfer_source | avk::image_usage::presentable; const vk::ImageUsageFlags swapChainImageUsageVk = vk::ImageUsageFlagBits::eColorAttachment | vk::ImageUsageFlagBits::eTransferDst | vk::ImageUsageFlagBits::eTransferSrc; ``` is not cool. See `window.cpp#L591`!
I just thought it would be nice to have something to begin with: I like the idea of having one standardized way the code should be formatted throughout the project....
At many places within _Auto-Vk_ and _Gears-Vk_, small `std::vector`s are passed around --- meaning that only few elements are contained. A small vector type would probably be very beneficial to...
Currently within Auto-Vk and Gears-Vk, when a function/method supports multiple elements for one particular argument, that argument's type is `std::vector`. That is bad, however, since users are forced to use...