both if GL pointparameters are used or not
(though depending on driver and hardware the pointparameters-based
particles *might* be always square or always round, regardless of
gl1_particle_square - that's driver-bugs which we can't fix, disable
pointparameters with `gl1_pointparameters 0` to work around it, or
just use the GL3 renderer)
r_lerp_list is to allow exceptions to r_2D_unfiltered (like for having
pixely UI in general, but filtered console background).
r_videos_unfiltered controls whether videos should be filtered or not
I also made r_nolerp_list CVAR_ARCHIVE, like users probably expect it.
because on MSVC it uses alloca() (or _malloca()) which mustn't be called
in loops, as the memory is only freed when returning from the function,
not when leaving the scope (or before the next loop iteration).
Instead do one "dry-run" iteration to figure out how big the array must
be at most, and then allocate it once before the loop with that size.
The easiest way to build this is to check out the dhewm3-libs project
(https://github.com/dhewm/dhewm3-libs/) to provide the dependencies
(SDL2, OpenAL, cURL) and set YQUAKE2LIBS accordingly, by passing
-DYQUAKE2LIBS=c:/path/to/dhewm3-libs/i686-w64-mingw32 to cmake.
I wouldn't really recommend building with MSVC - I just somehow made it
work and ignored all the warnings and I have no idea how portable the
resulting binaries are etc. For binaries you actually want to use, please
continue using MinGW-w64. Especially my workaround for VLAs (C99 variable
length arrays) is kinda fishy, particularly if those arrays are allocated
in a loop (that's inly done in ref_gl1.dll's code).
The only reason I did this is that I had to debug on Windows and, at least
for my specific bug, gdb didn't really work with binaries produced by
MingGW-w64 and MSVC's debugger works well with binaries produced by MSVC.
Currently requires VS 2019 16.8 or newer with C11 (/std:c11) because I
couldn't get YQ2_ALIGNAS_TYPE() to work with MSVC without _Alignas().
If we can get this to work, VS2015 or newer might suffice (but not older
versions, because their so called C standardlib didn't provide exotic
functions like snprintf()).
# Conflicts:
# CMakeLists.txt
The problem in door_go_up() may prevent doors from crushing something
blocking them. The problem in G_UseTargets() may prevent targets from
getting killed or fired.
Pointed out by @maraakate.
The ThrowHead() and ThrowClientHead() functions are special. They
transform the entity given in `self` (mostly the caller itself) into a
ripped off head. They don't reset the entities clip mask, which may
cause problems in interactions with other entities. Fix that by reseting
the clip mask to `0`. `0` should be save, because that's the default and
and least SV_TestEntityPosition() handles `0` clip masks.
Suggested by @BjossiAlfreds.
If `ent->dmg` is `0` it's set to `2`:
```
if (!ent->dmg)
{
ent->dmg = 2;
}
```
This enforces func_rotate dealing at least `2` damage points per tick.
Vanilla Quake II had this code a few lines below:
```
if (ent->dmg)
{
ent->blocked = rotating_blocked;
}
```
The if clause is always true. PVS studio complained about that. By
mistake the whole block was removed, essentially preveting func_rotate
from freeing itself when blocked. This broke at least the 'Emulsifying
Flesh Press' in the fact2.bsp.
Closes#786.
* `coop` and `deathmatch` were marked as CVAR_LATCH, `singleplayer` was
not. Fix that by adding the flag to `singleplayer`.
* `coop` and `deathmatch` were marked CVAR_SERVERINFO in the server
intitialization code. Mark both of them and `singleplayer` with
CVAR_SERVERINFO as soon as we're initializing them the first time.
Pointed out by @BjossiAlfreds.
Restored original gamemode prioritization to dm > coop > sp, fixed a bug where server start menu did not clear singleplayer cvar, and rewrote how server init manages gamemode cvars
There're some maps and maybe models or even mods in the wild which have
hardcoded paths with self references (`/./`) and / or empty diretories
(`//`). These assets works when read from the filesystem, but not when
read from PAK or ZIP files. Work around that by removing self references
and empty directories from the path right before opening the file.
Closes#767.
The code is building fine but at startup the rendere library cannot by
loaded: "LoadLibrary returned 126" Disable thread local as a band-aid
fix, it might be worth to have a deeper look and figure out what exactly
goes wrong.
Closes#762.
Since `self->helth` is set after calling `master_start()`
`self->max_health is always 0. Found by @drakonorodny and
analyzed by @BjossiAlfreds. Closes#761.
This is a corner case, next to unlikely that anyone would have ever hit
it. That's why my tests with asan didn't find the leak. The if case are
paletted textures which must be enabled by setting `gl1_palettedtexture`
to 1 and requires an GPU with support for `GL_EXT_paletted_texture`.
Nvidia dropped support for that in 2005. Additionally a sky texture
must be uploaded.
This brings several small bugfixes and more robust handling of files
without comment / tag header. It's not mentioned in the changelog,
but at least for dhewm3 updating to this latest version fixed some
problems with missdecoded files on MacOS when running on the M1 aarch64
CPUs.
This was an issue an Windows with it's small stack. It didn't trigger on
Linux. While at it make the code a little bit more robust by allocating
exactly the amount of data we need and not some arbitrary guess.
Setting r_2D_unfiltered to 1 (0 is default), 2D elements (GUI, menu,
console) are rendered without texture filtering in GL1 and GL3, while
everything else is still rendered with whatever is set in gl_texturemode
This setting (and now also gl_nolerp_list) is applied immediately,
so no vid_restart is needed.
refs #752
like ./quake2 +map sgc9-1
the problem was that everything from '-' to the next '+' (which starts
a command) was skipped; the intention of that (original Quake2) code
probably was to allow skipping something like "-datadir bla", though
Quake2 never supported arguments starting with '-' (until *we* added
-datadir and -portable); maybe that's a leftover from Quake1.
Anyway, the more correct way (that allows '-' in filenames) is to check
for a space before '-': so `quake2 +map base1 -portable` still works,
and now `quake2 +map sgc9-1` works as well
Make Qcommon_Frame and Qcommon_Mainloop static and minimize calls
for get current time, it takes 7% in some profiling cases.
We get current time twice before Qcommon_Frame(as Sys_Microseconds)
and inside it(as Sys_Milliseconds), and we can do it once.
Older ARM ABIs like Debian armel (ARMv5 EABI softfloat) don't use
or require a hardware FPU, so they can't execute the fmrx and fmxr
instructions. Only do this in hardfloat configurations that guarantee
VFP instructions are available.
The client might not be practically usable on ARM softfloat (although
nobody has reported that it isn't...) but the dedicated server is probably
fine, and ceasing to be able to build either would be a regression.
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
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.
- 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.
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.
