Commit graph

7 commits

Author SHA1 Message Date
James R
bd62fe4e90 TuneManager: remove GME related code 2024-01-29 23:07:57 -08:00
James R
1a0b927cf2 Add Music_LevelVolume, Music_ResetLevelVolume: change music volume from gameplay contexts
- Tunes opt into using this volume by setting
  Tune::use_level_volume to true
2024-01-15 16:29:01 -08:00
James R
f3208ac8ef TuneManager: clear current song if music is disabled, so music can resume later 2023-12-23 03:18:03 -08:00
James R
806067f48f Add Music_BatchExempt, temporarily exemplify a tune from batch operations 2023-12-05 04:15:21 -08:00
James R
97a66a1856 srb2::music::TuneManager::insert: add optional field, to duplicate an existing tune's configuration 2023-12-04 20:17:17 -08:00
Lach
962273044c Fix music manager clang error (thanks jart) 2023-08-15 20:37:21 +10:00
James R
39f46a0f20 Replace music handling
(This commit does not compile. Sound test and tunes
command code needs to be ported after this.)

This is a big one. Here's the rundown:

The old music system was very direct, much of the time
just a proxy to the real sound API in i_sound.h.

You could change the music on command, but there wasn't
a consistent way to prevent some music from playing over
others. P_RestoreMusic is one example of needing to
address this problem. The jingles system was intended as
another solution. Furthermore, sound test (Stereo) has its
own needs.

I am removing all of that. Music handling in general is
now a very deliberate system, kind of similar to jingles.

In the new system, "tunes" are registered. The tune stores
info such as whether it should loop or fade out. Most of
the configuration is intended to be initialized only ONCE.
Tunes can be mapped to an actual music lump. They can be
remapped at any time too.

Tunes are also configured with a priority number. This
determines which tune is heard, if multiple are supposed
to be playing at a time. You can even tell a tune how long
it should play, so it's unnecessary to track this with
bespoke timers.
2023-08-06 17:31:45 -07:00