Moved all the code using Altivec intrinsics to separate files. This
means we can optionally use GCC's -maltivec on just these files, which
are chosen at runtime if the CPU supports Altivec, and compile the rest
without it, making a single binary that has Altivec optimizations but
can still work on G3.
Unlike SSE and similar extensions on x86, there does not seem to be
a way to enable conditional, targeted use of Altivec based on runtime
detection (which is what ioquake3 wants to do) without also giving the
compiler permission to use Altivec in code generation; so to not crash
on CPUs that do not implement Altivec, we'll have to turn it off
altogether, except in translation units that are only entered when
runtime Altivec detection is successful.
This has been tested on Linux PPC (on an Altivec-enabled CPU),
but we may need further work after testing trickles out to other
PowerPC devices and ancient Mac OS X builds.
I did a little work on this patch, but the majority of the effort belongs
to Simon McVittie (thanks!).
code/libs/macosx/libSDL2-2.0.0.dylib has 2.0.8 for x86 and x86_64 and
2.0.1 for PPC. Add 2.0.1 headers for PPC with modifed SDL_platform.h to
allow compiling using macOS 10.5 SDK. Using separate headers allows the
engine to check the SDL version for enabling newer SDL features.
It seems to improve framerate and still work on x86 and x86_64. I
haven't tested ppc64 as I don't have the hardware. ppc64 isn't built
into the universal bundle either.
I noticed this because compiling opus warns it may be slow due to
optimization being disabled.
OpenBSD's sed (and possibly other platforms') interprets `\r` as a
literal `r` rather than a carriage return, which leads to all `r`
letters being stripped from the shaders' source.
This fixes the issue by using the POSIX-compliant `tr -d '\r'` to remove
carriage returns.
Thanks to @ryan-sg for reporting the issue
A race condition can happen when running "make all" with parallel jobs.
The issue is that the build directory can be created by another
concurrent job between the moment it was detected as missing and the
moment mkdir is called (which fails if the directory already exists).
This fixes the problem by always using `mkdir -p` which doesn't fail if
the directory already exists.
SDL_CFLAGS and SDL_LIBS assignment was "only if absent". However due
to previously assigning them to "pkg-config sdl2" values, the values
from sdl2-config were ignored.
Get all OpenGL functions using SDL_GL_GetProcAddress(). This makes it
easier to cross-arch compile on Linux and add support for OpenGL ES
in the future.
Users still have to supply their own libSDL2 for cross-arch compiling
on Linux. But now the user does not have to re-install libgl1-mesa-dev
package for i386 or amd64 on Debian when switching between compiling
ioquake3 for x86 and x86_64.
Fix for ioq3 test builds for Windows x86 (cross-compiled from Ubuntu
using mingw-w64) requiring libgcc_s_sjlj-1.dll. I'm unable to reproduce
the issue using mingw-w64 in Debian or Cygwin.
- Use common controls 6 so error dialogs use correct visuals on
Windows XP or later!
- Specify running as invoker so Windows doesn't guess if it should
prompt for admin permission on Vista or later.
- Specify compatible with Vista through Windows 10. Tells Windows
not to emulate Vista behavior, not sure if it affects anything.
Makefile automatically runs windres when manifest changes.
Lots of Linux distros have different names (libcurl-gnutls.so vs etc), and
version the symbols (curl_global_init@@CURL_LIBSSL_3), so it's more compatible
to just dlsym the basic entry points we need and just demand that libcurl is
installed at all.
Alternately: we'll use our own libcurl build, but we'll probably have to dump
SSL support to make this sane to do.
Need to be able to specify minimum Mac OS X version outside of the
Makefile to avoid conflicting CFLAGS.
Moved -mmacosx-version-min LDFLAGS into the Makefile.
Moved -arch x86_64 from OPTIMIZEVM to CFLAGS to fix linker errors
(previously make-macosx-ub.sh passed it to CFLAGS manually).
