[Scummvm-devel] SCI versions...

Max Horn max at quendi.de
Thu May 14 15:58:55 CEST 2009


Am 14.05.2009 um 14:48 schrieb Lars Skovlund:

> On Wed, May 13, 2009 at 08:49:27AM +0000, Filippos Karapetis wrote:
>>
>> Hi there
>>
>> I was looking at the different SCI versions, and then I
>> had this weird idea. The resource manager already has a set of SCI
>> versions, and it can (in most cases) detect the SCI generation of the
>> game reliably (there are exceptions, like Jones and LSL6, but it most
>> cases it's reliable). Could we base the SCI generation check (i.e.
>> SCI0, SCI1 etc) on the resource manager's findings?
>
> I'm not sure I understand exactly what you want to do. But there are
> at least some games (PQ1/VGA, the Crazy Nick's series, perhaps others)
> whose resource files are SCI1 (using the old compression routines
> etc.) but whose interpreters are SCI1.1 (with the distinction between
> heap and script resources being the most important issue here). If I
> understand your intention correctly, these games would fail to work
> with such a solution. Of course, we could add another version number
> to the resource version enum... but then it really ceases to be about
> resources and more like a more comprehensive kind of version enum. Or
> make it a game flag, or deduce it from the existence of heap
> resources...

In SCUMM, the resource format is "almost" implied by the major SCUMM  
version, except for v3 games, where we have both "unblocked" games  
(using more or less the same format as v2 games), and blocked ones  
(using a format closer to what is used in later versions of SCUMM).  
So, what we do there is, we derive the resource format from one game  
flag and the major SCUMM version.

For SCI, that would mean adding a GF_USE_SCI1_RESOURCE_FORMAT. Of  
course if there are more instances where the SCI version does not  
imply the  resource format uniquely, we could indeed use a different  
approach. Like keeping separate "resource format" and "SCI version"  
fields.

The fallback detector would then start by detecting the resource  
format only; maybe also trying to detect the SCI version from the  
executable. Based on that, either "guess" a game (could also take  
filenames into account), or just use this information to print a  
slightly augmented detector error message: "Game was not recognized,  
MD5s are ..., SCI resource format seems to be XYZ, please report this".



> IMO it is neater to have to know that, for example, a game is newer
> than time t, than knowing it needs feature GF_LOFSABSOLUTE (which
> every game newer than time t needs). Of course there are cases of
> backported features, where such a system breaks down.

If you mean with that: "Let's not preset all Game Feature flags in the  
detection table, but rather compute the relevant flags during run-time  
based on the SCI version in the detection entry plus a list of  
exceptions": Sure, can do that, we do something like that in SCUMM.

This should be confined to the detection code, however. The rest of  
the code should IMO try to to use feature flags whenever possible, not  
any versions, unless in special cases where it makes sense, i.e., when  
there are clear & major & unique differences between those major  
versions. E.g. in SCUMM, we use the major SCUM version to decide which  
opcode set to use and (together with certain feature flags, as  
mentioned above) which resource format to expect. (Admittedly the  
SCUMM engine is not always 100% clean in this regard either :)



Cheers,
Max




More information about the Scummvm-devel mailing list