Wrong fields specified in image layout transition in Chapter06 Texture Mapping.

[Extra-Creativity]

In line 352 of 06_Texture_mapping/00_Images.adoc, it says:

If you are using the barrier to transfer queue family ownership, then oldLayout and newLayout fields should be the indices of the queue families. They must be set to VK_QUEUE_FAMILY_IGNORED if you don't want to do this (not the default value!).

But actually, vk::ImageMemoryBarrier should use fields .srcQueueFamilyIndex and .dstQueueFamilyIndex in this case. And it should be explained why provided code in transitionImageLayout doesn't do so:

Vulkan-Tutorial/attachments/24_texture_image.cpp

Line 521 in fef9813

vk::ImageMemoryBarrier barrier{.oldLayout = oldLayout, .newLayout = newLayout, .image = image, .subresourceRange = {vk::ImageAspectFlagBits::eColor, 0, 1, 0, 1}};

while transition_image_layout (yes, it's a different function, with inconsistent naming convention) does so:

Vulkan-Tutorial/attachments/24_texture_image.cpp

Lines 742 to 772 in fef9813

	void transition_image_layout(
	uint32_t imageIndex,
	vk::ImageLayout old_layout,
	vk::ImageLayout new_layout,
	vk::AccessFlags2 src_access_mask,
	vk::AccessFlags2 dst_access_mask,
	vk::PipelineStageFlags2 src_stage_mask,
	vk::PipelineStageFlags2 dst_stage_mask)
	{
	vk::ImageMemoryBarrier2 barrier = {
	.srcStageMask = src_stage_mask,
	.srcAccessMask = src_access_mask,
	.dstStageMask = dst_stage_mask,
	.dstAccessMask = dst_access_mask,
	.oldLayout = old_layout,
	.newLayout = new_layout,
	.srcQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED,
	.dstQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED,
	.image = swapChainImages[imageIndex],
	.subresourceRange = {
	.aspectMask = vk::ImageAspectFlagBits::eColor,
	.baseMipLevel = 0,
	.levelCount = 1,
	.baseArrayLayer = 0,
	.layerCount = 1}};
	vk::DependencyInfo dependency_info = {
	.dependencyFlags = {},
	.imageMemoryBarrierCount = 1,
	.pImageMemoryBarriers = &barrier};
	commandBuffers[frameIndex].pipelineBarrier2(dependency_info);
	}

This function is used in 03_Drawing_a_triangle. I think a better way is to canonicalize these two functions instead.