There were lots of places in the code that called Sys_GrabInput(),
some of them each frame.
Most of this is unified in events.cpp now, in handleMouseGrab() which
is called once per frame by Sys_GenerateEvents() - this makes reasoning
about when the mouse is grabbed and when not a lot easier.
Sys_GrabInput(false) still is called in a few places, before operations
that tend to take long (like loading a map or vid_restart), but
(hopefully) not regularly anymore.
The other big change is that the game now uses SDLs absolute mouse mode
for fullscreen menus (except the PDA which is an ugly hack), so the
ingame cursor is at the same position as the system cursor, which
especially helps when debugging with `in_nograb 1` and should also help
if someone wants to integrate an additional GUI toolkit like Dear ImGui.
the script paths were wrong, on Linux they were like
"pak000.pk4/script/doom_util.script" while on Windows it's only
"script/doom_util.script".
Fixed idFileSystemLocal::OSPathToRelativePath() to skip ...pk4/
also fixed GCC compile error in Common.cpp
like the dhewm3 version and the OS and architecture of the dhewm3
version that created the savegame.
Also added an internalSavegameVersion so be independent of BUILD_NUMBER
fixes#344
If REPRODUCIBLE_BUILD is enabled in CMake, the code will not use
__DATE__ or __TIME__ macros, but instead hardcoded values.
Wherever __DATE__ or __TIME__ were previously used, we now use
ID__DATE__ and ID__TIME__, which are either set to hardcoded values or
to __DATE__ and __TIME__ in neo/framework/Licensee.h.
For some reason sounds were only updated/started about every 100ms,
which could lead to delays of up to around 100ms after a sound gets
started (with idSoundEmitterLocal::StartSound()) until OpenAL is finally
told to play the sound.
Also, the actual delay drifted over time between 1ms and 100ms, as the
sound ticks weren't a fixed multiple of the (16ms) gameticks - and the
sound updates didn't even happen at the regular 92-94ms intervals they
should because they run in the async thread which only updates every
16ms...
Because of this, the machine gun and other rapid firing weapons sounded
like they shot in bursts or left out shots occasionally, even though
they don't.
Anyway, now sound is updated every 16ms in the async thread so delays
are <= 16ms and hopefully less noticeable.
You can still get the old behavior with com_asyncSound 2 if you want.
Editor also seems to start, didn't test much further.
Only tested 32bit Windows, I fear the editor code isn't 64bit clean..
I hope I haven't broken anything elsewhere..
Changing idSession would break the interface for Game DLLs, making the
existing ports of Mods incompatible.
Luckily we have idCommon::GetAdditionalFunction() for cases like this..
Also added a check for WEAPON_NETFIRING in idWeapon::EnterCinematic(),
I got an Assert() there in Debug builds.
Running the Demo seems to work now, at least I could finish it without
any problems (ignoring some warnings in the console)
This is an ugly hack that allows both exporting additional functions
(incl. methods via static function + void* userArg) to Game DLLs
and setting callback functions from the Game DLL that the Engine will
call, without breaking the Game API (again after this change).
This is mostly meant for replacing ugly hacks with SourceHook and
similar and mods (yes, this is still an ugly hack, but less ugly).
See the huge comment in Common.h for more information.
Right now the only thing implemented is a Callback for when images
are reloaded (via reloadImages or vid_restart) - Ruiner needs that.
Also increased GAME_API_VERSION to 9, because this breaks the A[PB]I
(hopefully after the next release it won't be broken in the foreseeable
future)
if --help or -h or -help or -? or /? is passed as commandline argument,
the help is printed (to stdout) and then the game quits.
The help shows some helpful commandline arguments, including how to
tell the engine where to find the game data, how to set the resolution
and more
The console history is saved to a file on quit and restored after
starting the game.
So the commands entered in the console the last times the game was run
are still available in the console-history, just like commands that
were just entered.
Some mods/mappacks have their own game dir (fs_game) but no own gamelib.
Doom3 defaulted to the base game dll (I think), so we should do the same.
Fixes#44
This was only implemented with MSVC style asm.
Comments suggest that it was used to help catch invalid FOV calculations,
which were probably only happening with ancient compiler bugs.
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.
