The game code does not include common.h, so it needs to redo this
part for builds without SOURCE_DATE_EPOCH, where BUILD_DATE will
not have been passed in from the outside.
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
After some long discussions it was realizied that the old README had way
too much informations and was too unspecified on some topics. This new
README was written from scratch and focus on installing Quake II.
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.
Hardware gamma is broken, especially in fullscreen, and a Mac user told me
that setting HW/screen gamma on OSX is a bad idea anyway, because it resets
the monitor calibration.
The game /should/ look ok with vid_gamma 1 (if your display is configured
properly), but if you think it's too dark set it a bit higher and do
vid_restart.
Multitexturing was enabled by default in 0f7b422. It gives a small but
on todays hardware neglectable performance boost, but caused several
problems over the years. For example gl_showtris doesn't work with it
and there's at least one render glitch in city3.bsp.
not sure if this has any drawbacks, seems to work good so far.
No idea why id apparently deactivated this at some point, maybe to
optimize performance?
