There were complains that always generating footsteps is annoying,
because there will be footsteps while swimming or jumping. Refine
the cvar a little bit:
* `0`: No footsteps at all.
* `1`: Vanilla Quake II behavior.
* `2`: Always footsteps as long as the player has a ground entity.
* `3`: Always footsteps.
The changes the meaning of the values, `2` has become `3`.
Closes#738.
For historical reasons numbered paks must be loaded before all other
paks. The logic is easy: Add all numbered paks. Iterate over all
available paks, filter out numbered paks and add everything that's left.
Until now a simple glob comparisson against 'pak*' was used for the
filtering. This has two problems:
1. All paks starting with 'pak*' were filtered, regardless if they're
numbered paks or not.
2. Upper case or mixed case file names that are valid on caseinsenstive
systems like Windows weren't recognized as numbered paks and added
twice. Once as numbered pak and once as other pak.
Refactor the logic to only match paks starting with 'pak%d' and use
strcasecmp() for comparison. Closed#730.
Injecting the demo loop right after the `game` cvar was changed cannot
work: The demo loop is implemented through aliases, aliases are expended
as soon as they're added to the command buffer. However, the game isn't
changed as soon as the cvar is set, but the next time when the control
flow enters the file system. Therefor the aliases get expanded to the
wrong game and the demo loops breaks.
This closes#719.
I added the CMakeLists.txt 6 or 7 years ago so I could load the code
into Jetbrains Clion. I have moved to another editor years ago and the
cmake stuff is effectively unmaintained since then. We kept it around
in case that we'll do a MSVC port, but that's unlikely at this point.
Since bugreport and problems with the CMakeLists.txt keep coming up,
finally retire them. They can be resurrected from the git history if
we'll ever need them again.
Part of #725.
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.
