Some GPU drivers set a maximal extent size of 0x0 when the window gets
minimized. One example is Intel on Windows. A swapchain with extent
size of 0x0 is invalid, so we cannot reinitialize the renderer... Work
around that by postponing the restart as long as the maxmimal extent
size stays 0x0.
This could should be done in the client (don't call into th renderer
when the window is minimized), but it would need a lot of changes
to the client <-> renderer interactions. So take the easy route.
The client might call into the renderer after it was shut down by
`VID_ShutdownRenderer()` or initialized `VID_LoadRenderer()`. This
is arguably a client bug, but hard to fix on client side and not
a problem for all other renderers. Work around it by marking the
current frame as 'not started' at Vulkan shutdown and init.
This is more in line with the rest of the code. Reinitializing the
internal state when building a new context is saver than relying on
Vulkan telling us that something is wrong an reacting to that.
Just calling `QVk_Shutdown()` is wrong. It doesn't wait for Vulkan to
finish, which can cause crashes. And it leaks some ressources which
makes the GPU driver unhappy.
The ref_vk renderer was written for vkQ2 which has differend renderer
<-> client semantics. In YQ2 we can end up initializing or shutting the
renderer down several times. Not by the client, but by the client not
knowing of the renderer has already initialized / shutdown it's internal
state. This is fatal, leading to ressource leaks, crashes and other fun.
Introduce a new global variable `vk_initialize` and use it to track if
we're initialized or not.
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)
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.
This was the default until 2.0.12 and is what the expects. It changed
with 2.0.14, casing problems with window ordering under windows and
some X11 window managers like kwin.
Do it unconditionally. So we're shure that we're ending with a minimized
windows, no matter what SDL does.
Fixes part of #647.
One of the most common bug reports is, that the fullscreen mode doesn't
behave like users expect. This is caused by `vid_fullscreen 1` setting
desktop fullscreen mode (a fullscreen windows) and not the native
fullscreen mode. This commits switches the semantics:
* 1: Native fullscreen, like Vanilla Quake II.
* 2: Desktop fullscreen.
With this alt-tab reverts to native fullscreen. While at it improve the
documentation, suggest setting `r_mode -2` when using `vid_fullscreen
2`. Change the menu strings to make things clearer, set `r_mode -2` when
selecting 'fullscreen window' in the menu.
I pondered several other options:
* Introducing a second cvar for the desktop fullscreen, like we did in
dhewm3. This has the problem, that in Quake II vi_fullscreen is
special and used to communicate changed to the renderer configuration
between the client and renderer. A second fullscreen cvar would
complicate this already shaky mechanism even more.
* Setting `r_mode -2` when `vid_fullscreen 2`. This might not be what
the user wants and causes problems when we're unable to get the
desktop resolution.
Switching this back to Vanilla Q2 behavior fixes at least one lightning
problem in the space map in baseq2. It'll break the lighting in some
addon maps, but is more correct from a global standpoint. You can't
have everything...
Closes#677.
If an error is detected in vkAcquireNextImageKHR or vkQueuePresentKHR,
avoid restarting the whole video system and the game window. Instead,
shut down the Vulkan subsystem as gracefully as possible and restart it
without touching the window.
This fixes the problem with infinite video restarts under the Gnome
desktop environment.
1: The Vanilla Quake II behaviour, footsteps are generated when the
player is faster than 255.
0: Footstep sounds are never generated.
2: Footstep sounds are always generated.
Defaults to `1`, cheat protected to `1`.
Closes#666.
When windowed or in "switch resolution" mode, the viewport must be kept
in the top-left corner or it will appear cut while in fullscreen.
Also, make offset and width calculations safe from the point of view of
the swapchain extent, in case there's a mismatch.
Since we are now loading the world color buffer content before drawing
on them again, we need to make sure the attachment layout transition
from shader-read-optimal to color-attachment-optimal happens before
color attachment read operations.
