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.
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.
The variable yquake2RendererLinkerFlags is used to store the linker flags for opengl but the empty variable yquake2OpenGLLinkerFlags is used when linking libraries to the renderer.
Also there's no need to link the opengl libs to the opengl3 renderer when the glad extension loader is being used.
The CMakeLists.txt used the same linker flags for all target, grossly
overlinking q2ded and both render libraries. Fix this by introducing
fine grained variables holding the linker flags.
I hope that I've referenced all headers required by the libraries. If
I missed some compilation will work but IDEs like Clion won't be able
to deduce all symbols.
Before this change cmake overlinked the q2ded binary and the game.so
game library. Now it is also the case with ref_gl1.so and ref_gl3. This
will be fixed in a later commit.
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.
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.
Because setting both a default target directory and a configuration specific target directory wouldn't work as intended with multi-configuration generators.
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!
