Since `vid_fullscreen` isn't special anymore, it's completely handled by
`Vid_Restart_f()`, which in turn simplifies the spaghetti code in the vk
renderer. If I understand that glibberish correctly the only we need to
handle is the partial restart in `QVk_Restart()`.
This function will be used to replace the vid_fullscreen->modified
mechanism used the communicate renderer configuration restarts to the
client with a proper proper API. The implementation is backward
compatible, existing renderers are still working.
VK_WARNING: Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x58e7d23ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively. (performance)
The commanders body entity is special, because it's spawned in god mode.
That's no problem in the baseq2 and addons campaigns. But it may break
some custom maps and prevents some hacks, one example is putting the
entity inside an killbox.
Submitted by Евгений T.
Knightmare of KMQ2 requested this as an easy way to support client site
prtocol auto detection.
While here fix the protocol version number in the error string.
This brings yquake2 closer to vkQuake2 regarding renderer restarts when
the swapchain is out of date, among other situations that trigger a
Vulkan renderer restart.
Basically, the current behavior has the problem that when the renderer
is restarted at the beginning of the frame, the models are lost and we
end up with "ERROR: Mod_PointInLeaf: bad model" when attempting to
render anything after that restart.
To solve this, we move the restart logic to EndFrame and add a twist to
it: we use a vid_refresh variable to signal the server that the client
needs re-registration before starting the next frame cleanly, which will
trigger the registration logic to prepare the models again.
When creating the Vulkan texture samplers, make them have the real
anisotropic filtering value selected by the user. This has two side
effects:
* We no longer need two sets of texture samplers in Vulkan (one with and
another one without anisotropic filtering).
* The anisotropic filter value in Vulkan is no longer an on/off switch
and we use the value as chosen by the user.
Making the anisotropic filter value only be applied after hitting Apply
in the video menu will make it more natural for the Vulkan renderer to
restart itself when a new anisotropic value is selected, paving the way
to use the actual anisotropic filtering value in Vulkan.
