Unify class VulkanSample and HPPVulkanSample.

[asuessenbach]

Description

First step to unifying C- and C++-bindings of vulkan in the framework: Unify the central classes VulkanSample and HPPVulkanSample. Conceptually does the following:

• replaces VulkanSample and HPPVulkanSample by a templated class template <bool CppBindings> VulkanSample.
• internally, that new class uses the C++-bindings.
• controlled by the bool template parameter CppBindings, it provides some interface functions using the C-bindings data types or the C++-bindings data types.
• for now, all the other classes with two flavors (Device and HPPDevice, ...) still exist and their usage in this class' interface are also controlled by the bool template parameter CppBindings.
• to gracefully handle that dichotomy, all members of that class are private now, and some accessor functions are provided.
• especially due to that latest bullet point, literally all samples needed to be touched to use those accessor functions!

Build tested on Win10 with VS2022. Run tested on Win10 with NVidia GPU.

General Checklist:

Please ensure the following points are checked:

• [x] My code follows the coding style
• [x] I have reviewed file licenses
• [x] I have commented any added functions (in line with Doxygen)
• [x] I have commented any code that could be hard to understand
• [x] My changes do not add any new compiler warnings
• [x] My changes do not add any new validation layer errors or warnings
• [x] I have used existing framework/helper functions where possible
• [x] My changes do not add any regressions
• [x] I have tested every sample to ensure everything runs correctly

• [x] This PR describes the scope and expected impact of the changes I am making

  Note: The Samples CI runs a number of checks including:

  • [x] I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
  • [ ] My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

• [x] I have tested the sample on at least one compliant Vulkan implementation
• [x] If the sample is vendor-specific, I have tagged it appropriately
• [x] I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
• [x] Any dependent assets have been merged and published in downstream modules
• [x] For new samples, I have added a paragraph with a summary to the appropriate chapter in the samples readme
• [x] For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
• [x] For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

[asuessenbach]

Somehow other peoples changes has sneaked into this one. Maybe due to some rebasing? And I don't know, how to get them out of the PR again. Can anybody help me with that?

[tomadamatkinson]

Somehow other peoples changes has sneaked into this one. Maybe due to some rebasing? And I don't know, how to get them out of the PR again. Can anybody help me with that?

@asuessenbach as it has been a few days it likely wont be achievable with git reflog. Something you might try is

• Checkout your branch
• Checkout a new branch (temp to test the changes without editing your current work)
• Squash your commits
• Rebase again on main - override any changes present in your branch with those in main

I tend to be able to fix these changes locally if it happens to me but its quite hard to recall the precise steps i normally take. The steps above may not work for you but its something to try at least

[tomadamatkinson]

I will take a more thorough review once the rebase issues are sorted. I reviewed vulkan_sample.h and the sample changes. Unsure which changes have leaked in from other commits.

Im happy with the overall interface. I would have suggested something like get_device and get_c_device to keep things ultra simple, but I didn't realise just how large the VulkanSample interface had grown. Is the idea to slowly phase out the C interfaces using this same technique?

[asuessenbach]

I will take a more thorough review once the rebase issues are sorted. I reviewed vulkan_sample.h and the sample changes. Unsure which changes have leaked in from other commits.

It seems, all the alien changes have gone with my latest force-push. So feel free to review in more depth ;)

[marty-johnson59]

Merging per agreement on the call - now that conflicts are resolved..