Remove attachment 18_vertex_input

attachments/CMakeLists.txt

@@ -213,20 +213,16 @@ add_chapter (16_frames_in_flight
 add_chapter (17_swap_chain_recreation
   SHADER 09_shader_base)
 
-add_chapter (18_vertex_input
-  SHADER 18_shader_vertexbuffer
-  LIBS glm::glm)
-
 add_chapter (19_vertex_buffer
-  SHADER 18_shader_vertexbuffer
+  SHADER 19_shader_vertexbuffer
   LIBS glm::glm)
 
 add_chapter (20_staging_buffer
-  SHADER 18_shader_vertexbuffer
+  SHADER 19_shader_vertexbuffer
   LIBS glm::glm)
 
 add_chapter (21_index_buffer
-  SHADER 18_shader_vertexbuffer
+  SHADER 19_shader_vertexbuffer
   LIBS glm::glm)
 
 add_chapter (22_descriptor_layout

en/04_Vertex_buffers/00_Vertex_input_description.adoc

@@ -58,7 +58,8 @@ Create a new structure called `Vertex` with the two attributes that we're going
 
 [,c++]
 ----
-struct Vertex {
+struct Vertex
+{
     glm::vec2 pos;
     glm::vec3 color;
 };
@@ -84,7 +85,7 @@ This is known as _interleaving_ vertex attributes.
 The next step is to tell Vulkan how to pass this data format to the vertex shader once it's been uploaded into GPU memory.
 There are two types of structures needed to convey this information.
 
-The first structure is `VkVertexInputBindingDescription` and we'll add a member function to the `Vertex` struct to populate it with the right data.
+The first structure is `vk::VertexInputBindingDescription` and we'll add a member function to the `Vertex` struct to populate it with the right data.
 
 [,c++]
 ----
@@ -105,14 +106,14 @@ All of our per-vertex data is packed together in one array, so we're only going
 The `binding` parameter specifies the index of the binding in the array of bindings.
 The `stride` parameter specifies the number of bytes from one entry to the next, and the `inputRate` parameter can have one of the following values:
 
-* `VK_VERTEX_INPUT_RATE_VERTEX`: Move to the next data entry after each vertex
-* `VK_VERTEX_INPUT_RATE_INSTANCE`: Move to the next data entry after each instance
+* `vk::VertexInputRate::eVertex`  : Move to the next data entry after each vertex
+* `vk::VertexInputRate::eInstance`: Move to the next data entry after each instance
 
 We're not going to use instanced rendering, so we'll stick to per-vertex data.
 
 == Attribute descriptions
 
-The second structure that describes how to handle vertex input is `VkVertexInputAttributeDescription`.
+The second structure that describes how to handle vertex input is `vk::VertexInputAttributeDescription`.
 We're going to add another helper function to `Vertex` to fill in these structs.
 
 [,c++]
@@ -141,22 +142,20 @@ The `format` parameter describes the type of data for the attribute.
 A bit confusingly, the formats are specified using the same enumeration as color formats.
 The following shader types and formats are commonly used together:
 
-* `float`: `VK_FORMAT_R32_SFLOAT`
-* `float2`: `VK_FORMAT_R32G32_SFLOAT`
-* `float3`: `VK_FORMAT_R32G32B32_SFLOAT`
-* `float4`: `VK_FORMAT_R32G32B32A32_SFLOAT`
+* `float` : `vk::Format::eR32Sfloat`
+* `float2`: `vk::Format::eR32G32Sfloat`
+* `float3`: `vk::Format::eR32G32B32Sfloat`
+* `float4`: `vk::Format::eR32G32B32A32Sfloat`
 
 As you can see, you should use the format where the amount of color channels matches the number of components in the shader data type.
 It is allowed to use more channels than the number of components in the shader, but they will be silently discarded.
 If the number of channels is lower than the number of components, then the BGA components will use default values of `(0, 0, 1)`.
-The color type (`SFLOAT`, `UINT`, `SINT`) and bit width should also match the type of the shader input.
+The color type (`Sfloat`, `Uint`, `Sint`) and bit width should also match the type of the shader input.
 See the following examples:
 
-* `int2`: `VK_FORMAT_R32G32_SINT`, a 2-component vector of 32-bit signed
-integers
-* `uint4`: `VK_FORMAT_R32G32B32A32_UINT`, a 4-component vector of 32-bit
-unsigned integers
-* `double`: `VK_FORMAT_R64_SFLOAT`, a double-precision (64-bit) float
+* `int2`  : `vk::Format::eR32G32Sint`, a 2-component vector of 32-bit signed integers
+* `uint4` : `vk::Format::eR32G32B32A32Uint`, a 4-component vector of 32-bit unsigned integers
+* `double`: `vk::Format::eR64Sfloat`, a double-precision (64-bit) float
 
 The `format` parameter implicitly defines the byte size of attribute data and the `offset` parameter has specified the number of bytes since the start of the per-vertex data to read from.
 The binding is loading one `Vertex` at a time and the position attribute (`pos`) is at an offset of `0` bytes from the beginning of this struct.
@@ -171,17 +170,18 @@ Find the `vertexInputInfo` struct and modify it to reference the two description
 
 [,c++]
 ----
-auto bindingDescription = Vertex::getBindingDescription();
-auto attributeDescriptions = Vertex::getAttributeDescriptions();
-vk::PipelineVertexInputStateCreateInfo vertexInputInfo {  .vertexBindingDescriptionCount =1, .pVertexBindingDescriptions = &bindingDescription,
-    .vertexAttributeDescriptionCount = attributeDescriptions.size(), .pVertexAttributeDescriptions = attributeDescriptions.data() };
+auto                                   bindingDescription    = Vertex::getBindingDescription();
+auto                                   attributeDescriptions = Vertex::getAttributeDescriptions();
+vk::PipelineVertexInputStateCreateInfo vertexInputInfo{ .vertexBindingDescriptionCount   = 1,
+                                                        .pVertexBindingDescriptions      = &bindingDescription,
+                                                        .vertexAttributeDescriptionCount = static_cast<uint32_t>( attributeDescriptions.size() ),
+                                                        .pVertexAttributeDescriptions    = attributeDescriptions.data() };
 ----
 
 The pipeline is now ready to accept vertex data in the format of the `vertices` container and pass it on to our vertex shader.
-If you run the program now with validation layers enabled, you'll see that it complains that there is no vertex buffer bound to the binding.
 The xref:./01_Vertex_buffer_creation.adoc[next step] is to create a vertex buffer and move the vertex data to it so the GPU is able to access it.
 
-link:/attachments/18_vertex_input.cpp[C{pp} code] /
-link:/attachments/18_shader_vertexbuffer.slang[slang shader] /
-link:/attachments/18_shader_vertexbuffer.vert[GLSL Vertex shader] /
-link:/attachments/18_shader_vertexbuffer.frag[GLSL Fragment shader]
+link:/attachments/19_vertex_buffer.cpp[C{pp} code] /
+link:/attachments/19_shader_vertexbuffer.slang[slang shader] /
+link:/attachments/19_shader_vertexbuffer.vert[GLSL Vertex shader] /
+link:/attachments/19_shader_vertexbuffer.frag[GLSL Fragment shader]

en/04_Vertex_buffers/01_Vertex_buffer_creation.adoc

@@ -262,6 +262,6 @@ image::/images/triangle_white.png[]
 In the xref:./02_Staging_buffer.adoc[next chapter,] we'll look at a different way to copy vertex data to a vertex buffer that results in better performance, but takes some more work.
 
 link:/attachments/19_vertex_buffer.cpp[C{pp} code] /
-link:/attachments/18_shader_vertexbuffer.slang[slang shader] /
-link:/attachments/18_shader_vertexbuffer.vert[GLSL Vertex shader] /
-link:/attachments/18_shader_vertexbuffer.frag[GLSL Fragment shader]
+link:/attachments/19_shader_vertexbuffer.slang[slang shader] /
+link:/attachments/19_shader_vertexbuffer.vert[GLSL Vertex shader] /
+link:/attachments/19_shader_vertexbuffer.frag[GLSL Fragment shader]

en/04_Vertex_buffers/02_Staging_buffer.adoc

@@ -206,6 +206,6 @@ However, for this tutorial, it's okay to use a separate allocation for every res
 In the xref:./03_Index_buffer.adoc[next chapter,] we'll learn about index buffers for vertex reuse.
 
 link:/attachments/20_staging_buffer.cpp[C{pp} code] /
-link:/attachments/18_shader_vertexbuffer.slang[slang shader] /
-link:/attachments/18_shader_vertexbuffer.vert[GLSL Vertex shader] /
-link:/attachments/18_shader_vertexbuffer.frag[GLSL Fragment shader]
+link:/attachments/19_shader_vertexbuffer.slang[slang shader] /
+link:/attachments/19_shader_vertexbuffer.vert[GLSL Vertex shader] /
+link:/attachments/19_shader_vertexbuffer.frag[GLSL Fragment shader]

en/04_Vertex_buffers/03_Index_buffer.adoc

@@ -141,6 +141,6 @@ This is known as _aliasing_ and some Vulkan functions have explicit flags to spe
 The xref:05_Uniform_buffers/00_Descriptor_set_layout_and_buffer.adoc[next chapter] we'll learn how to pass frequently changing parameters to the GPU.
 
 link:/attachments/21_index_buffer.cpp[C{pp} code] /
-link:/attachments/18_shader_vertexbuffer.slang[slang shader] /
-link:/attachments/18_shader_vertexbuffer.vert[GLSL Vertex shader] /
-link:/attachments/18_shader_vertexbuffer.frag[GLSL Fragment shader]
+link:/attachments/19_shader_vertexbuffer.slang[slang shader] /
+link:/attachments/19_shader_vertexbuffer.vert[GLSL Vertex shader] /
+link:/attachments/19_shader_vertexbuffer.frag[GLSL Fragment shader]