While this shouldn't be a problem with C code, better be safe than
sorry. @DanielGibson stumbled over this while debugging some strange
RB-Doom3 / dhewm3 issues with gcc. See this bug report for details:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
$PROCESSOR_ARCHITECTURE seems to contain the architecture of the host,
but we need the architecture the current MinGW shell is targeting.
$MINGW_CHOST seems to be just that, and on my system it's either
i686-w64-mingw32 (mingw32.exe) or x86_64-w64-mingw32 (mingw64.exe)
(No idea what it looks like for Windows on ARM...)
As fixing this would otherwise break existing savegames, I bumped the
SAVEGAMEVER to "YQ2-4" and added a quirk for older savegameversions:
On Windows i386 savegames that contain "AMD64" instead of "i386" as
architecture are also accepted.
(For YQ2-1 this didn't seem necessary, apparently "i386" was hardcoded)
* No need for global CXXFLAGS. The only difference to CFLAGS is the
standard selector, use $(subst) to derive them from CFLAGS.
* libstd++ must never be manually linked. Doing so only works for the
GNU C++ stack, not for the LLVM stack and anything else. Link with
the C++ frontend instead.
* Force MingW to g++ as CXX.Force MingW to g++ as CXX.
* No need to specify -lm, libm is already part of the global LDFLAGS.
* Windows doesn't need -fPIC.
* The Vulkan renderer doesn't use glad.
This is an enhancement to the previous `yield` work:
* Don't enforce `-march=armv8-a` for aarch64 builds, because it is the
initial ARMv8 revision and compilers will either use that or something
newer.
* Refine preprocessor guards around `asm("yield");` so the code isn't
compiled in if unsupported by the current `-march='.
Submitted by @smcv in #535.
This was requested several times, the last time in pull request #523.
Only the optimization level, warning level and debug stuff may be
overridden. All other options are enforces because they're required.
While here add a new variable to force a debug build: `make DEBUG=1`.
Loading libcurl at runtime instead of linking it at compile time makes
things a lot easier and more reliable on Windows. On other platform
libcurl can be installed as optional dependency instead as an hard one.
This is a very first cut:
* It compiles
* It doesn't crash
What's missing:
* cmake integration
* CURL should be loaded dynamically
* Integration between download code and filesystem
* Likely UTF-8 stuff
* cl_http.c needs cleanup
* Windows support
I've chosen the minimal invasive way for this:
* Import miniz and remove -lz linker flags.
* Create a short header minizconf.h roviding everything we need
originally defined by zconf.h and not provided by miniz.
* Replace zlib.h with miniz.h and minizconf.h.
The input system backend was once used in the client and the renderers,
but for some years now it has been an integral part of the client only.
Move it there.
* CDA was only supported of the client was build with SDL 1.2. Our
Windows binaries had no CDA support for years, I'm pretty sure that
it never worked on Linux and no computer build after 2005 has even
the necessary hardware. So let's just remove it.
* X11GAMMA was a hack to work around SDL 1.2s inability to set the
gamma on newer xorg-server versions. It has been broken for some
time now an is rather ugly. Remove it.
This is the first step in removing SDL 1.2 support.
FreeBSD has supported printing backtraces for years. The API is the same
as on Linux, the only difference is that libexecinfo must be linked as a
seperate library. Since the last FreeBSD version with backtrace support
(FreeBSD 9.3) went out of support some time ago unconditionally enable
the printing.
By default minizip uses fopen64(), fseek64() and so on. Those may not
be defined on all system, especially the BSDs. While FreeBSD already
has a special case, for example OpenBSD hasn't. Work around this by
forcing minizip to use fopen(), fseek() and so on everything that's not
Linux or Windows. This is not 100% correct, it may prevent the usage of
ZIPs lager than 2GB on Solaris and other rarely used systems. But I
doubt that anyone has such large ZIPs with assets, they would likely hit
other internal limits.
In the future Quake II should use off_t instead of int were applicable.
With that we could set -D_FILE_OFFSET_BITS=64.
This change is based upon a patch send by @devnexen in pr #279.
There's no need to duplicate machine independent parts of the client
initialization and the main loop for every platform.
While at it remove the nearly empty unix.h header and move Windows
main() into an own file. Not both platform have the same basic layout.
While building the wrapper as a console application is completely fine
there're some advantages by creating a "real" Windows GUI Application:
* Console applications always spawn an annoying console window.
* Windows GUI applications seem to have a much lower chance to trigger
my new best friend, the Windows Defender. As a console application
quake.exe triggered every time I started it, as Windows GUI
application not only once.
Use WinMain() instead of wWinMain() because MinGW doesn't know about
the later and it doesn't matter anyways.
libSDLmain.a has to be linked and must run anyways. So there's no need
for us to reinvent the wheel, just rely on SDLs process setup, argument
parsing, message handling and so on. As a nice side effect this may fix
some strange bugs related to message handling and argument parsing...
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.
Can now build a 32bit version.
Note that all your dependencies will also need to support 32-bit.
Install SDL2, libel, libvorbis, openal-soft in Homebrew using
‘--universal’ flag
No changes to source were needed, just to makefile.
The build process is now also different.
Frameworks are no longer needed, but you will need to get some packages
from Homebrew to compile.
Install homebrew, then get the following packages before compiling.
openal-soft
libogg
libvorbis
sdl2
No, this is not a rage quit but the result of a long discussion. There
are several reasons for us to drop OS X support:
- OS X support was always more or less hacky. For example is was never
really integrated into the build system and some features like the
OpenAL sound backend never worked well.
- The OS X support never grew into the new world based upon SDL2.
- It was broken since at least Lion which was released 4 years ago.
- None of the developers has a Mac or plans to buy one. Supporting
a software for a platform not used by the developers is more or
less impossible.
- And despite several appeals no one from the OS X community ever
stept up and send patches.
Removed are:
- Makefile support
- The OpenAL quirks
- The Cocoa bindings
- The framworks
Not removed is:
- Savegame support
- Memory management support
- Platform detection
- OpenGL and SDL includes
So, if someone steps up and does a modern, fully integrated port based
upon SDL2 we're happy to merge it back. The requirements are:
- It must be a clean port, without any hacks
- Full build system integration must be provided
- The port must be maintained even after it was merged. At every release
binaries must be build, API / ABI changes with new OS X versions must
be tracked.
Retexturing support is now always on (you can still switch it off with
the gl_retexturing CVAR), as we don't have the additional libjpeg
dependency anymore.
stb_image is used for tga, jpg and the newly supported png, so the
old tga and jpeg loading code has been removed.
I furthermore cleaned up the somehow messy and possibly slightly broken
retexturing selection code in R_FindImage()
Ability to read an optional configuration file
which is read if exists, we can even decide
which configuration file (default is config.mk) to use at
the command line like this:
$ make # it will read config.mk if exists
$ make CONFIG_FILE=my-badass-conf.mk
$ make CONFIG_FILE=no-retexturing.mk
As always, build variables still can be set as well by command line.
$ make WITH_SYSTEMWIDE=/media/cdrom/quake2-data CONFIG_FILE=my-badass-conf.mk
The old Window build was tightly bound to Nuwens MinGW distro. Since
Nuwen decided to take the 64 bit way and dropped 32 bit support, we'll
change over to a more generic MinGW build. Use this chance to clean up
things.
PLEASE NOTE: There's no such thing as a "standard MinGW install".
Therefor our buildsystem cann not and will not be generic. It's still
desinged along the pathes of our build environment. We'll upload it
to the projects FTP server.
Things do consider:
- Dependencies (jpeg, libogg, libvorbis, OpenAL, SDL2, zlib) should be
installed under /custom/.
- We're now relying on sdl2-config, to be found at /custom/bin. It's
just a simple shell script, depending on your compiler unsupported
CFLAGS or LDFLAGS must be removed from it.
- Windows binaries are now stripped. There's no need to supply debug
symbols on Windows. This reduces quake.exe from ~8.3MB to ~1.6MB.
- The Binaries are still hard linked.
This automagically sets an rpath to WITH_SYSTEMDIR/lib, when
WITH_SYSTEMWIDE is specified. If no WITH_SYSTEMDIR is given,
the default path /usr/share/games/quake2/lib is used. As for
the normal rpath, for now only FreeBSD and Linux are supported.
This was requested by caedes.
This should ease the overwriting of systemwide installed libs with
specialized versions. Also distributors may use this facility to supply
libraries next to the binaries. Maybe the same should be added for the
other platforms, but I'm not sure if and how they support RPATHes.
SDL2 can and should be statically linked. This is much more easier than
linking it dynamically and more comfortable for the user. One libs less
to care about.
The quake2 binary now gets -DSDL2 in the CFLAGS, so Win32/OSX can
use different #include paths accordingly.
This is also (ab)used to print which SDL version is used on startup.
Don't use this for anything else, use
#if SDL_VERSION_ATLEAST(2, 0, 0)
instead.
I haven't tested building on/for Win32 or OSX, there may be more
work to do.
Furthermore I added Copyright-Info about CalculateGammaRamp()
in refresh.c (it's from SDL2)
* Fix input issues (mouse-wheel and mouse input)
* SDL2 is not default anymore in the Makefile (use WITH_SDL2=yes)
* If SDL2 is enabled, CD audio is disabled (SDL2 doesn't support
that - use OGG/Vorbis instead)
* Small fix to make it compile with SDL1.2 again
Makefile is adjusted, it compiles and works mostly, but
* For some reason (bug in SDL_GetRelativeMouseState() ?)
mouse input doesn't work properly.. it seems to be bound
to window borders, even if input is grabbed
* some keys can't be used anymore because there's no SDLK_*
for them anymore (gotta find out if this is important)
* Maybe some of the changes need cleanup
With this change the "refresh" make target doesn't any longer exists.
It was merged into the "client" target. One will need a "make clean"
before building yQ2 after this change.
This is a manual merge of Hecatomb Q2 ref b8952d5. Manual since git
couldn't do an automerge for some reasons... Notable changes are:
- QGL function pointers are removed, libGL is linked directly
- The OpenGL log framework is removed. It was disfunctional
- The gl_driver cvar is finaly gone
This change is currently untested on Windows and OS. There should
be no problems but a better Makefile integration of libGL is needed.
