Opened 8 years ago
Closed 8 years ago
#9700 closed defect (fixed)
SCI: Audio settings sync is not quite right
Reported by: | csnover | Owned by: | csnover |
---|---|---|---|
Priority: | normal | Component: | Engine: SCI |
Version: | Keywords: | ||
Cc: | Game: |
Description
Volume changes are automatically synchronised to ScummVM whenever kDoSound
and kDoAudio
volume subops are invoked, but these ops are used by game scripts during the normal course of a game, not just by the user changing audio settings. As a result, syncing whenever the volume is changed via these kernel calls can cause the user’s audio settings to be broken. For example, quitting a game in the middle of speech will cause the normal music volume level to be restored at the reduced speech volume level.
So, the only time that the audio settings should be synchronised from the game is when the user is actually interacting with the in-game audio settings. There is no 100% consistent way to check this across all engines, but I will elaborate on potential approaches I have discovered so far in the comments on this ticket, in case anything sounds particularly good or particularly bad.
Change History (5)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
SCI32 is a little more difficult because audio control was taken over by game scripts as time went on.
GK1: Handles music volume by calling kDoSoundSetVolume
on gkMusic1
and gkMusic2
objects, and sound volume by calling kDoSoundSetVolume
on gkSound1
, gkSound2
, and gkSound3
objects. It does not call to master volume.
PQ4: pqGameControls
, or increaseVolume
and decreaseVolume
.
QFG4: volumeSlider
.
KQ7: volumeUp
and volumeDown
.
LSL6hires: hiResMenu
and volumeDial
.
GK2: Writes to global 76 (music volume).
Hoyle: volumeSlider
.
MGDX: MgButtonBar
.
Phant1: midiVolDown
, midiVolUp
, dacVolDown
, dacVolUp
, or globals 187 (music) and 188 (DAC).
PQ:SWAT: volumeDownButn
, volumeUpButn
.
Shivers: spVolume
.
SQ6: soundBar
, musicBar
.
Torin: Globals 227 (music), 228 (sfx), 229 (speech).
Alternate approaches considered include looking to see if the control panel plane is visible (doesn’t work with MGDX, and some planes had to be identified indirectly by priority+pictureId instead of by name).
comment:4 by , 8 years ago
Owner: | set to |
---|
comment:5 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in 3303a881397beff1753fba237a5da735de03edb5.
There are a few different ways to determine whether a volume change is one that should be synced. The most consistent and reliable way to do this for SCI16 appears to be to check objects on the call stack:
For the text menu bar SCI16 games, check the call stack for an object named
TheMenuBar
orMenuBar
.For icon bar SCI16 games, check the call stack for an object named
volumeSlider
in almost all the games. MG256 does its own thing with a control namedsoundBut
. LSL6 CD-lores usesmenuBar
. Slater & Charlie usesvolButton
.Considered alternatives were to look at the port name (not all the volume/control dialogues have a port name), or look to see if the control panel at global 63 is active (not all games use global 63).