[Scummvm-devel] New GUI options were added to ScummVM. ATTN all engine devs.

[Max Horn]

Am 06.06.2009 um 21:02 schrieb Eugene Sandulenko:

> Hi Team,
>
> I recently added new feature to ScummVM GUI which I called Game GUI
> options. This was an old planned thing from me and I finally got my
> hands over the implementation.

Awesome work. As are the other changes, like that new "search" widget  
in the launcher :).

>
> In short, it is a 'guioptions=' key which is added on game detection,
> and it is a list of "no's" which is used to disable certain GUI  
> widgets
> which are not used by some particular game.
>
> Since it is number of 'NO's' and not 'DO's', it does not break all
> existing scummvm.ini files, which will make our users happy. As a
> consequence, in order to benefit from GUI options, a user should
> redetect all his game collection. Mass add could help with it (which
> was also improved, btw ;) ).

But people (e.g. me) will *hate* to redetect, as that would break  
existing target names. We really need an upgrade feature, which either  
scans through all target (or just a subset, like a single one), and  
updates them. While we are it, some users (e.g. me ;) might also like  
having the feature to update the game desc to to the latest ones (our  
current game desc strings are much more detailed. Of course, not  
everybody will want that, i.e., those people who customized their  
descs or are jus fond of them.

I propose we add an "--update-target-settings" command line option,  
which does that. And add ways in the GUI to trigger it: For once, if  
we start and notice that the gameoptions are missing (or that the .ini  
version is "too old"... we don't use that version yet, right? well,  
maybe we should); in that case, we should ask the user "do you want me  
to upgrade your existing targets?". Or even better: Just do it  
automatically, and display a progress dialog which says "Now upgrading  
your game targets..." and which auto-closes once done.


If this sounds OK to people, I'll work on it.


>
> The currently implemented flags are (common/util.h & .cpp):
>
>  GUIO_NOSUBTITLES  -- disables all subtitle controls
>  GUIO_NOMUSIC  -- disables music volume controls
>  GUIO_NOSPEECH -- disables speech volume controls
>  GUIO_NOSFX  -- disables SFX volume controls
>  GUIO_NOMIDI  -- disables whole MIDI tab
>  GUIO_NOLAUNCHLOAD -- disable Load button

[...]

>  detection tables and fix wrong entries.
>
> Some thoughts about potential flags and some rants on the
> implementation.
>
> I think that NOMT32 and NOADLIB could make sense since there are
> number of controls which could look weird to the end user who do not
> use, esp. Roland MT-32 device.

Aye. Actually, I think somewhat more fine grained information would be  
even better: For each game, the supported music driver "kinds" should  
be listed somehow (maybe as separate gui options, or maybe in a way  
that does not yet exist; this is more or less part of the "revamp the  
music driver API" project, I guess). So that for you are only shown  
those drivers that make sense for the given game. Types would  
include:  pc speaker, pcjr, adlib, FM-TOWNS, MIDI/GM, MIDI/MT32, etc.

[...]

>
> Also currently there is no way to update already set GUI options,  
> other
> that redetecting the game over again. This is a flaw in our current
> design, but I think it is quite possible with a bit of work to have a
> method like "redetectGame(id)" in engine implemented. This will let us
> to do more flexible things with our configuration file when engines
> evolve.

I already talked about this above. I think this can be done without  
*any* extra code in the engines. Basically, you just grab an existing  
target, and point the right (Meta)Engine at the directory specified in  
the target, and ask it to detect. Then, compare it to the existing  
target. If it seems to be "compatible", update the game options.


>
> Also since there is no way to update the flags, the list is turned  
> into
> list of 'NO's,' whereas more natural would be to have it as list of
> 'DO's' as the games tend to use narrow subset of options.

Makes sense, I guess.

>
> Additionally, if a developer mistakenly puts some NO in GUI option,
> there is no current way to remove it, only by forcing the user to
> redetect the game. In my opinion this is really nasty and
> annoying drawback of our current architecture.

Another reason to have an "auto-update" mode. But it will never be  
perfect, of course -- a user could just manually mess with those  
options. As long as there is an easy way to reset them, though, that  
won't be an issue.



Cheers,
Max