<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br><br>> CC: scummvm-devel@lists.sourceforge.net<br>> From: max@quendi.de<br>> To: philipk79@hotmail.com<br>> Subject: Re: [Scummvm-devel] SCI versions...<br>> Date: Thu, 14 May 2009 13:31:27 +0200<br>> <br>> Hi Filippos!<br>> <br>> <br>> First off, I really appreciate you are (re)writing the code for <br>> detection and representing SCI versions and game features. This will <br>> enable us to some important improvements later on.<br>> <br><br>Thanks :)<br><br>> However, I think such a detection should not be performed after we <br>> instantiated the game; it really should be part of the detection <br>> process (resp. the fallback detection). This will allow us later on to <br>> use different Engine subclasses for different major SCI versions, if <br>> we desire so. The earlier the code "knows" the exact SCI version <br>> during runtime, the earlier it can make appropriate choices at various <br>> points (e.g. regarding which resource manager class to instantiate ;).<br>> <br><br>Agreed<br><br>> <br>> > So, each game entry would only have information concerning if the <br>> > version should be autodetected or not, along with version flags. <br>> > Some examples:<br>> > KQ5 floppy: SCI_VERSION_AUTODETECT<br>> > KQ5 CD: SCI_VERSION_AUTODETECT + GF_LOFSABSOLUTE + GF_LATESCI1<br>> <br>> We could do that, but what do we gain by that? Each entry corresponds <br>> to one precise game version anyway; having that version encoded <br>> precisely into the detection entry is helpful: When I get a report <br>> about an issue with a certain game, I can use the MD5 to find out what <br>> version it is with a glance. It also helps us to maintain an accurate <br>> overview of which versions are used in which games/variants.<br><br>Yes, but the problem here is that some version checks are arbitrary, and some versions<br>have been changed to account for these checks. I agree that the version should<br>be included in the detection entries, but the fact that these versions are then changed<br>so that the games work is a bit problematic...<br><br>> One note on this: At least for SCUMM, we also "detect" many game <br>> feature flags based on the version, but not all, because in a few <br>> cases, SCUMM was not developed linearly, so it's impossible to detect <br>> all features just from the versions. This is not a big deal, though: <br>> For SCUMM, we just allow specifying feature flags in the detection <br>> entry, and any additional flags that are auto-detected are ORed with <br>> the preset.<br><br>Indeed, I noticed that, and I did something similar in SCI.<br><br>> <br>> > In my opinion, this scheme looks to be much easier than trying to <br>> > see which SCI interpreter version works in each game...<br>> <br>> I am not sure what you mean with this last remark? If we include the <br>> SCI interpreter version along with the text about "unknown game <br>> version, please report these MD5s, yadda yadd", this will be trivial <br>> to do, no?<br><br>Well, the SCI interpreter version can be reported, yes. The problem is that<br>some version entries have been changed to make the games playable, which is<br>wrong. It would be nice to just rely on the major SCI version (e.g. SCI0, SCI1<br>and so on) and not on the minor ones, but rather use feature flags for these.<br>This does look better than trying to see which version works and which doesn't<br>for each game.<br><br>Regards<br>Filippos<br><br><br /><hr />Windows Live™: Keep your life in sync. <a href='http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009' target='_new'>Check it out.</a></body>
</html>