vulkan.h includes platform specific headers that cause non trivial build
overhead. Because vk-bootstrap doesn't make use of any platform specific
API's, it can move over to vulkan_core.h.
This *MAY* break users of the library who were depending on vulkan/vulkan.h
including other headers, like windows.h. But because the benefits outweigh
the drawbacks, it is a good change.
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.
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.
