[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm:[43846] scummvm/trunk

[Travis Howell]

Jordi Vilalta wrote:
> 2009/8/31 Eugene Sandulenko <sev at scummvm.org>:
>> On Mon, 31 Aug 2009 01:52:17 +0000
>> Kirben at users.sourceforge.net wrote:
>>> Log Message:
>>> -----------
>>> Revert revision 43845, to keep configure options for games and game
>>> engines clear and consistent.
>> Thank you, Kirben, because my eyebrow raised when I was reviewing
>> r43845 :)
> 
> The aim of revision 43845 was to easily disable the detection of all
> the unsupported games or versions of games of the enabled engines so
> we don't give false expectations to the users using final releases.

What false expectations? we list all supported games, and any 
limitations in the documentation.

> The set of supported games doesn't always match engines or subengines.
> Using the Groovie engine as an example, we have the detection entry
> for the Macintosh version of The 7th Guest which uses the first
> version of the engine but it isn't supported. Right now the whole
> version 2 is disabled, but someday some of its games will be supported
> while some of them still won't be.

We don't usually exclude games, based on platform alone, unless not 
possible to support at all. Since it can lead to false reports of 
unknown versions of those games.

> Another example: I read that the first releases enabling the SCI
> engine by default will just enable a selection of games considered
> stable enough for end users, even if other games using the same engine
> (or even later versions) are supported. In order not having to add
> lots of "#if 0" for each release I think a general flag to
> enable/disable unsupported games would be best.

It is far too early to be talking about what will be included in the 
first release, with SCI game engine enabled, since the SCI game engine 
is still disabled by default. What games are enabled for a final 
release, is decided early in the release cycle. With game detection 
entries commented out in the release branch, if games aren't in a 
supported state.

> Which is the preferred way to handle this? Renaming the groovie2 flag
> to groovie-unsupported? Adding a new option for each supported engine
> that contains unsupported games (groovie1-unsupported,
> groovie2-unsupported, ...)?

No, adding generic options like that, doesn't many any sense. It would 
only lead to more confusion about what exactly what games are been 
enabled and disabled.

The current options of configure to enable or disable games and game 
engines, make it clear what exactly is been enabled and disabled. And 
any future options for unsupported games, should be kept that way.