sounds queued up while the Channel Group Target Unit is inactive will all play at the same time
once the unit is made active. To avoid this, it is now only deactivated when the gamestate is
GS_LEVEL. Otherwise, it just gets muted. Fixes http://forum.zdoom.org/viewtopic.php?f=2&t=33592 "Strife voices overlap"
SVN r3818 (trunk)
actor+channel. Since in this case, it's really just restarting the sound, it shouldn't limit
it. (Since it's already playing, we know the limit wasn't exceeded when it started playing, so
it shouldn't be exceeded if we restart it now.)
SVN r3355 (trunk)
major change, so I'm making no provisions for using older FMOD DLLs when compiled with the
4.38 API. However, sound positioning is still broken like in 4.28, so you are recommended
to continue building with 4.26. Also, the Freeverb-based DSP unit is no longer present in
FMOD, so the underwater effect is currently unavailable when using 4.38 until I can figure
out how to make it work with the SFX Reverb unit instead. (And on that topic, the Freeverb
DSP was officially only for stereo outputs, so I really shouldn't have been using it in the
first place.)
- Since I would like to eventually figure out the sound positioning issues with the newer
FMODs, the following have been added:
* snd_drawoutput now labels its outputs with the speakers they represent.
* DCanvas::DrawTextA was added as an alias for DrawText, since the Windows headers #define
DrawText to a Unicode/non-Unicode variant.
* The loopsound console command was added to spawn an actor at the player's location and
have it loop a sound infinitely.
Hopefully I can figure it out. FMOD's 3D example works, so I assume the problem lies with
my code, though I don't really know where to begin looking for the problem.
SVN r3350 (trunk)
- Initialize the alt HUD explicitly in D_DoomMain.
- don't let S_UnloadReverbDef leave a broken list of sound environments behind.
- Added more code to explicitly delete data before initializing it.
SVN r3039 (trunk)
- move D_LoadWadSettings to keysections.cpp.
- made some more data reloadable.
- data structures filled by P_SetupLevel should be cleared before loading the level. They can remain non-empty in case of an error. There's probably more to fix here...
- fixed: MidiDevices and MusicAliases were not cleared before reloading local SNDINFOs.
- fixed signed/unsigned warnings in AddSwitchPair for real (GCC really allows -1u? MSVC prints a warning for that.)
SVN r3036 (trunk)
* Second argument: Volume scalar. 0 and 128 are normal volume. (Where "normal" is whatever
it was defined with in SNDINFO.) Other values scale it accordingly.
* Third argument: Minimum distance before volume fading starts.
* Fourth argument: Maximum distance at which the sound is audible. Setting either of these to 0
will use whatever they were defined with in SNDINFO.
SVN r2214 (trunk)
- fixed: The sound channel structure should not store the sound table's entries' addresses which are stored in a TArray by pointer. In case the array gets reallocated very bad things can happen. This caused some bad crashes when GZDoom's FraggleScript implementation created new sound entries.
SVN r2114 (trunk)
player does not immediately activate switches. oldbuttons was not usable
for this. This also required that CopyPlayer preserves this info.
- Fixed: When restarting the music there was a NULL pointer check missing
so it crashed when the game was started wi
- Fixed: If the Use key is used to respawn the player it must be cleared
so that it doesn't trigger any subsequent actions after respawning.
- Fixed: Resurrecting a monster did not restore flags5 and flags6.
- Fixed: Projectiles which killed a non-monster were unable to determine
what precisely they hit because MF_CORPSE is only valid for monsters.
A new flag, MF6_KILLED that gets set for all objects that die, was added
for this case.
- Added a generic A_Weave function that exposes all possible options of
A_BishopMissileWeave and A_CStaffMissileSlither. These 2 functions are
no longer needed from DECORATE and therefore deprecated.
SVN r2045 (trunk)
flag now restarts the song so that the new looping setting can be applied.
(This was easier than modifying every music handler to support modifying
loop changes on the fly, which seems like overkill.)
SVN r2041 (trunk)
* Looping sounds that have been playing for a very long time, were evicted,
and then were restarted need to have their positions clamped to lie
within the bounds of the sounds. If we try to set a start position very
far beyond the end, it will overflow inside FMOD and not work.
* A start time of 0 is not actually valid and means the sound was never
assigned a start time.
- The latter bug also reveals a problem with starting looped sounds evicted:
They need to be assigned a start time so if they should have the opportunity
to start later, they will be properly synchronized.
SVN r1987 (trunk)
