Opened 9 years ago
Closed 9 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 , 9 years ago
comment:2 by , 9 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 , 9 years ago
| Owner: | set to |
|---|
comment:5 by , 9 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
TheMenuBarorMenuBar.For icon bar SCI16 games, check the call stack for an object named
volumeSliderin 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).