Sometimes when resizing the window we may get the following validation
error:
ERROR: VALIDATION - Message Id Number: -370888023 | Message Id Name:
VUID-vkAcquireNextImageKHR-semaphore-01286
Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01286 ]
Object 0: handle = 0xdcc8fd0000000012, type = VK_OBJECT_TYPE_SEMAPHORE;
| MessageID = 0xe9e4b2a9 | vkAcquireNextImageKHR: Semaphore must not be
currently signaled or in a wait state. The Vulkan spec states: If
semaphore is not VK_NULL_HANDLE it must be unsignaled
(https://vulkan.lunarg.com/doc/view/1.2.198.1/linux/1.2-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01286)
In VulkanContext::prepare_buffers the problem was that
vkAcquireNextImageKHR returned VK_SUBOPTIMAL_KHR but it already signaled
the semaphore (because it is possible to continue normally with a
VK_SUBOPTIMAL_KHR result).
Then we recreate the swapchain and reuse the
w->image_acquired_semaphores[frame_index] which is in an inconsistent
state.
Fixed by recreating the semamphores along the swapchain.
Fix#80570
There was an error in the other branch of the refactored function where the size of the array was not properly multiplied by the size of the float to check against the buffer size. This was only an error in the error-checking itself and not the functionality. There was also an error where the proper notification was not emitted whenever the buffer for the multimesh is recreated to invalidate the previous references the renderer might've created to it. This fixes CPU Particles getting corrupted when they're created without emission being enabled.
Even if you specify the subsystem to be the console one, the vsproj doesn't carry over the setting, which makes working with this mode in the IDE a bit annoying since it'll regenerate the vsproj right afterwards. Since there's only two options and 'gui' is the default, we only carry over the 'console' setting.
Direct buffer copies are required to perform certain operations more efficiently, as the only current alternative is to download the buffer to the CPU and upload it again. As the first use case, the new function is used when enabling motion vectors on multimeshes.
Integer scaling is achieved (after aspect expansion) by "lying" to the
stretching code about the window's size, telling it that it's always an
integer multiple of the viewport so that it only gets stretched to an
integer factor.
This approach works with all stretch and aspect modes and doesn't
require handling for each, only requiring to "loosen up" some
self-excluding conditions (in other words, replacing some `else if`s
with just `if`s) regarding viewport offset and margin calculation (black
bars).
Includes a tiny usability change that adds a range hint for the content
scale factor between 0.5 to 8.0.
Co-Authored-By: Hugo Locurcio <hugo.locurcio@hugo.pro>