It makes little sense to centralise the definitions for things like
Steam, GoG, etc.. These paths are only useful in the case where the user
has derived the data from such a store, has installed ioq3 in a separate
location, and we want it do be able to find said data. If a derivative
project has deployed (binaries and all) on e.g. Steam then for them
fs_basepath will already be correct, and fs_steampath is not useful.
Instead of defining NO_VM_COMPILED on the unlimited number of CPU
architectures where we don't have a JIT for QVM bytecode, define
HAVE_VM_COMPILED on the finite number of architectures where we do
(x86, PowerPC, Sparc or 32-bit ARM).
Signed-off-by: Simon McVittie <smcv@debian.org>
We need specific code for any architecture that does have a JIT, so we
can safely assume that any other architecture does not.
Signed-off-by: Simon McVittie <smcv@debian.org>
This was the last remaining GNU assembler code that was in its own
independent source file, as opposed to being embedded in C code with
GNU `__asm__ volatile` or MSVC `__asm` (which tends to be much easier
to deal with in a modern build system).
When the Quake 3 engine was originally written, this might have been
an "expensive" function when written in portable C, but after 25 years
of CPU development it's less likely to matter (and modern compilers
might produce faster results from the C code anyway).
Resolves: https://github.com/ioquake/ioq3/issues/778
Signed-off-by: Simon McVittie <smcv@debian.org>
Before commit a7d33b1c "(bug #3639) BoxOnPlaneSide rewrite" there
was more code here, but since then the only thing left is the
Invert24To16 function, to which I couldn't find any references since
the beginning of ioquake3's git history.
Resolves: https://github.com/ioquake/ioq3/issues/774
Signed-off-by: Simon McVittie <smcv@debian.org>
Sys_BinaryPathRelative takes a parameter which is path concatenated with
Sys_BinaryPath, and resolved to a canonical path. The intended use case
is to facilitate the situation where you want the game data directory to
exist outside the same directory in which the binary lives, but relative
to it. More specifically, if you want to distriute multiple binaries for
different architectures, in the same tree, this allows for a means of
having said binaries in architecture subdirectories, with a shared data
directory, e.g.:
ioq3/x86/ioquake3.exe etc.
ioq3/x86_64/ioquake3.exe etc.
ioq3/baseq3/pak0.pk3 etc.
Here, when building you would define DEFAULT_RELATIVE_BASEDIR=".." by
appending it to the build system CFLAGS, and then the executables will
by default look in their parent directory for the data.
This is `#if 0` anyway, and has been since the initial Quake 3 Arena GPL
release, so clearly it hasn't been used for some time.
Signed-off-by: Simon McVittie <smcv@debian.org>
I'm aware this probably breaks the MSVC build, but
a) I think it's probably broken already
b) I have good reasons that will hopefully make this a non-issue anyway
FARPROC is defined with an empty parameter list, which newer versions of GCC consider equivalent to (void). Compilation fails when qSHGetFolderPath gets called with arguments.
The VAO surface cache uses glBufferSubData and triggers a very slow
path in some GLES implementations. Specifically I have observed 10x
frame times under Emscripten with ANGLE/Metal on macOS and with Mali
on Android.
Co-authored-by: Zack Middleton <zack@cloemail.com>
Co-authored-by: WofWca <wofwca@protonmail.com>
