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.
OpenAL devices can disconnect, and with some luck they're back after
a few seconds. This especially seems to happen with Intels Windows GPU
driver and display-audio when switching the resolution or enabling
fullscreen, see #209
Now a disconnect is detected and we try to reset the device for 20
seconds, hoping it comes back. This needs at least openal-soft 1.17.0
to build and 1.20.0 or newer to actually work.
Also added missing stub functions in openal_stub.cpp (used by dedicated
server so it doesn't have to link libopenal)
idSoundSystemLocal::Init() didn't consider the case that opening the
default device (alcOpenDevice(NULL)) could fail, but this can happen if no
audio devices exist (or all are disabled or they're sleeping bluetooth
headphones or whatever).
Starting a map failed then with
ERROR: idSoundCache: error generating OpenAL hardware buffer
Now this and "s_noSound 1" are handled the same and one can play.
If the main sound in a shader was a .wav
(soundShader->entries[0]->hardwareBuffer == true), only that sound was
played (and looped with AL_LOOPING), even if a leadin was configured.
If the main sound was an .ogg it worked.
Not it should always work.
On Windows, ID_INLINE does __forceinline, which is bad if the function
calls alloca() and is called in a loop..
So use just __inline there so the compiler can choose not to inline
(if called in a loop).
This didn't cause actual stack overflows as far as I know, but it could
(and MSVC warns about it).
turns out tri->numIndexes can be quite big so _alloca16() would be
called with >1MB - and the Win32 stack only is 1MB, so that overflows.
As a workaround, use Mem_Alloc16() if we need >600KB
was reported in #265
The Doom3: Lost Mission (aka D3LE) mod uses string table entry keys that
don't follow the proper Doom3 scheme of "#str_01234", but look like
"#str_adil_exis_pda_01_audio_info" - the "hash" algorithm of idLangDict,
which basically just converts the number after "#str_" into an int,
probably doesn't work very well with this and there was an assertion
to prevent this..
However, it seems to work well enough, so now I only print one warning
for the first "invalid" key and otherwise accept those keys.
The stringtable (strings/*.lang) also has font-related entries
(like "#font" "Chainlink_Semi-Bold") that triggered another assertion,
now everything that starts with "#font" is silently skipped.
can be enabled/disabled with the r_useStencilOpSeparate for comparisons
(like Z-Fail, this doesn't really seem to make a difference on my main
machine, neither on my RPi4)
Partly based on Pat Raynor's Code:
2933cb5545/neo/renderer/draw_stencilshadow.cpp
the tables contain character constants like ('ä') that are supposed to
be interpreted as ISO8859-1 or WINDOWS-1252 or sth, but that doesn't
seem to work with MinGW (anymore) - seems like it assumes UTF-8 by
default, and for some reason -finput-charset=ISO8859-1 doesn't help
either, it complains about multichar character constants then..
Anyway, now the table entries are represented as the corresponding
integer constants which seems to work as intended.
Fixes#238
dhewm3 uses source_group(TREE ...) which is only supported in
CMake 3.8 and newer.
As it's only cosmetical (so files show up in correct path in IDEs like
Visual Studio), I just replace the source_group() function with a dummy
for affected CMake versions. At least people can still compile then..
fixes#232
Bringing back support for the (MFC-based Windows-only) editing tools.
Only tested 32bit (not sure if the code is 64bit-clean), needs a
"proper" (non-Express) version of Visual Studio *including* MFC support,
tested the free "Community" Editions of VS 2013 and 2017.
(For VS2013 I needed to install the "Visual C++ MFC MBCS Library for
Visual Studio 2013" because it either didn't include MFC support at all
or only the wrong version, don't remember, you'll need that one anyway)
In short, it uses a idGLDrawableMaterial widget that calls
renderSystem->BeginFrame(w, h); (with w and h being small for the texture
preview window) and BeginFrame() sets glConfig.vidWidth and vidHeight to
w/h and that never got reset to the original value (window width/height).
This breaks everything because for some reason
renderSystem->GetSCreenWidth()/Height() return glConfig.vidWidth/Height
so it will just continue to render everything at that resolution (in a
small rectangle on the lower left corner of the window).
This bug has already existed in Doom3 1.3.1 (but was less noticable because
apparently when switching away from Doom3 and back to the window it reset
vidWidth/Height to the window resolution)
I only implemented a workaround (restore glConfig.vid* after rendering the
texture preview), it's possible that the same issue exists in other
(probably editor-) code - but a "proper fix" might also break code (and I'm
not super-familiar with the editor code or even just using them)
When selecting a texture in Inspectors -> Media -> Textures that doesn't
really exist (.mtr defines it, but referenced image files are missing),
the game/editor used to crash.
The problem was that somehow people thought the best way to communicate
that a file wasn't found was by setting the timestamp to 0xFFFFFFFF
and then checking for that - sometimes (incorrectly) by comparing it to -1.
That worked for 32bit ID_TIME_T (typedefed to time_t), but not with 64bit
time_t, which now seems to be the default for Win32 in VS.
So I replaced a few -1 and 0xFF... with FILE_NOT_FOUND_TIMESTAMP and now it
works.
FILE_NOT_FOUND_TIMESTAMP is still defined as 0xFFFFFFFF, maybe I should
change that, unsure if that'd break anything though..
When changing it one should keep in mind that time_t might still be 32bit
on some platforms (Linux x86?) so that should still work.. (-1 could work)
...by including `vecLib/vecLib.h` only on `__APPLE__`, and not just any `__ppc__`
From https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235668:
> On powerpc* platforms vecLib/vecLib.h is included by default.
> This header is only available on Mac OS X, so remove it. It
> doesn't seem to be actually needed to compile this port.
Upgrade CMakeLists.txt minimum SDK version for compiling in macOS to v.10.9 "Mavericks" for 64 bit builds.
Until now, make failed with this error:
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
In file included from /Juegos/dhewm3/neo/idlib/bv/Bounds.cpp:29:
/Juegos/dhewm3/neo/sys/platform.h:185:10: fatal error: 'cstddef' file not found
#include <cstddef>
^~~~~~~~~
1 warning and 1 error generated.
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..
causes trouble on macOS, and we shouldn't interact with X11 directly
anyway, because SDL does it for us.
OpenBSD apparently needed it (at least it was added for OpenBSD
support), but the only place I can imagine it being needed is the
superfluous #include <SDL_syswm.h> in neo/sys/glimp.cpp - which I now
removed. In case it's needed after all please tell me, then I'll add it
again - but guarded by if(os STREQUALS "OpenBSD") or however one checks
for OpenBSD in CMake.
handling SIGTTIN/OU allows running Doom3 in the background (or even
sending it to the background with Ctrl-Z + bg) by disabling TTY input
(before it would get stuck when run in background without +set in_tty 0,
see #215)
While at it, I also added signal handlers for some common crash signals
(SIGILL, SIGABRT, SIGFPE, SIGSEGV) to print a backtrace before exiting
the game (partly based on Yamagi Quake II code).
For some reason CMake thinks it's a great default to display all the source
files of a project in Visual Studio as a flat list (instead of in the
directory structure they're physically in).
source_group(TREE ...) *per project/"target"* helps.
Also, so far there was no reason to list or otherwise use header files
in CMakeLists.txt - but for them to turn up in VS they must be added to
the source lists. I've done that, but I'm sloppily globbing them instead
of adding each headder manually like it's done for the source files
(because it doesn't matter if a header that's not really used turns up
in those lists)
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)
it could happen that i is 1 but numPlanes is still 0
(=> if for i = 0: ( p[j] - p[i] ).LengthSqr() < 0.01f )
so planes[-1] would be accessed which of course is invalid and can crash
WIN_DESKTOP means that this can currently only be set for the top-level
window in a .gui (all its subwindows/widgets will be scaled implicitly)
There are two ways to make a GUI use this:
1. in the .gui add a window variable "scaleto43 1", like
windowDef Desktop {
rect 0 ,0 ,640 ,480
nocursor 1
float talk 0
scaleto43 1
// .. etc rest of windowDef
2. When creating the GUI from C++ code, you can afterwards make the
UserInterface scale to 4:3 like this:
idUserInterface* ui = Whatever(); // create it
ui->SetStateBool("scaleto43", true);
ui->StateChanged(gameLocal.time);
Both lines are important!
As you can see in my changes to Player.cpp, my primary usecase for this
is the cursor/crosshair GUI.
So stuff doesn't look so distorted in widescreen resolutions.
Implies that there are black bars on the left/right then..
Can be disabled with "r_scaleMenusTo43 0"
Does *not* affect the HUD (incl. crosshair) - scaling it automagically
would be very hard (or impossible), because it doesn't only render
the crosshair, healthpoints etc, but also fullscreen effects like the
screen turning red when the player is hit - and fullscreen effects
would look very shitty if they didn't cover the whole screen but had
"empty" bars on left/right.
(Mostly) fixes#188 and #189
Mods that have their own video settings menu can tell dhewm3 to replace
the "choices" and "values" entries in their choiceDef with the
resolutions supported by dhewm3 (and corresponding modes).
So if we add new video modes to dhewm3, they'll automatically appear in
the menu without changing the .gui
To enable this, the mod authors only need to add a "injectResolutions 1"
entry to their resolution choiceDef. By default, the first entry will
be "r_custom*" for r_mode -1, which means "custom resolution, use
r_customWidth and r_customHeight".
If that entry shoud be disabled for the mod, just add another entry:
"injectCustomResolutionMode 0"
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
If an OpenAL source runs out of samples it transisions into state
AL_STOPPED. That happens if we're entering the menu (which switches
to another soundworld) and when saving the game (because the game
blocks for some milliseconds). Work around this by adding a new
field 'stopped' to the channel state and use that to determine if
a sound was stopped. And not AL_STOPPED like before.
In the last few weeks I've played again through the game and kept an eye
on small oddities. And there're a lot of them. For example some GUIs and
videos getting stuck after the first frame (issue #192) or being unable
to protect the guy with the lamp in Alpha Labs 3. Some digging proved
that most - if not all - of these problems are caused by the compilers
optimization level. When build with -O2 both g++ 8.1 and clang 6.0.0 are
producing working code. g++ 8.1 with -O3 has some small, hard to notice
oddities, clang 6.0.0 with -O3 shows a lot of them. Since there's not
measurable difference between -O3 and -O2 just go down to the later:
x doom_o3.txt
+ doom_o2.txt
+----------------------------------------------------------------------+
| + |
| + * |
|x * x * |
| |_____________________|___A______M__A_________M___|_||
+----------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 5 173 178 177 176.4 2.0736441
+ 5 176 178 178 177.2 1.0954451
so even with many loud sounds the overall volume isn't reduced by
OpenAL - apparently OpenAL scales down all sounds temporarily if the
mixed result would be too loud or sth like that.
Just sending all sounds to OpenAL with a lower volume prevents that from
happening (just set your system speaker volume a bit higher if needed).
This problem was especially noticable when shooting at metal walls with
the shotgun (each pellet produces an impact sound so it gets kinda loud)
Sometimes memory was allocated with new[] but freed with delete instead
of delete[], which is wrong.
And there were some small memory leaks, too.
Furtunately clang's AddressSanitizer detected all that so I could easily
fix it.
(There seem to be some more small memory leaks which are harder to fix,
though)
On FreeBSD, the game used to crash when loading the last level of RoE
(d3xp), while loading models/david/hell_h7.ma.
The problem could be reproduced on Linux whith #define USE_LIBC_MALLOC 1
and clang's AddressSanitizer.
Turns out that this file specifies a vertex transform for a non-existent
vertex (index 31, while we only have 0-30) and thus the bounds of
pMesh->vertexes[] are violated.
I added a check to ensure the index is within the bounds and a Warning
if it isn't.
It should work now. If however it turns out that more files have this
problem, maybe .ma is parsed incorrectly and we need a differently fix.
(Should) fix#138
as we do int buttonIndex = ev.button.button - SDL_BUTTON_LEFT;
it's only consistent to do if(ev.button.button < SDL_BUTTON_LEFT + 8)
it doesn't really make any difference as long as SDL_BUTTON_LEFT is 1,
but this way it's safe for SDL3 or whatever future version might break
the ABI.
__builtin_trap() causes an illegal instruction and thus the process
can't resume afterwards.
raise(SIGTRAP) only breaks into the debugger and thus allows to
"ignore" the assertion while debugging.
The assertion in idBounds::operator-(const idBounds&) was triggered
from idWeapon::Event_LaunchProjectiles() (ownerBounds - projBounds)
It only happened when using the BFG.
So I added a check to make sure calling operator- is legal.
I guess this also caused #122
It's an SDL_TEXTEDITING event which we seem to get on Windows whenever
the Window gains focus (or is created). I think it can be safely
ignored, so that's what I do.
I also changed how those warnings are printed - as a hex number now,
because they're defined as hex numbers in the SDL source and it's easier
to find out what kind of event it is this way.
When ingame, Shift-Esc would open the menu and another Shift-Esc the
console. Now it immediately opens the console and only Esc without
Shift opens the menu.
The fullscreen guis pretend to be 640x480 internally, also for the mouse
cursor position. So adding the actually moved pixels (when playing the
game at a higher resolution) to the GUIs cursor position makes it move
too fast.
To fix that I detect (hopefully that check is reliable!) if the
idUserInterfaceLocal instance is a fullscreen GUI and if so scale the
reported mouse moved pixels with 640/actual_window_width and
480/actual_window_height.
If res_none (event with .evType == EV_NONE) is returned,
idEventLoop::RunEventLoop() will assume there are no more events this
frame => pending events will be delayed til next frame (or later if
again res_none is returned in the meantime).
So res_none shouldn't be returned just because there was an SDL event
we didn't care about or we did care about but don't generate a doom3
event for (but toggle fullscreen or something).
Instead we should just fetch and handle the next SDL event.
Before checking there I look for gamedata next to the executable, but
the check was broken: I got the directory the executable is in and
checked if it exists.. well.. of course it does, but that doesn't mean
there's game data in it..
So now I check if that directory actually has a "base/" subdirectory
(or whatever is #defined in BASE_GAMEDIR) and if that fails
/usr/local/games/doom3/ is tried instead.
Thanks chungy for pointing the bug out in #97 !
* r_mode defaults to 5 (1024x768), I think that's more sane than 640x480
* r_fullscreen defaults to 0 (=> windowed mode) because fullscreen in
the wrong resolution sucks.. let people do their initial configuration
in windowed mode
* r_swapInterval defaults to 1 (=> VSync active by default) because that
makes the game feel more smooth and most PCs should be able to 60fps
in this 11years old game anyway
* s_useEAXReverb defaults to 1 (=> use EAX/EFX effects by default),
because OpenAL-soft supports them on all platforms/hardware and if
for some reason the used OpenAL implementation doesn't support it,
it's deactivated automatically anyway.
All these things can be configured in the Options Menu.
the resolutions are really hardcoded in an ugly combination of the
values r_mode supports, a string in strings/*.lang ("#str_04222")
describing the resolutions r_mode supports
("640x480;800x600;1024x768;1152x864;1280x1024;1600x1200")
and a string in mainmenu.gui with the corresponding r_mode values
("3;4;5;6;7;8").. as neither the strings nor mainmenu.gui are GPL'ed
I can't really redistribute a changed version of them.
So I added lots of resolutions to r_vidModes and wrote two functions
that generate the resolutions list string and r_mode value
string for the GUI.
Then I added a hack in the code that detects when the "window" for the
system options ("choiceDef OS2Primary") is created and overwrites the
hardcoded strings with custom ones from my new functions.
This is tested with both the main game and the official d3xp
(Resurrection of Evil) Addon.
No idea if it works with other mods, depends on whether they just copied
that part of the menu or wrote their own.
for some reason neo/tools/compilers/dmap/optimize.cpp included windows.h
and GL/gl.h before including dmap.h, which indirectly includes qgl.h.
This made things in qgl.h explode - seems like APIENTRYP in the
QGLPROC() macro expanded to bullshit because of some APIENTRYP or
APIENTRY definition in windows.h or GL/gl.h
Those includes are totally unnecessary, dmap.h -> qgl.h already includes
GL/gl.h, indirectly via SDL_opengl.h and in that setup things somehow
are fine.
the problem was that the CVar was initialized from the commandline
*after* Posix_InitConsoleInput() is called, so it was too late.
common->StartupVariable() seems to be the right way to initialize a
CVar early.
While I couldn't reproduce the crash, according to the bugreport it
happens if renderSystem->GetScreenWidth()/Height() returned 0 - and
that is indeed the only plausible reason I can imagine for it.
So I check for that case and handle it gracefully by defaulting to
4:3 FOV values.
The version will be 1.4.0 because it's not compatible with
Doom3 1.3.1 mod DLLs.
(Note that this commit doesn't mean 1.4.0 is done, I might do some
minor changes before tagging the Release!)
Because Debian Squeeze's libjpeg6 didn't have jpeg_mem_src(), we added
jpeg_memory_src() to provide the functionality.
This shouldn't be needed anymore and without it we can drop libjpeg code
from our repo.
Fixes#110
For some reason Gentoo renamed zlibs OF() macro to _Z_OF
Our minizip uses OF(), so add a #define for it in case
_Z_OF is defined.
Thanks to salamanderrake for the fix
The implementation is now in framework/minizip/*
instead of framework/Unzip.cpp
This was version 0.15beta, now we use 1.1 from
zlib 1.2.7/contrib/minizip
Some code had to be adjusted for this, but it got
cleaner on the way
idAnimator::GetJointLocalTransform() miscompiles with gcc 4.5 and
-ftree-vrp (implied by -O2).
Reorder code to avoid the compiler bug, no functional change.
The original commit was for game/ only, but d3xp/ will have the same
issues..
Added r_aspectratio -1 which means "auto" (as new default).
This mode sets fov_x and fov_y according to screen-width/height.
=> No need to set r_aspectratio manually anymore (assuming your display's
pixels are about square).
The standard aspect ratios can still be enforced as before, though.
When one tries to quit the game (via quit in console) while a timedemo
is running, the game freezes indefinitely while displaying the timedemo
results.
This happens because the MessageBox used for that waits for a an event
normally triggered by a timer - but it seems like that does not happen
anymore during Shutdown()
The fix makes sure that this message box isn't displayed.
Commit 9e158470 set the SDL OpenGL attribut SDL_GL_ALPHA_SIZE to 0 since
the alpha channel is used by Wayland. But for X11 the GLX 1.4 specification
clearly states: "If the requested number of bits in attrib_list for a
particular color component is 0 or GLX_DONT_CARE, then the number of
bits for that component is not considered." So if SDL_GL_ALPHA_SIZE is
0 a framebuffer without an alpha channel is created. This is no problem
on the default GLX module due to a non standard implementation but
manifests with Nvidias GLX module. The consequence are render mistakes
like in game display showing static or the flashlight looking weird.
Everytime List.h is included in a new file (and sys/platform.h isn't)
there are confusing compiler-errors..
So just #include sys/platform.h in List.h directly, because it uses
ID_INLINE which is defined there
GCC had shitloads of superfluous warnings wherever List.h and Str.h were
included.. get rid of them by using #pragma GCC diagnostic at some places
in List.h and Str.h.
Also add some casts, initialize some variables for other warnings
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
* the OpenAL function definitions mustn't include __declspec(dllimport)
=> fixed by pretending to compile OpenAL statically
* glimp.cpp shouldn't be used in dedicated-only mode (as it was already
the case on Linux and OSX)
=> No special handling for ID_DEDICATED needed in glimp.cpp, as it's not
used anyway
* add APIENTRY to every gl function in stub_gl.cpp for compatibility
with windows headers and MSVC
* remove GL/gl.h #include from win_local.h as it's not needed
* in qgl.h, when building dedicated server for windows, redefine WINGDIAPI
to nothing for SDL_opengl.h #include to get rid off __declspec(dllimport)
by using #pragma push_macro and pop_macro, because our stub is no dll.
Fixes https://github.com/dhewm/dhewm3/issues/39
Some functions were duplicated, the only difference was a const in one
parameter. The definitions in the header were with const, so I kept
those versions.
Also, the functions in the header are pure C, so add extern "C",
this fixes issues with MSVC and the formerly duplicated functions.
There used to be a bug (discussed in #40), that ALT was still set after
using ALT-Tab. Thus when next pressing enter fullscreen was toggled.
This should now be fixed by unsetting the modifiers when focus is
regained (SDL_ACTIVEEVENT or SDL_WINDOWEVENT_FOCUS_GAINED).
On windows un-grabbing (or possibly re-grabbing) the mouse seems to
mess up the view angly (view is centered afterwards), see
https://github.com/dhewm/dhewm3/issues/18
That's fixed by not releasing the mouse (there is no reason to do that
anyway).
In 09ea2ca8 we fixed a memset(), but it turns out wiping memory at that
position is wrong in the first place:
If an ase mesh has a GEOMOBJECT/NODE_TM transform matrix before the
GEOMOBJECT/MESH entry, the prior parsed TM will be wiped.
Since a GEOMOBJECT aseObject_t is already calling memset() upon
initialisation, we can just drop the spurios call.
Fixes#13.
Set the library name to an empty string to prevent this error:
CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
CURL_LIBRARY (ADVANCED)
Since we don't have our own signal handler anymore, those two
init functions can be merged into the existing Sys_Init(), which
is already called by common->Init().
warning: variable ‘err’ set but not used [-Wunused-but-set-variable]
warning: unused variable ‘len’ [-Wunused-variable]
warning: format ‘%d’ expects argument of type ‘int’, but argument 3
has type ‘long long unsigned int’ [-Wformat]
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.
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.
Fix silly issue from 3d692b58 (sizeof(E_EVENT_SIZEOF_VEC)).
Align entity values of events to the native pointer size, which
is noticeably faster on x86_64 and fixes another assert() in
debug builds.
Past savegames with entities in events are not compatible.
The argument size of each event is checked in debug builds
and this change was missing from the x86_64 commits.
Surprisingly this didn't trigger yet with the original game,
only with the mod 'Classic Doom 3'.
Set AL_LOWPASS_GAIN like EAX did under the hood.
Set the same filter via AL_DIRECT_FILTER on sources.
This should bring the overall sfx closer to EAX:
<kaan_> it sounds awesome
All infos provided by KittyCat from #openal.
The gain values are expressed as millibels in the .efx files
and need to be converted to normalized floating points.
Get the EAX4 EAXREVERBFLAGS_DECAYHFLIMIT from the "flags" token
and set AL_EAXREVERB_DECAY_HFLIMIT accordingly.
All infos provided by KittyCat from #openal, many thanks!
First attempt at porting the EAX reverb code to EFX.
This only works when the ALC_EXT_EFX extension is supported by
the OpenAL vendor (which is not the case for the OSX supplied
framework, use OpenAL soft instead).
The current stable version of OpenAL Soft (v1.13 as of this
writing) can barely handle this additional workload, current
master is highly recommended when using this feature.
We already link to OPENAL_LIBRARY further down.
Log some debug OpenAL info, mainly so OSX users can check they are not
using Apple's OpenAL. OpenAL Soft is recommended as it fixes many
issues.
I specify it as follows:
cmake -DOPENAL_LIBRARY=/usr/local/lib/libopenal.dylib -DOPENAL_INCLUDE_DIR=/usr/local/include -GXcode ../neo/
(because FindOpenAL.cmake prefers the /System frameworks)
Found another copy in renderer/Cinematic.cpp. Move the
newer implementation from renderer/Image_files.cpp in its
own file and use the libjpeg v8c license blob (which is where
this code comes from).
Adapt README too with the v8c license.
Don't link against SDLmain.[a|lib], always compile it.
We can use pure C MinGW cross compiled libraries with MSVC, and
this is the only static library used.
SDLmain.m does the bulk of the work for us, so get rid of
the DOOMController NSObject, move the quakeMain() contents to
main() and let SDL do its thing.
Add missing SDLMain and icon/resource files to generated .xcodeproj
Now builds on Lion in XCode4 with the 10.6 SDK using LLVM-GCC4.2.
Also tested on WinXP in VS 9 2008 Professional, I don't appear to have
broken anything there, stuff like MACOSX_BUNDLE_INFO_PLIST is
effectively ignored.
idAnimator::GetJointLocalTransform() miscompiles with gcc 4.5 and
-ftree-vrp (implied by -O2).
Reorder code to avoid the compiler bug, no functional change.
Sys_GetScanTable() and MapKey() are only used by the Windows backend
or the Windows-only tools.
Rename to Win_GetScanTable() and move MapKey() as Win_MapKey() to
win_input.cpp.
New CVar "in_kbd" to set the layout for the keyboard. SDL 1.2
doesn't offer any way to determine it, and we need this feature
to use the same key for toggling the console independent of the
keyboard layout.
The old "in_nograb" from the Linux backend is still supported.
Use SDL to set video modes, get a GL context and detect the
amount of VRAM.
As with the Linux GLimp implementation, sys_videoRam can be used
in case the SDL detection fails.
Required for events with string arguments. On debug builds
an assert() is triggered when trying to save such an event,
while events could not be properly restored in any build.
This happens when going from map delta4 to hell1 and the
autosave feature kicks in. The trigger event 'selectWeapon'
with the string argument 'weapon_fists' is in the event queue.
With the binary from id a warning is issued:
WARNING: player1 is not carrying weapon ''
so the bug exists in there too, just that its a release build
and doesn't abort().
I also managed to trigger this while saving shortly after
activating an elevator switch.
