simplified framework options exposed to user and added aggregate-like initialization.

[pocdn]

Exposing to the user the Instance and Device at Framework level caused some examples to stop working.

// Initialize makers
vku::InstanceMaker im{};
im.defaultLayers();
vku::DeviceMaker dm{};
dm.defaultLayers();

The fix is to instead expose Framework high-level options only

// Define framework options
vku::FrameworkOptions fo = {
.useCompute = false;
.useTessellationShader = false;
.useGeometryShader = false;
.useMultiView = false;
};

and not expose "im" and and "dm" to the user directly. The reason is that all the possible options of those two require commensurate code changes beyond just specifying their member variables and more vk::code changes inside vku_framework.hpp.

The newer compilers didn't flag correctly error of using aggregate initilizers when a constructor is user defined. However, the consequence affected the uses of

vku::Window
vk::Viewport
vk::RenderPassBeginInfo
vk::CommandPoolCreateInfo

The fix was to create thin "Maker" wrappers around all these except vku::Window. There wasn't really much benefit for vku::Window. For the other three the code was returned to a more aggregate-like use case with benefit of allowing setting of internal variables in any order unlike actual c++20 aggregate initializers.

prior:

displacementRpbi = vk::RenderPassBeginInfo {
  *displacementRenderPass,
  *displacementFrameBuffer,
  vk::Rect2D{{0, 0}, {window.width(), window.height()}},
  (uint32_t) clearColours.size(),
  clearColours.data()
};

Note, the above can still be used if user likes but now the more aggregate-like use case is also possible (and used in all examples):

displacementRpbi = vku::RenderPassBeginInfoMaker{}
  .renderPass( *displacementRenderPass )
  .framebuffer( *displacementFrameBuffer )
  .renderArea( vk::Rect2D{{0, 0}, {window.width(), window.height()}} )
  .clearValueCount( (uint32_t) clearColours.size() )
  .pClearValues( clearColours.data() )
  .createUnique();

And an example/swirltexture was added.

Two minor changes related to external libraries which give annoying warnings that could be easily fixed.

external/gilgamesh/mesh.hpp ... simply add a missing return statements, added this proposal to original gilgamesh project.

external/glm/detail/type_half.inl ... latest glm actually does this change from "f *= f" to "f = f * f"

[lhog]

Looks cool, but something has happened and lots of files show conflicts.

[pocdn]

My local branch had become out of sync with this master branch. The conflicts should be gone now.

[lhog]

@andy-thomason would you please grant commit rights to @pocdn
Seems like none of us has time to contribute to Vookoo :(

[andy-thomason]

I've added @pocdn as a collablorator. If there is anything else that is required. Please say so. If this was an organisation, I could grant admin rights, but I'm not sure how to do that in a user repo.

We could create an organisation and transfer the repo there if that helps.

[andy-thomason]

I'm overwhelmed that you all have found this useful. The Vulkan API does not make it easy to get started, which was the primary motive for doing this.