-
Notifications
You must be signed in to change notification settings - Fork 0
Design
Future versions will contain ease of use implementation for testing / bootstrapping a working implementation of a Vulkan instance. Because of this, there will be optional includes down the line containing static and dynamic allocation specifications so that these objects do not have to be defined by the user.
Eventually if I hold interest in maintaining the library in the following years, I will update the design to make use for C++ 20.
This library is not designed for use in old compilers. I have no desire to add or hold back the implementation design of the library to those standards. I will add a section to the conventions for how to to make / manage a different C++ standard (such as 03, 11, 14, etc) if anyone would like to do so (currently not done).
There will be a macro option to use a longer namespace: VaultedVulkan.
The vaults define explicit implementation contexts that each have their own level of abstraction in wrapping away from the traditional Vulkan-C-API.
These serve to make it easier for users to distinguish and make use of only the implementation they desire from the library in a clean and easy to manage way.
By default only vaults 1-3 are defined. To have vault 4 available the VT_Open_Vault_4 macro must be defined before including the library in a desired header. VT_V4_Setup_Implementation must also be defined in a cpp file with the library included once again for V4 to compile.
Vault_0 is not designed to be used directly as its intended for use as a backed implementation for the other vaults. This includes platform detection, and helper templates/structure definitions that help define the proper implementation with less redundancies.
(See wiki pages related to vaults 1-4 for their information).
The organization and order of both the files and the wrapped structures may not follow according to the Vulkan-API specification.
The specification has major sections and subsections for how it organizes the information related to functionality and the objects used within the API. However due to these sections cross referencing definitions, and there being an implicit but clear hierarchy of object dependency, the library will organize Vulkan-API structures in nested definitions based on the interpreted hierarchy and in contexts that they may not have been originally specified in. If its been found that an interpretation goes against the actual use of Vulkan's design of the implementation / structure definitions, they will be refactored to correct the mistake.
There is no exposed Vulkan C-API functionality intended to be used by the user of this library, with the library. All the macros, enumerations, structures, functions, type definitions, etc that are used, have been wrapped. This is done with the implementation of the Vault_01 namespace. Which is then built upon in the rest of the vaults for the rest of the implementation.
The reason for doing so is to provide a all encompassing replacement interface to the traditional Vulkan C or C++ API, with minimal to hopefully no cost (there is no such thing as zero-cost abstraction).
This is done without worry as if any correlation with the original API is desired, simply looking for the wrapped definition in the library will have a direct link to the original specification definition the wrapped version represents.