The contents of the previous drawn frame, used to mask geometry glitches
due to geometry sometimes not being watertight, was not being correctly
loaded for MSAA cases.
When MSAA is not used, the single-sample attachment needs to be loaded
and stored. With MSAA enabled, it's the multisample attachment the one
needing to be loaded and stored.
The pipeline used to draw a texture quad was only created compatible
with the RP_UI render pass, which has a single-sample color attachment.
This made the pipeline work when MSAA was disabled, but it did not work
properly with it enabled.
To fix the issue, create a set of pipelines, instead of a single one,
with compatibility with the different types of render passes, as the
pipeline is used for both the scaled down view borders as well as UI
elements in the third render pass.
This was added in e3e5bd1 as a work around for some openal-soft bug.
When too many audio samples got played at the same time, the global
volume dropped. This was fixed in openal-soft 0.19.0, released more
than two years ago. We're keeping the work around, because some
distros may still ship with buggy openal-soft versions and some
players may like the changed behavior. It's disabled by default.
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.
When set to `1`, both `deathmatch` and `coop` are forced to `0`.
`maxclients` is forced to `1`. This makes it possible to play single
player campaigns over the dedicated server.
Closes#614.
All renderers had the fix, but it was only optional in the GL renderers.
And there it was missimplemented, cvars must be defined in the renderers
main() function. Otherwise they aren't available at startup.
Rename gl_fixsurfsky to r_fixsurfsky, implement it for all renderers and
enable it by default.
Due to the skybox geometry not always being watertight, it's sometimes
possible to see instances of isolated black pixels flickering along
skybox edges. This happens when the sampling coordinates for the given
pixel fall outside any triangle in the skybox due to the previous
problem.
These pixels are usually visible when MSAA is not used and pixels are
big enough on the screen, like when using lower screen resolutions or
large vk_pixel_size values. If MSAA is used, normally only a few of the
samples fall outside any triangle and the problem is masked a bit, being
harder to spot.
Instead of fixing the skybox clipping routines, which may be
complicated, this commit simply preserves color buffer contents between
frames. If any pixel ends up without coverage, its color will be taken
from a previous draw a few frames before, depending on the swapchain
size. This is usually more than enough to completely mask the problem
visually.
Skybox edges are sometimes visible in Vulkan, specially in lower screen
resolutions or when vk_pixel_size is used to the same effect.
To avoid this problem, draw the skybox using CLAMP_TO_EDGE addressing
mode in samplers. In order to do that, the number of texture samplers is
doubled and a second set of samplers with the new addressing mode are
created, and used only when drawing the skybox.
$PROCESSOR_ARCHITECTURE seems to contain the architecture of the host,
but we need the architecture the current MinGW shell is targeting.
$MINGW_CHOST seems to be just that, and on my system it's either
i686-w64-mingw32 (mingw32.exe) or x86_64-w64-mingw32 (mingw64.exe)
(No idea what it looks like for Windows on ARM...)
As fixing this would otherwise break existing savegames, I bumped the
SAVEGAMEVER to "YQ2-4" and added a quirk for older savegameversions:
On Windows i386 savegames that contain "AMD64" instead of "i386" as
architecture are also accepted.
(For YQ2-1 this didn't seem necessary, apparently "i386" was hardcoded)
In Vanilla Q2 (without any point releases) the hyperblaster projectiles
emitted white light. In the 3.21 sources it's yellow. It likely changed
in on of the (early) point releases. Change it to yellow, the code now
matches 3.21.
Since the first release Yamagi Quake II used the more fanzy R1Q2 colors
for some dynamic lights:
* In R1Q2 the rocket has orange light, matching the color of the fire
trail and the generic explosion. Vanilla Quake II had yellow light,
the same as the blaster and several muzzle flashs.
* In R1Q2 hyperblaster projectiles are emitting yellow light, like the
normal blaster. That matches the projectile colors, the muzzle flash
and the effect when hitting a wall. And it's more logical, since the
hyperblaster is just a blaster on steroids. Vanilla Quake II had white
/ uncolored lights.
Add an option to revert to Vanilla Quake II colors, leave the R1Q2
colors as default. Closes#640.
Since 1a913eb we're calling realpath() on every dir and bail out if the
real path isn't available. If the game is started the first time, the
configuration dir doesn't exist at the first realpath() call and the
game errors out. Always create the configuration dir when determining
it's path.
This didn't happen on Windows because the configuration dir was created
when opening stdout.txt right after we entered main().
TODO: Sys_Mkdir() should grow at leas a little bit error handling. We're
silently ending up in -portable mode if the configuration dir couldn't
created.
When calculating the pipeline scissor adjusted for vk_pixel_size, round
scissor offset down and size up. This avoids black bars on image borders
when scaling up if the division is not exact.
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.
