Allows the tests to set the exact values vk-bootstrap will receieve
rather than require a real vulkan driver to be present on the system.
This is done by creating a `vulkan-1.dll` on windows that implements
all of the API functions, and on linux/macOS intercepts `dlsym` to
make it return the mock's functions.
The example triangle now will have a absolute filepath to the shaders.
This allows running the exe from directories other than the location of the shaders in the filesystem.
Alternative solutions would be to copy/paste the shader binary into the source code.
find_package is used to try to find the Vulkan-Headers, and if they aren't
present, it downloads them with fetch content. This way users don't need
vulkan 'installed' on their system, specifically for windows users.
It also changes the tests to load all the necessary function pointers, that
way we don't need to find the vulkan loader to build the tests.
Make vk-bootstrap capable of loading the vulkan runtime and not need to
link against the library. This improves the usability of vk-bootstrap since
now you don't need the vulkan library on your system to build.
This commit also changes how SystemInfo works so as to allow the dynamic
vulkan loading.
To recreate a swapchain now requires making a new SwapchainBuilder or
keeping the old one around. Removed the recreate function since its
purpose was unclear. Introduced set_old_swapchain to allow recyling the
old swapchain. Updated documentation and getting started guide.
Updated the documentation for using the new <error_code> based errors.
Also fixed an issue where SystemInfo wouldn't check if layers had a
debug_utils extension.
Added device::get_queue_families() to facilitate custom queue setups
get_swapchain_images() renamed to get_image(), made member function to
swapchain.
get_swapchain_image_views() renamed to get_image_views(), also moved to
member function of swapchain
fixed bug with headless instance not being correct
Stopped Catch2 from polluting the buildable targets
SystemInfo will be the way for users to know what is and isn't available on their system.
Currently, it only has booleans for if validation layers and debug messenger are available,
but more could be added in the future.
Premise is to let the easy creation of a compute or transfer queue.
If the user supplies a custom list they want to use, defer to that.
Else, enable the basic requirements and be on your merry way.
