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..)
it's saved in $HOME/.yq2/$mod/history.txt
While I was at it, I made the max number of lines in the history
configurable at compiletime by introducing a NUM_KEY_LINES #define
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.
* remove link to our debian packages, we don't do that anymore
-> mention debian/ubuntu packages instead
* remove references to libjpeg, we don't use that anymore
* Link to retex pack was broken, replace with our mirror, mention that
the ones in models.zip suck
* Fix some typos
Daniel is more or less sure that a stuck Alt key can occure if the user
switches through several windows by Alt-Tab. That sounds resonable,
because the keyup event for Alt may happen when the focus is not on
Quake II. In that case SDL2 misses it and for Quake II the key stays
down. Solve this by capturing the focus loss event and mark all keys
as up.
