While having a Vulkan renderer in Yamagi Quake II sounded like a good
idea, especially for cheap hardware with broken OpenGL drivers, the last
weeks showed that the code is not ready for primetime. Some examples
for critical problems:
* Render glitches when using non-standard assets. Everything with more
polygons and texture resultion than baseq2 seems to be broken.
* The startup and shutdown code is a mess. While I fixes the most
critical bug, there're a lot of cases left. Startup and shutdown
mostly works by luck.
* At least one memory leak in the model code.
And neither @DanielGibson nor myself have deeper knowledge about Vulkan.
We don't have the time and the motivation to learn it. While some
community members did excellent work on ref_vk (especially @0lvin and
@rg3), the community maintenance promised in the initial pull request
never really materialized. Therefor we risk ending up with a renderer
that we can't and won't maintain by ourself.
Vulkan is not gone. The code will be recommitted in a separate
repository at: https://github.com/yquake2/ref_vk
We're willing to give community members commit access to that
repository. Send a substantial pull request and ask for it.
This commit removes the previous R_CleanupBorders hack and fixes
textured border drawing, so borders are correctly drawn in the right
place and are not taken into account when applying the underwater
effect.
This commit includes the following changes:
* When vid_fullscreen is 1, the game is now drawn centered in the
screen instead of the top left corner, by modifying the viewport and
scissor when drawing the world warp and UI render passes.
* When vid_fullscreen is 1, the world view no longer has an incorrect
size and/or aspect ratio. This was due to the world warp and UI
render passes sampling from the whole color buffer instead of the
restricted render area. To fix this, the postprocessing and world warp
shaders now use unnormalized coordinates, corrected with the frame
offset, and sample directly from the appropriate texels.
* The game no longer outputs pixels which have not been written to,
which are usually displayed black but may come out with undefined
colors. For this, some output color attachments are cleared before
drawing the final elements in the frame.
This commit adds a new cvar called vk_pixel_size that represents how big
pixels should look in the rendered world in order to simulate lower
screen resolutions. With its default value of 1 everything looks normal,
but with bigger sizes (e.g. 4) the rendered world starts to look
"pixelated" due to pixels appearing bigger.
To implement the effect, the viewport and scissor are modified when
drawing the world so the rendering results cover a smaller area in the
top-left corner of the image.
The post-processing fragment shader is used to scale the image back to
the swapchain size before drawing UI elements on top of it.
The UI is not affected by this change, so the existing UI scaling
options continue to work as before with no changes, adding some
flexibility to the mix.
Related to feature request #588.
If I understand this right it only builds the dedicated server. I think
that Dockerfiles need to be at the project root. Nevertheless I put it
under stuff/, the root dir is already cluttered enough.
Closes#498.
* Pass the same compiler flags like make.
* Update FindSDL2.
* Remove unneeded FindOggVorbis.
There still some options missing, like the RPATHes or he ability to
define the system wide installation directory.
At high 'fov' values the weapon looked quite distorted.
Now it's rendered with an independent FOV, which looks better.
Note that the 'fov' cvar sets fov_x, while this is based on fov_y
(which is calculated from fov_x), so it's indeed different values:
r_gunfov seems to correspond to fov 90.
We use r_gunfov 80 as default, because it looks better.
if that cvar is set to 1, particles aren't rendered as nice circles, but
as squares, like in the software renderer or in Quake1.
Also documented it in cvarlist.md and fixed some typos there
