This work was submitted by Dmitry Antipov. We stick to macros instead of
inline functions since they're in line with the rest of the code base.
This patch removes several unused functions and tranfers most of the
rest into macros.
As suggested by Daniel, use the same hack as dhewm3: The user defines a
path prefix and CMake does the rest. So this is enough to build on
Windows: cmake -G Unix\ Makefiles -DYQUAKE2LIBS=C:/MinGW/32/LIBS ..
This is a working CMake based build system for Windows:
- While this should work with system wide installed libraries, it's
still highly recommended to use the latest version of our official
Windows build environment.
- It was tested with out official build environment on Windows 7 with
32 bit and 64 bit builds
- You'll need something in the lines of this nice and short command:
cmake -G Unix\ Makefiles \
-DSDL2_LIBRARY=C:/MinGW/32/LIBS/lib/libSDL2.dll.a \
-DSDL2_INCLUDE_DIR=C:/MinGW/32/LIBS/include \
-DZLIB_INCLUDE_DIR=C:/MinGW/32/LIBS/include \
-DZLIB_LIBRARY=C:/MinGW/32/LIBS/lib/libz.a \
-DOGG_LIBRARY=C:/MinGW/32/LIBS/lib/libogg.dll.a \
-DOGG_INCLUDE_DIR=C:/MinGW/32/LIBS/include \
-DVORBIS_LIBRARY=C:/MinGW/32/LIBS/lib/libvorbis.dll.a \
-DVORBIS_INCLUDE_DIR=C:/MinGW/32/LIBS/include \
-DVORBISFILE_LIBRARY=C:/MinGW/32/LIBS/lib/libvorbisfile.dll.a \
-DVORBISENC_LIBRARY=C:/libvorbisenc.dll.a \
-DOPENAL_LIBRARY=C:/MinGW/32/LIBS/lib/libOpenAL32.dll.a \
-DOPENAL_INCLUDE_DIR=C:/MinGW/32/LIBS/include ..
Yes, forward slashes! Backslashes will break!
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.
As Jack Whitham noticed [0], animated textures freeze at their first
frame if they're on a transparent surface. This can be seen in base3
(Com Centre), for example. At least for the OpenGL renderer this is
caused by the fact that the animation chain is never forwarded if the
texture is bound to a transparent surface. The fix is to do exactly
that...
I can only speculate why the animations on transparent surfaces were
never used / implemented. Maybe performance issues or it was just
forgotten.
0: http://blog.jwhitham.org/2015/04/more-fun-with-floating-point-numbers.html
sounds easy, right?
Except some genius decided to save CVAR_LATCH cvars in buffers of
MAX_OSPATH length into savegames.. so just changing MAX_OSPATH
breaks savegame compatibility.
Fortunately, this assumption only matters in SV_WriteServerFile() and
SV_ReadServerFile() so I worked around it by introducing a
platform-specific LATCH_CVAR_SAVELENGTH (because MAX_OSPATH was 256 on
Windows but 128 on other systems..)
