[Scummvm-devel] SCI versions...

[Filippos Karapetis]

> CC: scummvm-devel at lists.sourceforge.net
> From: max at quendi.de
> To: philipk79 at hotmail.com
> Subject: Re: [Scummvm-devel] SCI versions...
> Date: Thu, 14 May 2009 13:31:27 +0200
> 
> Hi Filippos!
> 
> 
> First off, I really appreciate you are (re)writing the code for  
> detection and representing SCI versions and game features. This will  
> enable us to some important improvements later on.
> 

Thanks :)

> However, I think such a detection should not be performed after we  
> instantiated the game; it really should be part of the detection  
> process (resp. the fallback detection). This will allow us later on to  
> use different Engine subclasses for different major SCI versions, if  
> we desire so. The earlier the code "knows" the exact SCI version  
> during runtime, the earlier it can make appropriate choices at various  
> points (e.g. regarding which resource manager class to instantiate ;).
> 

Agreed

> 
> > So, each game entry would only have information concerning if the  
> > version should be autodetected or not, along with version flags.  
> > Some examples:
> > KQ5 floppy: SCI_VERSION_AUTODETECT
> > KQ5 CD: SCI_VERSION_AUTODETECT + GF_LOFSABSOLUTE + GF_LATESCI1
> 
> We could do that, but what do we gain by that? Each entry corresponds  
> to one precise game version anyway; having that version encoded  
> precisely into the detection entry is helpful: When I get a report  
> about an issue with a certain game, I can use the MD5 to find out what  
> version it is with a glance. It also helps us to maintain an accurate  
> overview of which versions are used in which games/variants.

Yes, but the problem here is that some version checks are arbitrary, and some versions
have been changed to account for these checks. I agree that the version should
be included in the detection entries, but the fact that these versions are then changed
so that the games work is a bit problematic...

> One note on this: At least for SCUMM, we also "detect" many game  
> feature flags based on the version, but not all, because in a few  
> cases, SCUMM was not developed linearly, so it's impossible to detect  
> all features just from the versions. This is not a big deal, though:  
> For SCUMM, we just allow specifying feature flags in the detection  
> entry, and any additional flags that are auto-detected are ORed with  
> the preset.

Indeed, I noticed that, and I did something similar in SCI.

> 
> > In my opinion, this scheme looks to be much easier than trying to  
> > see which SCI interpreter version works in each game...
> 
> I am not sure what you mean with this last remark? If we include the  
> SCI interpreter version along with the text about "unknown game  
> version, please report these MD5s, yadda yadd", this will be trivial  
> to do, no?

Well, the SCI interpreter version can be reported, yes. The problem is that
some version entries have been changed to make the games playable, which is
wrong. It would be nice to just rely on the major SCI version (e.g. SCI0, SCI1
and so on) and not on the minor ones, but rather use feature flags for these.
This does look better than trying to see which version works and which doesn't
for each game.

Regards
Filippos


_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090514/3cfa615f/attachment.html>