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>
