[Scummvm-devel] SCI versions...

[Max Horn]

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.


Am 13.05.2009 um 10:49 schrieb Filippos Karapetis:

> 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?

It would absolutely be possible and acceptable to switch detection  
from plain MD5 based to an approach based on data structures, such as  
of resource files. Note that this is what the SCUMM detector does:  
Even with all MD5s removed from the code, it correctly detects >90% of  
all SCUMM games, in particular many so far unknown game variants. Of  
course the AdvancedDetector can also do that using fallback detection  
code.


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 ;).


> 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.


> Plus, it could be possible to detect the flags themselves from the  
> detected version (e.g. SCI_VERSION_1_EARLY or SCI_VERSION_1_LATE),  
> so it might be possible to remove some version flags in the future  
> (like, for example, GF_LATESCI1).

That would be possible regardless of whether we auto-detect the  
version of hardcode the version in each detection entry, of course.

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.


> 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?



Cheers,
Max