At least for LLVM / Clang the -fsanitize= option must be passed to the
linker before any objects or libraries, otherwise the sanitizers will
either noch link or are disfunctional. Split LDFLAGS into LDFLAGS for
flags and LDLIBS for librariers, pass LDFLAGS before any objects and
LDLIBS after all objects. While at it set RTLD_NODELETE so that shared
libs opened by dlopen() are never deleted from memory when building
with sanitizers.
Until 7.45 we supported adding non existent dirs to the search path,
8.00 bails out if it cannot at a dir. It turned out that some users
install the binary through their package management (SYSTEMWIDE is set),
but use local game data. This case was broken, because the SYSTEMDIR
doesn't exist. Fix this by marking the SYSTEMDIR as optional.
Closes#724.
While this shouldn't be a problem with C code, better be safe than
sorry. @DanielGibson stumbled over this while debugging some strange
RB-Doom3 / dhewm3 issues with gcc. See this bug report for details:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
- memcpy() shouldn't be called with NULL, even if length == 0
- In CMod_LoadBrushSides() j (from in->texinfo) could be -1,
which of course is no valid array index
Autosaves are special. The are a byproduct of the level change process.
When loaded they aren't respawning the player at it's last position, the
player is relocated to func_playerstart. Since entities spawn at their
start position, the player may end up in the wrong spot.
One example is train.bsp -> base2.bsp. The platform spawns in upper
position, the player in lower position. The platform comes down and
crushes the player.
Most of these cases work by luck when the client isn't paused during
load, because the world advances a few frames before the player is
spawned. Implement a better fix: Detect if an autosave is loaded (name
is save0 or current) and treat it like a map change, advance the world
by 100 frames. We cant use the `autosave` boolean, because it's in the
game savefile.
Fix suggested by @BjossiAlfreds, closes#711.
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 is next to no functional change, the only difference to before is,
that the Vulkan renderer is treated as an unknown renderer. gl3 is the
first regular fallback.
Unitl now the video menu showed all known renderer libs (gl1, gl3, vk
and soft), regardless if the lib was available or not. Rework the
renderer selection logic to skip over non existent renderer libs:
Generate an array combining the menu string and cvar string of all
available renderer libs, use this array instead of the hardcoded array.
While at it simplify the code a little bit.
So far I haven't seen a restart loop, but at least in theory they'e
possible. Because its hard to break out of such loop, especially on
Windows were interaction with the taskmanager is required, play save
and restart max. 3 times in a row.
The timeout specifies how long Vulkan waits for the next frame becoming
available. On the one hand we need to take the vsync or the possibility
that we get scheduled away for longer times into account. On the other
hand we don't want to wait for too long, the game may run into the
timeout after its windows was minimized, etc. 500 milliseconds sounds
like a good compromise.
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.
Yamagi
Denis Pauk
David Carlier
Daniel Gibson
Spirrwell
BjossiAlfreds