Before we can ship the softrenderer in the default install we'll need to
clean up the cvars. Currently the softrenderer is using the gl_* cvars
which is confusing.
Commit 883781c selected these paths for all OSs, but when linking to
a system copy of OpenAL for Linux distribution binaries we want the
normal OpenAL in /usr.
Signed-off-by: Simon McVittie <smcv@debian.org>
Highlights are:
- Since MSYS2 is much more unixlike than our old build environment we
can remove most Windows specific hacks from the Makefile.
- MSYS2 has an package manager, the build environment can be updated
by "pacman -Syu" just like an ordenary Arch Linux installation.
- Parallel builds are now working.
- git is integrated into the build envirment.
- zlib is now linked as a dynamic lib.
After this commit the old bild environment will no longer work! The
latest version must be downloaded and extracted to C:\MSYS2. Get it
here: https://deponie.yamagi.org/quake2/windows/build/
still no 3D rendering, but in theory it should be able to load models,
bsps etc, just not render them yet.
also moved/copied md2.c and sp2.c to gl/ and gl3/ because they use
renderer-specific types
the arguments were not used anyway, and returning true/false is clearer
than returning -1 (for error) or sth else (which has no deeper meaning
anyway).
Also:
* PrepareForWindow() can now return -1 if there's an error
* suppress some warnings in Makefile
* fix error for building ref_gl.dylib on OSX
the problem is that sdl2-config --libs apparently includes shit that's only
useful for the executable, but not dlls, like linking against SDL2main and
libmingw32 and setting -mwindows
Furthermore I forgot to add -lopengl32 and -shared to the ref_gl Windows
LDFLAGS.
If someone really want's overwrite OSTYPE on Windows it's much easier to
just alter one line in the Makefile than supporting setting it through
the command line.
The old implementation had two problems:
* OSTYPE and ARCH are systemwide defines, overriding them may break
the global libc headers. This is a theoretical problem, I've never
seen it in praxis.
* Not all system set ARCH correctly when building in a chroot env.
For example on Linux ARCH is set to x86_64 when building in an
i386 chroot. Now the user can do something like "make YQ2ARCH=i386"
to get things right.
In Linux distributions, having the executable depend on the right
libraries and arrange for them to be installed is straightforward,
and there's a lot of infrastructure for tracking which library
version a particular executable needs, including making sure we have
a version that contains all of the symbols that were used. Loading
libopenal at runtime defeats that infrastructure.
The ability to substitute a different-but-compatible libopenal,
or operate with reduced functionality without libopenal, might
still be desirable for generic/portable binary releases.
The CMake build system already linked the executable to
${OPENAL_LIBRARY} anyway, so it is already a hard dependency in that
build system.
For deterministic/reproducible builds (where the same source and
toolchain can be verified to produce the same binary, allowing
maliciously substituted binaries to be detected) it is desirable to
take the software's idea of the build date from the build system;
otherwise, the real-time clock at the time of building affects the
result, making it non-reproducible.
SOURCE_DATE_EPOCH is a distribution-neutral specification for how
to do that. It is meant to be set by meta-build systems such as
dpkg or RPM, using a date/time that is already part of the source code,
for example the date of the latest git commit, the date in
the package's debian/changelog, or the date in the RPM spec file.
See https://reproducible-builds.org/specs/source-date-epoch/ for the
specification of SOURCE_DATE_EPOCH, or https://reproducible-builds.org/
for more information on reproducible builds in general.
The old whitelist was a leftover from the early days of YQ2. It should
run on most / all architectures, as long SDL supports them. As suggested
by smcv in issue #138 generate the OSTYPE and ARCH defines by the build
system instead of hardcoding it.
Savegame compatibility is provided by bumping the savegame version. Old
savegames are compared against the old OSTYPE and ARCH defined, new ones
against the new defines. This compatibility code should be removed
somewhere in the distant future.
This should have been done years ago, .dynlib is the canocial extension
for libraries on OS X. In a broader sense this simplifies the CMake
build system a little bit, since CMake enforces .dynlib for OS X
libraries.
See https://github.com/yquake2/yquake2/issues/71
and https://github.com/yquake2/xatrix/issues/4
In ClientThink(), the float value ent->velocity[i]*8 is saved into
a short and if the value is too big for a short, in 32bit gcc builds
the short is set to SHRT_MIN, resulting in the player being pressed
down instead of up.
Now we put the result in a 32bit int first (which should be big enough)
and assign the int to the short. This still overflows, but with -fwrapv
at least in a defined way (most probably the same way the original
binaries did).
And while I was at it, when the game lib is loaded, it prints the date
it was built, this is especially interesting for our Win32 binaries.
