Still, nothing will work: no plugins are loaded and they're all broken
anyway.
glx, sgl, glslx etc are going away, just the basics will be built: fbdev
(probably go away eventually), sdl, x11 and hopefully someday win. That's
actually the only reason anything links.
If the client receives a skin updated message from the server before having
loaded the player model (shouldn't happen, but some servers have very
strange programmers), no skin data is avaible for updating, so just bail
out.
Where possible, symbols have been made static, prefixed with glsl_/GLSL_ or
moved into the code shared by all renderers. This will make doing plugins
easier but done now for link testing. The moving was done via the gl
commit.
Where possible, symbols have been made static, prefixed with gl_/GL_ or
moved into the code shared by all renderers. This will make doing plugins
easier but done now for link testing.
QF will now load a single image with (${skyname}_map.*) using blender's
layout. That is, 3x2 with the top row being back, right, front and the
bottom row being bottom, top, left.
Thanks to spirit for pointing that QF wasn't compiling with zlib 1.2.6
(archlinux, not yet in debian).
I was using gzFile as "gzFile *gzfile", but gzFile is already a pointer. In
older versions of zlib (including the 1.2.3 that's in debian), gzFile is
declared as a void *, and it seems that gcc is happy with assigning void **
to void *. However, in recent zlib, gzFile is now struct gzFile_s *, which
gcc is most definitely unhappy about assigning to struct gzFile **.
I just hope that either I had misread the type back when I wrote quakeio,
or that nobody is using such an ancient zlib.
This makes gib depend on gamecode, but removes the dependency on gib from
ruamoko. Unfortunately, carne now needs to be linked against gamecode even
though it never uses it.
Just about to do a release, and I realized windows users wouldn't have any
way of checking out the new renderer. I'll add wglsl when I get a chance to
do some testing.
o All instances of LIBADD/LDADD have a corresponding DEPENDENCIES
specificatiion.
o libraries now use a lib_ldflags macro to keep things consistent
o duplication of source/lib names has been minimized (particularly in
the libraries; more work needs to be done for the executables)
o automake spec blocks have been organized (again, more work needs to be
done for the executables)
The api hides all the gory details of message buffer setup and usage
(particularly the differences between writing and reading). Most
importantly, the api provides a safe way to read and write binary data
(always little endian).
Bill Currie