.. except where SDL_Swap* is actually used (idlib/Lib.cpp).
Otherwise #if D3_IS_BIG_ENDIAN suffices, (NOT #ifdef, it's always set,
but to either 0 or 1!)
the stb libs, miniz and minizip are now always optimized to speed up
performance, esp. level loading times, in debug builds.
So far the stb libs implementation were dragged into the source file
that uses them, now I created additional source files just for them so
those can be optimized while the engine source files using those libs
can remain unoptimized in debug builds.
- s_scaleDownAndClamp CVar so the clamping and scaling down of all
sounds (that is done to prevent clipping) can be disabled
(enabled by default)
- s_alOutputLimiter CVar to allow configuring ALC_SOFT_output_limiter
which (if enabled) reduces the overall volume if it gets too loud,
to avoid clipping (defaults to -1 = "let OpenAL decide")
- s_alHRTF to allow enabling or disabling HRTF, requires ALC_SOFT_HRTF
(defaults to -1 = "let OpenAL decide")
Those CVars can be changed at runtime and are applied immediately
(in case of s_alHRTF and s_alOutputLimiter by resetting the OpenAL
device, just like we do when a disconnect is detected)
Commit 3c01757d27 introduced scaling down all sounds to prevent too
many loud-ish sounds from making OpenAL scale the overall volume down.
The problem is that before this change, many sounds had a volume > 1.0,
but vastly different: e.g. player_machinegun_fire was 5.039685 (14dB)
and player_chaingun_fire was 1.414214 (3dB).
But in the end, all volumes were clamped to 1.0 before setting AL_GAIN
(because AL_GAIN only supports values between 0 and 1 by default), so
the machinegun and chaingun had the same volume after all.
When scaling those down to 1/3 of the original volume, some sounds that
used to have a volume of >= 1.0 (=> AL_GAIN set to 1.0) had a volume
lower than 1.0, so they suddenly the chaingun sounded quiter than
the machinegun. While theoretically this is more correct than before
(after all, the sound shader of player_chaingun_fire set a much lower
volume than that of player_machinegun_fire), it doesn't sound like it
used to (even with the old software sound backend!).
Clamping to 1.0 *before* scaling to 1/3 should restore the old behavior
(of all sounds with volume > 1.0 before clamping using the same AL_GAIN)
while still avoiding the issue of having OpenAL (Soft) scale down the
overall volume when shooting a metal wall with the shotgun.
Unsurprisingly the same problem (inconsistent weapon volumes due to
incorrect sound shaders setting the volume way to high and thus relying
on being clamped to 1.0) that occurred with my volume *= 0.333 hack
also happens when reducing the global volume.
So apply that global volume scale *after* clamping to 1.0
see https://github.com/bibendovsky/eaxefx/pull/28#issuecomment-1367436162
It happened a lot more since
504b572a Update sounds at ~60Hz instead of ~10Hz, fixes#141
(because then MixLoop() is more likely to be called in the narrow
timeframe this can happen during level load) but could happen before.
So far I only observed it when starting a new game in Classic Doom 3.
See comment in the change and #461 for more information.
Originally sound updates only happened about every 100ms and
`sampleTime` (or `newSoundTime`) was a multiple of 4096
(`MIXBUFFER_SAMPLES`).
After I changed this to updates every 16ms and made the calculation of
`sampleTime` a lot simpler, it could be any value (as it's current
amount of milliseconds multiplied by 44.1).
It generally seemed to work, but it seems advisable to make it a
multiple of 8 (see also "Fix endless loop when decoding OGGs" commit).
So I round it to the nearest multiple of 8 now. Furthermore I increased
the accuracy when the game has been running for a long time by using
double instead of float, and tried to make sure that `sampleTime` is
always positive (or at least as long as `inTime` is positive).
In idSampleDecoderLocal::DecodeOGG() `totalSamples` was 1 and
`reqSamples` was 0, which caused an endless loop.. this was caused by
idSoundWorldLocal::ReadFromSaveGame() setting
`chan->openalStreamingOffset` to an odd number, I think due to
`currentSoundTime` being an odd number.
To fix that, I round up `chan->openalStreamingOffset` to a (very) even
number, and to be double-sure I also added a check in DecodeOgg() to
make sure it exits the loop if `reqSamples` is 0.
In idSampleDecoderLocal::DecodeOGG() sometimes (esp. in The Lost Mission
mod) it happens that stb_vorbis_get_samples_float() decodes one sample
less than expected so one is left and when trying to decode that,
stb_vorbis_get_samples_float() returns 0, which we interpreted as an error.
This case is now handled more gracefully: No warning is printed (except
if developer 1) and failed is not set (setting it would prevent the sound
from being played again, I think).
It can be set to a value between 0.0 and 1.0.
1.0 sounds like it did before introducing this cvar; as many people
found the the effect way to strong, I made 0.5 the default value
Otherwise especially looped sounds continue playing while the menu
is open, especially noticeable when opening the menu while firing
the chaingun (the whirring sound continues playing).
The code to decompress OGG files directly on load if they're shorter
than s_decompressionLimit seconds (usually 6) accidentally got broken
when removing the non-OpenAL soundbackends:
`if ( objectInfo.wFormatTag == WAVE_FORMAT_TAG_OGG )` slipped into the
`if ( objectInfo.wFormatTag == WAVE_FORMAT_TAG_PCM )` block - obviously
both can't be true at the same time so the OGG case was never executed.
Now it's in its own block again. I put it into a {} scope so it doesn't
have to be re-indented (=> more useful with git blame)
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.
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!
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.
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.
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)
* 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 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
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.
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!
