Opened 15 years ago
Last modified 7 years ago
#7722 new feature request
GUI: volume and subtitles speed sliders
| Reported by: | criezy | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
When using sliders, I am not too much in favour of a number that doesn't mean much (e.g. subtitle speed, volumes). The values have only a meaning relative to each other, which in itself is not useless and for this reason I would keep them. But I would add some hint on what it means. For example add a "slow" on the left of the subtitle speed slider and "fast" on the right (resp. "low" and "high" for the volume sliders) and display the value only on the right of that.
Ticket imported from: #2821529. Ticket imported from: feature-requests/538.
Change History (7)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Well the truth about the subtitles slider is, that I think it's engine dependend whether to the very left it's fast or to slow. That depends if the engine uses a "subtitle delay" like setting, which would mean left is fast, right is slow. While a "subtitle speed" setting would mean left is slow, right is fast.
I think at least SCUMM is using subtitle delay, Tinsel probably too. KYRA for example uses a speed like setting, the further to the right the faster the subtitles disappear.
BTW. That that 'different' subtitle speed control is only there in the SCUMM engine AFAIK. It uses another scale. What's even worse is the dialog which shows up when you use '+' and '-' to change the settings, it's again a different scale (x inverted to be precise). The GMM, which should one day also replace the SCUMM menu, does use the same settings range as the launcher.
comment:3 by , 15 years ago
Now, when we have GUI features, this would not be complex to modify this control per game.
Thus we can use even native ranges and behavior, that is "Subtitle speed"/"Subtitle delay"
comment:4 by , 15 years ago
We of course still need a nice default, since we can't expect all configs to be updated currently, because of a missing migration dialog on ScummVM launch.
I would still guess from a user point a consistent setting would be best. We might just reverse the settings internally, depending on what the engines use. Thus IMHO with a consistent behavior of the subtitle speed control between all engines we can be sure nobody is confused.
comment:5 by , 15 years ago
There are two separate issues here:
1) The actual item asks about adding nice labels to various sliders that indicate which sides correspond to low/high resp. slow/fast resp. whatever else. To that I say: Good idea, let's do it, *where possible* at least.
2) The discussion in the comments then revolves around the problem that the subtitle "speed" settings have reverse interpretation in some engines. As such, it is relevant to the feature request, although this here is probably not the best place to discuss them... Anyway, on that subject: It is *not* a simple matter to change / reverse the subtitle speed vs. delay meaning in engines. Mostly because we currently have no good migration path for config settings. I.e. there is no way to know whether a value has already been converted, or not.
This problem could be solved in two ways: 1) Start to make use of a config file version number stored in the config file. If the config file version is before X, assume the subtitle "speed" has the old meaning; else assume it has the new meaning. Alternative approach: Deprecate the "talkspeed" config value, and replace it by a new one, e.g. "subtitle_speed", which uses the new values.
There is another problem: Different engines may use different scales. As long as we are only talking about reversing the subtitle speed vs. delay, that's not a major issue (at least if the allowed range of the "talkspeed" variable for the given game is known). But I advise caution against trying to also rescale the talkspeed. I.e. trying to force the subtitle "speed" to be in the range 0 to 255 for all games -- I think doing that will cause a lot of pain, conversion losses, and nasty detail problems. I'd advice against it. Instead, do as Eugene suggested, and specifc the allowed range for that slider in the "game GUI features" settings.
Lastly, about the subtitle speed "slider" that appears in SCUMM when you press + and -: This emulates an engine of the original interpreter, and I absolutely want to keep it. Pressing +/- to increase/decrease talk delays (or talk speed...) is very helpful feature, and using the GMM or main menu for this is very awkward. But I agree that the slider it shows should be consistent with the corresponding slider in the various options dialogs. That's a matter of adjusting the documentation of the +/- keys to clearly state whether they modify the talk *speed* or the talk *delay*.
comment:6 by , 15 years ago
My request was indeed what you summarise in 1). But the second point is also valid imho. I think whatever the game use internally the GUI should always ask the same (i.e. always subtitle speed or always subtitle delay) when using the ScummVM GUI. In the game, when using the original game GUI it might be different (you will not change that anyway) and this is not an issue. As for the options file and the internal ScummVM structure/classes, I don't care what they store. If some games/engines store a delay and other a speed that's not a problem as long as in the GUI they all use the same.
Concerning the different scales I don't think this is a big problem. It would be good to have the same scale in the GUI for all the games, but anyway I think most users don't look at the numerical value but only look at the position of the slider.
comment:7 by , 7 years ago
| Component: | → GUI |
|---|
While adding extra info for the volume slider is IMO unnecessary (anyone can understand that 0 means "mute" and 256 means "loud"), I agree that the subtitle speed slider is totally confusing for two reasons:
1. There are actually two subtitle speed controls with different value scales: one in the launcher menu and another one in the game menu.
2. IIRC, the way the speed control works has been inverted then reverted not long ago. I'm not even sure how things are supposed to work: is 1 > 2 or the other way around?
Anyway, I seem to recall that there's already a feature request (or maybe a bug report) about this subject.