Seems to work; note that idWaveFile is only ever used in idSoundSample::Load()
As stb_vorbis doesn't support custom callbacks for reading, I feed it
the full .ogg files as a buffer. Shouldn't make much of a difference
though - either the whole file is decoded on load anyway (so the buffer
is freed after decoding, or it's streamed, but in that case the old code
also kept the whole ogg file in memory by using idFily_Memory.
I also added warning messages in places where calls to stb_vorbis_*()
can fail, where there were none in the equivalent libvorbis code.
libjpeg is a pain in the ass, especially due to Ubuntu shipping
libjpeg-turbo in jpeg8 mode as their default libjpeg, while every other
distro I checked (including debian!) ships libjpeg-turbo in jpeg6.2 mode
Thankfully stb_image.h exists - just a single header and it even
has a (much!) friendlier API.
It's not like Doom3 (or any of the mods I checked) actually use JPEGs,
but I'm sure if I'd drop support completely, someone would complain
(perhaps rightfully so).
the problem was that the sources were still associated to it, because
they get deleted after the listenerSlot: the sources get freed in
idSoundSystemLocal::Shutdown() which is called by
idCommonLocal::ShutdownGame() in line 3217,
while the listenerSlot is deleted via idSessionLocal::Shutdown()
-> delete sw/rw -> idSoundWorldLocal::~idSoundWorldLocal()
-> idSoundWorldLocal::Shutdown() - and idSessionLocal::Shutdown() is
called in idCommonLocal::ShutdownGame() line 3211, before the other.
I'm not gonna mess with the order of deleting things in ShutdownGame(),
but it's sufficient to unassociate the effect slot from the source
when destroying the emitters in idSoundWorldLocal::Shutdown(),
by adding a call for that to idSoundChannel::ALStop() - and destroying
the emitters before deleting listenerSlot.
Before this fix, with ALSOFT_LOGLEVEL=3 you got the following warning:
(WW) Error generated on context 0x5578fce2a280, code 0xa004,
"Deleting in-use effect slot 1"
Thanks for openal-soft's KittyCat for pointing this out!
Turns out that ${CMAKE_SYSTEM_PROCESSOR} is broken on Windows
(both for Visual Studio and for 32bit MinGW/msys shells which for some
reason seem to output x86_64 in uname -a)
Also suppressed -Wclass-memaccess warnings from GCC >= 8
idClipModel::axis is an idMat3 rotation matrix.
Usually it's an identity matrix, but if the player is pushed around by
an idPush entity it's modified and apparently can (wrongly) remain
modified, possibly when saving while idPush is active.
This seems to happen sometimes on the crashing elevator in game/delta1.
The fix/workaround is to reset it to mat3_identity when loading a
savegame.
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
"Fix "t->c->value.argSize == func->parmTotal" Assertion in Scripts, #303"
had broken old savegames because the script checksum
(idProgram::CalculateChecksum()) changed, see #344.
This is fixed now, also the BUILD_NUMBER is increased so old savegames
can be identified for a workaround.
Don't use this commit without the next one which will further modify the
savegame format (for the new BUILD_NUMBER 1305)
This reverts commit 01ac144b09.
Looks like this broke the build on some systems, because some
package managers pack SDL2Config.cmake and others pack sdl2-config.cmake
in their SDL2 development packages (for some reason, SDL2 seems
to ship both in their source, and they appear to be incompatible).
Shipping our own FindSDL2.cmake might be unclean/ugly/whatever, but
at least it works (most of the time? at least it appears to work better
than not shipping it)
* Windows DLL-Load-Errors
Added error reporting using formatmessage, ignoring if the DLL just
doesn't exist, custom warning for "[193 (0xC1)] is not a valid Win32
application." (probably wrong architecture)
* update gitignore with build folder
.. but only if the file exists.
It's ok if mods don't have their own DLL/.so, but if they do have one
and loading fails it's interesting why they failed (e.g. no access
rights, 64bit lib with 32bit executable or other way around, missing
symbols due to wrong libc version, ...)
The same should be done for Windows, but that's still TODO.
I updated sdl2-config.cmake in dhewm3-libs so building on Windows with
them works again, however that required also a little change in
dhewm3's CMakeLists.txt
I also still had some uncommited changes for that fullscreen workaround
that I'm committing now.
.. that doesn't switch the display resolution, but creates a borderless
fullscreen window at current desktop resolution.
SDL2-only (SDL_WINDOW_FULLSCREEN_DESKTOP).
Doing this with an additional CVar instead of r_fullscreen 2 or similar
has the advantage that it works properly with Alt-Enter
SDL has a bug (at least on Windows) where SDL_CreateWindow() with
SDL_WINDOW_FULLSCREEN doesn't use the configured resolution (if it's
higher than the current desktop resolution).
Try to work around that - based on Yamagi Quake II code.
Also, if GLimp_Init() fails, the "safe mode" fallback is now in
windowed mode instead of fullscreen mode.
The code used #ifdef __ppc__, probably a leftover from old Mac support,
which apparently doesn't work on all PPC systems (maybe not 64bit PPC).
Now using the LittleFloat() function instead which exists for
exactly this purpose and already handles endianess properly.
If a "class" (object) in a Script has multiple member function
prototypes, and one function implementation later calls another before
that is implemented, there was an assertion when the script was parsed
(at map start), because the size of function arguments at the call-site
didn't match what the function expected - because the function hadn't
calculated that size yet, that only happened once its own
implementation was parsed.
Now it's calculated (and stored) when the prototype/declaration is
parsed to prevent this issue, which seems to be kinda common with Mods,
esp. Script-only mods, as the release game DLLs had Assertions disabled.
It corrupted the stack when called with buffers allocated on the stack
and numSamples that are not a multiple of four, apparently, by writing
4 floats too many, at least in the 22KHz Stereo case..
This caused the crash described in
https://github.com/dhewm/dhewm3/issues/303#issuecomment-678809662
Now it just uses the generic C code, like all platforms besides MSVC/x86
already do.
Apparently VS2019 (or its integrated CMake?) interpreted
add_definitions(/MP) as "also pass it to rc.exe" which didn't like it..
no idea why this worked before, but now it seems to work everywhere.
fix#304
Also set VS_STARTUP_PROJECT so when launching the debugger in VS it doesn't
try to launch ALL_BUILD (...) but dhewm3.
idSessionLocal::SaveGame() uses saveName for both the description in
savegames/bla.txt and the filename itself ("bla" in this case), which
is a "scrubbed" version of that string ("file extension" removed,
problematic chars replaced with '_').
In case of Autosaves, MoveToNewMap() passes a translated name of the
map as saveName, which makes sense for the description, but not so much
for the filename.
In Spanish the Alpha Labs names are like "LAB. ALFA 1", "LAB. ALFA 2" ..
and everything after "LAB" is cut off as a file extension - so every
autosave of an Alpha Labs part overwrites the last one, as they all get
the same name...
The solution is to pass an additional (optional) argument saveFileName
to idSessionLocal::SaveGame(), and for autosaves pass the mapname
(which is the filename without .map; yes, it might contain slashes,
but the scrubber will turn them into _) instead of the translated name
as saveFileName.
