Never use "game" as library name, use the game name instead. This
allows d3xp/mods to coexist in a single (installation-)directory.
This paves the way for future `make install` or binary installers.
Additionally, the "mods" menu entry works from within the game gui.
Split fs_savepath for config files. This is in preparation for
moving the writable paths on *nix to $XDG_DATA_HOME and
$XDG_CONFIG_HOME.
Affected files: config.spec, *.cfg, doomkey, xpkey.
Includes savegames, configs, screenshots and so on.
And "My Documents" is actually CSIDL_PERSONAL, see
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx
This somehow matches the behaviour on Linux and OSX where this stuff is
saved in some kind of home-dir (e.g. ~/.doom3)
Taken (with kind permission) from Yamagi Quake II's Sys_GetHomeDir()
The correct type for %d, %i, %u, ... is int, not long.
Even if FS_WriteFloatString() didn't care about that, sprintf() (which is called
with the same format strings and the corresponding values) does.
Apart from some minor stuff, this changes the signature of some methods
of Parser and Token classes and of the (unused) Random2 class.
That no problem though, because the calling code uses normal ints
anyway.
(Except for handling of longs in TypeInfo and win32-only Maya import stuff).
sizeof(long) == sizeof(int) on x86 and win64,
but not on 64bit (x86_64) linux/unix/osx/.. so they should be avoided.
Monsters got stuck in same places of d3xp because PVS calculations
returned that they were not in the players PVS.
This only happened on LP64 systems like Unix/Linux amd64 where
sizeof(long) == 8 - it did not happen on Win64 because it's LLP64, i.e.
sizeof(long) == 4 (like on x86 32bit).
Bit fiddling code in Pvs.cpp seemed to assume that sizeof(long) == 4
like on win32.
Fixes#7.
The original implementation was pretty broken (but not used anyway),
it is now fixed and improved a bit (got rid of one inner loop).
This (at least part of the problem) was detected by PVS-Studio,
see http://www.viva64.com/en/b/0120/ Fragment 3
This happens before the SDL GL window is set up, which just
results in a warning. Another call will properly set the
gamma table after the window is initialized.
Make gammaTable a stack variable. This is sufficient, since SDL
already restores the gamma values for us on exit.
