vk::Formats in the match arm. Meanwhile, the second usage of the | operator is the bitwise OR operator which combines the bits of the vk::ImageAspectFlags we want to enable in this code path.
+
let aspect_mask = if new_layout == vk::ImageLayout::DEPTH_STENCIL_ATTACHMENT_OPTIMAL {
match format {
vk::Format::D32_SFLOAT_S8_UINT | vk::Format::D24_UNORM_S8_UINT =>
diff --git a/print.html b/print.html
index 3af4626..9a234ea 100644
--- a/print.html
+++ b/print.html
@@ -507,7 +507,7 @@ macOS
Next comes our main function (which returns an anyhow::Result type). This function starts by initializing pretty_env_logger which will print our logs to the console (as shown later).
Then we create an event loop and window to render to using winit using LogicalSize which will scale the window according to the DPI of your display. If you want to know more about UI scaling you can read the relevant winit documentation.
Next we create an instance of our Vulkan app (App) and enter into our rendering loop. This loop will continually render our scene to the window until you request the window to be closed at which point the app will be destroyed and the program will exit. The destroying flag is necessary to not keep attempting to render the scene while the app is being destroyed which would most likely result in the program crashing after attempting to access Vulkan resources that have been destroyed.
-Lastly comes App and AppData. App will be used to implement the setup, rendering, and destruction logic required for the Vulkan program we will be building over the course of the following chapters. AppData will serve simply as a container for the large number of Vulkan resources we will need to create and initialize which will allow for them to be easily passed to functions to be read and/or modified.
+Lastly comes App and AppData. App will be used to implement the setup, rendering, and destruction logic required for the Vulkan program we will be building over the course of the following chapters. AppData will serve simply as a container for the large number of Vulkan resources we will need to create and initialize which will allow for them to be easily passed to functions to be read and/or modified. AppData implements the Default trait so we can easily construct an instance of this struct with empty/default values.
This will come in handy because many of the following chapters consist of adding a function which takes a &mut AppData and creates and initializes Vulkan resources. These functions will then be called from our App::create constructor method to set up our Vulkan app. Then, before our program exits, these Vulkan resources will be released by our App::destroy method.
A Note on Safety
All Vulkan commands, both the raw commands and their command wrappers, are marked unsafe in vulkanalia. This is because most Vulkan commands have restrictions on how they can be called that cannot be enforced by Rust (unless a higher-level interface that hides the Vulkan API is provided like in vulkano).
@@ -795,6 +795,9 @@ Message cal
Finally, the user_callback field specifies the callback function. You can optionally pass a mutable reference to the user_data field which will be passed along to the callback function via the final parameter. You could use this to pass a pointer to the AppData struct, for example.
Lastly we call create_debug_utils_messenger_ext to register our debug callback with the Vulkan instance.
Since our create_instance function takes an AppData reference now, we'll also need to update App and App::create:
+
+Note: AppData::default() will use the implementation of the Default trait generated by the presence of #[derive(Default)] on the AppData struct. This will result in containers like Vec being initialized to empty lists and Vulkan handles like vk::DebugUtilsMessengerEXT being initialized to null handles. If Vulkan handles are not initialized properly before they are used, the validation layers we are enabling in this chapter should let us know exactly what we missed.
+
struct App {
entry: Entry,
instance: Instance,
@@ -5207,6 +5210,9 @@ pattern that matches either of the specified vk::Formats in the match arm. Meanwhile, the second usage of the | operator is the bitwise OR operator which combines the bits of the vk::ImageAspectFlags we want to enable in this code path.
+
let aspect_mask = if new_layout == vk::ImageLayout::DEPTH_STENCIL_ATTACHMENT_OPTIMAL {
match format {
vk::Format::D32_SFLOAT_S8_UINT | vk::Format::D24_UNORM_S8_UINT =>
diff --git a/setup/base_code.html b/setup/base_code.html
index 1f4581f..ce857a8 100644
--- a/setup/base_code.html
+++ b/setup/base_code.html
@@ -207,7 +207,7 @@ Base code
Next comes our main function (which returns an anyhow::Result type). This function starts by initializing pretty_env_logger which will print our logs to the console (as shown later).
Then we create an event loop and window to render to using winit using LogicalSize which will scale the window according to the DPI of your display. If you want to know more about UI scaling you can read the relevant winit documentation.
Next we create an instance of our Vulkan app (App) and enter into our rendering loop. This loop will continually render our scene to the window until you request the window to be closed at which point the app will be destroyed and the program will exit. The destroying flag is necessary to not keep attempting to render the scene while the app is being destroyed which would most likely result in the program crashing after attempting to access Vulkan resources that have been destroyed.
-Lastly comes App and AppData. App will be used to implement the setup, rendering, and destruction logic required for the Vulkan program we will be building over the course of the following chapters. AppData will serve simply as a container for the large number of Vulkan resources we will need to create and initialize which will allow for them to be easily passed to functions to be read and/or modified.
+Lastly comes App and AppData. App will be used to implement the setup, rendering, and destruction logic required for the Vulkan program we will be building over the course of the following chapters. AppData will serve simply as a container for the large number of Vulkan resources we will need to create and initialize which will allow for them to be easily passed to functions to be read and/or modified. AppData implements the Default trait so we can easily construct an instance of this struct with empty/default values.
This will come in handy because many of the following chapters consist of adding a function which takes a &mut AppData and creates and initializes Vulkan resources. These functions will then be called from our App::create constructor method to set up our Vulkan app. Then, before our program exits, these Vulkan resources will be released by our App::destroy method.
A Note on Safety
All Vulkan commands, both the raw commands and their command wrappers, are marked unsafe in vulkanalia. This is because most Vulkan commands have restrictions on how they can be called that cannot be enforced by Rust (unless a higher-level interface that hides the Vulkan API is provided like in vulkano).
diff --git a/setup/validation_layers.html b/setup/validation_layers.html
index 097528c..30170eb 100644
--- a/setup/validation_layers.html
+++ b/setup/validation_layers.html
@@ -300,6 +300,9 @@ Message cal
Finally, the user_callback field specifies the callback function. You can optionally pass a mutable reference to the user_data field which will be passed along to the callback function via the final parameter. You could use this to pass a pointer to the AppData struct, for example.
Lastly we call create_debug_utils_messenger_ext to register our debug callback with the Vulkan instance.
Since our create_instance function takes an AppData reference now, we'll also need to update App and App::create:
+
+Note: AppData::default() will use the implementation of the Default trait generated by the presence of #[derive(Default)] on the AppData struct. This will result in containers like Vec being initialized to empty lists and Vulkan handles like vk::DebugUtilsMessengerEXT being initialized to null handles. If Vulkan handles are not initialized properly before they are used, the validation layers we are enabling in this chapter should let us know exactly what we missed.
+
struct App {
entry: Entry,
instance: Instance,