[Scummvm-devel] SCI versions...

Filippos Karapetis philipk79 at hotmail.com
Thu May 14 16:30:56 CEST 2009


> > 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 :)


(note: I'm only commenting on the parts of the e-mail from Lars found
inside Max's reply, as the original mail from Lars was not sent to -devel).

Well, the way that SCI versions are implemented, there are certain games
which don't work with the detected SCI version, which kind of defeats the
whole purpose of relying on the interpreter version in the first place.

An example is Conquests of Camelot (Amiga), where the detected version is
1.002.030, but it's actually version 0.000.685. Same goes for Longbow:
detected version is 1.005.001, with the actual version being 1.000.510.
Then, there are the weird version numbers for KQ1 (S.old.010), Eco Quest
(1.ECO.013), SQ4 (1.SQ4.057), QFG2 (L.rry.083), Pharkas (l.cfs.081), where
we actually guess what the SCI version should be (and we don't know for
some cases, e.g. Pharkas).

As you can see, the current engine version scheme is problematic, and it
will get more complicated while support for new games is added in. Plus, there
are features which existed only in certain games, e.g. the way that windows
are handled in PQ3.

Also, we found a different behavior in kSetCursor() in KQ5 CD and EcoQuest 1,
(which use multicolored mouse pointers) which is how it works in SCI1.1 games.
This behavior cannot really be explained from the SCI version: KQ5 CD is version
1.000.784, EcoQuest 1 version 1.ECO.013. We can't assume that EcoQuest is
version 1.000.013, because SQ4 floppy, having versions like 1.000.753 and
1.SQ4.030, is newer than EcoQuest 1 (but in fact it's not).

Regarding the problem with the SCI1.1 games using SCI1 data files: there are
ways to solve that, some of which have been mentioned already (game flags
or relying on certain kind of game data being available).

All in all, it's better to rely on the game data files themselves for the actual
version detection, rather than on interpreter versions which may or may not
work for all the versions of a specific game.

Regards
Filippos

_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090514/eaa4d630/attachment.html>


More information about the Scummvm-devel mailing list