Adjusted doc wording for pTypeExternalMemoryHandleTypes

docs/html/other_api_interop.html

@@ -145,7 +145,7 @@ <h2 class="doxsection"><a class="anchor" id="other_api_interop_exporting_prepara
 <div class="ttc" id="astruct_vma_pool_create_info_html_ab6f2e52c47bfe1f4b44920b8bfc27b41"><div class="ttname"><a href="struct_vma_pool_create_info.html#ab6f2e52c47bfe1f4b44920b8bfc27b41">VmaPoolCreateInfo::pMemoryAllocateNext</a></div><div class="ttdeci">void *VkMemoryAllocateInfo pMemoryAllocateNext</div><div class="ttdoc">Additional pNext chain to be attached to VkMemoryAllocateInfo used for every allocation made by this ...</div><div class="ttdef"><b>Definition</b> vk_mem_alloc.h:1397</div></div>
 <div class="ttc" id="astruct_vma_pool_html"><div class="ttname"><a href="struct_vma_pool.html">VmaPool</a></div><div class="ttdoc">Represents custom memory pool.</div></div>
 </div><!-- fragment --><p>Note that the structure passed as <a class="el" href="struct_vma_pool_create_info.html#ab6f2e52c47bfe1f4b44920b8bfc27b41" title="Additional pNext chain to be attached to VkMemoryAllocateInfo used for every allocation made by this ...">VmaPoolCreateInfo::pMemoryAllocateNext</a> must remain alive and unchanged for the whole lifetime of the custom pool, because it will be used when the pool allocates a new device memory block. No copy is made internally. This is why variable <span class="tt">exportMemAllocInfo</span> is defined as static.</p>
-<p>If you want to export all memory allocated by VMA from certain memory types, also dedicated allocations or other allocations made from default pools, an alternative solution is to fill in <a class="el" href="struct_vma_allocator_create_info.html#ae8f0db05e5cb4c43d7713bf4a49a736b" title="Either null or a pointer to an array of external memory handle types for each Vulkan memory type.">VmaAllocatorCreateInfo::pTypeExternalMemoryHandleTypes</a>. It should point to an array with <span class="tt">VkExternalMemoryHandleTypeFlagsKHR</span> to be automatically passed by the library through <span class="tt">VkExportMemoryAllocateInfoKHR</span> on each allocation made from a specific memory type. You should not mix these two methods in a way that allows to apply both to the same memory type. Otherwise, <span class="tt">VkExportMemoryAllocateInfoKHR</span> structure would be attached twice to the <span class="tt">pNext</span> chain of <span class="tt">VkMemoryAllocateInfo</span>.</p>
+<p>If you want to export all memory allocated by VMA from certain memory types, including dedicated allocations and allocations made from default pools, an alternative solution is to fill in <a class="el" href="struct_vma_allocator_create_info.html#ae8f0db05e5cb4c43d7713bf4a49a736b" title="Either null or a pointer to an array of external memory handle types for each Vulkan memory type.">VmaAllocatorCreateInfo::pTypeExternalMemoryHandleTypes</a>. It should point to an array with <span class="tt">VkExternalMemoryHandleTypeFlagsKHR</span> to be automatically passed by the library through <span class="tt">VkExportMemoryAllocateInfoKHR</span> on each allocation made from a specific memory type. You should not mix these two methods in a way that allows to apply both to the same memory type. Otherwise, <span class="tt">VkExportMemoryAllocateInfoKHR</span> structure would be attached twice to the <span class="tt">pNext</span> chain of <span class="tt">VkMemoryAllocateInfo</span>.</p>
 <h2 class="doxsection"><a class="anchor" id="other_api_interop_exporting_memory_allocation"></a>
 Memory allocation</h2>
 <p>Finally, you can create a buffer with an allocation out of the custom pool. The buffer should use same flags as the sample buffer used to find the memory type. It should also specify <span class="tt">VkExternalMemoryBufferCreateInfoKHR</span> in its <span class="tt">pNext</span> chain.</p>