allow the OpenGL implementation to be overriden through the
OPENGL_DRIVER environment variable. If it is not set, we use the
implementation installed in the profile
/nix/var/nix/profiles/opengl, allowing easy late binding by the
user, e.g.,
$ nix-env -p /nix/var/nix/profiles/opengl -i nvidia-sys-opengl
might install the NVidia OpenGL implementation.
The code that does this is not specific to Quake 3: it has been
factored out into build-support/opengl/mesa-switch.sh. Presumably
any application that requires hardware-accelerated OpenGL needs it.
* Add the Quake 3 demo to the cache.
svn path=/nixpkgs/trunk/; revision=4612
quake3/demo takes care of downloading and patching the required PAK
files. quake3/wrapper calls the Quake binary with a synthesised
directory of symlinks to activated PAK files. This should make it
easy to plug in the commercial PAKs, or third-party mods.
svn path=/nixpkgs/trunk/; revision=4611
to work "out of the box" with hardware acceleration and either the
shareware or full PAK files. But with some hackery, I have gotten
it to work with both Mesa software rendering and NVidia hardware
rendering.
svn path=/nixpkgs/trunk/; revision=4595
* Added NASM, the Netwide Assembler.
* Added Generator, an emulator for Sega Genesis / Mega Drive machines.
Built with XVideo patch. Strangely it crashes with a GDK error when
started in normal mode. However, with the "-a" switch (arcade mode)
it works, and subsequently switching back to windowed mode (Ctrl-F)
also works.
svn path=/nixpkgs/trunk/; revision=1509
An interesting complication is that we have to change the ELF type
of the executable from `Linux' to `SVR4', otherwise the
`ld-linux.so.2' trick to override the glibc used doesn't work
(apparently `Linux' is not a recognised ELF type!).
UT doesn't work with software Mesa, so right now we impurily use
`/usr/lib/libGL.so'. I cannot really test whether it works with
hardware Mesa, since it barfs with an error about missing OpenGL
extensions. But that's probably because I'm testing this on an
iBook over an SSH connection to a Linux machine.
svn path=/nixpkgs/trunk/; revision=1047
to deploy existing binary-only components.
We use the `ld-linux.so.2 PROGRAM' trick to force the use of our own
glibc, and set LD_LIBRARY_PATH to point to the required libraries
(X11, Mesa).
Since Mesa is software-only, Q3A is rather slow. I'll have to
figure out how to use the Mesa from XFree86 (X.Org), since it knows
how to use DRI (or at least speak the GLX protocol). Unfortunately
the xlibs people haven't modularised that part of XFree86 yet.
Also, the flag `+set s_initsound 0' has to be passed to Quake to
disable sound, otherwise it segfaults on startup. It doesn't do
this with the normal glibc, which is strange. Maybe it tries to
dynamically load some sound library or something.
svn path=/nixpkgs/trunk/; revision=1046