<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> > IMO it is neater to have to know that, for example, a game is newer<br>> > than time t, than knowing it needs feature GF_LOFSABSOLUTE (which<br>> > every game newer than time t needs). Of course there are cases of<br>> > backported features, where such a system breaks down.<br>> <br>> If you mean with that: "Let's not preset all Game Feature flags in the <br>> detection table, but rather compute the relevant flags during run-time <br>> based on the SCI version in the detection entry plus a list of <br>> exceptions": Sure, can do that, we do something like that in SCUMM.<br>> <br>> This should be confined to the detection code, however. The rest of <br>> the code should IMO try to to use feature flags whenever possible, not <br>> any versions, unless in special cases where it makes sense, i.e., when <br>> there are clear & major & unique differences between those major <br>> versions. E.g. in SCUMM, we use the major SCUM version to decide which <br>> opcode set to use and (together with certain feature flags, as <br>> mentioned above) which resource format to expect. (Admittedly the <br>> SCUMM engine is not always 100% clean in this regard either :)<br><br><br>(note: I'm only commenting on the parts of the e-mail from Lars found<br>inside Max's reply, as the original mail from Lars was not sent to -devel).<br><br>Well, the way that SCI versions are implemented, there are certain games<br>which don't work with the detected SCI version, which kind of defeats the<br>whole purpose of relying on the interpreter version in the first place.<br><br>An example is Conquests of Camelot (Amiga), where the detected version is<br>1.002.030, but it's actually version 0.000.685. Same goes for Longbow:<br>detected version is 1.005.001, with the actual version being 1.000.510.<br>Then, there are the weird version numbers for KQ1 (S.old.010), Eco Quest<br>(1.ECO.013), SQ4 (1.SQ4.057), QFG2 (L.rry.083), Pharkas (l.cfs.081), where<br>we actually guess what the SCI version should be (and we don't know for<br>some cases, e.g. Pharkas).<br><br>As you can see, the current engine version scheme is problematic, and it<br>will get more complicated while support for new games is added in. Plus, there<br>are features which existed only in certain games, e.g. the way that windows<br>are handled in PQ3.<br><br>Also, we found a different behavior in kSetCursor() in KQ5 CD and EcoQuest 1,<br>(which use multicolored mouse pointers) which is how it works in SCI1.1 games.<br>This behavior cannot really be explained from the SCI version: KQ5 CD is version<br>1.000.784, EcoQuest 1 version 1.ECO.013. We can't assume that EcoQuest is<br>version 1.000.013, because SQ4 floppy, having versions like 1.000.753 and<br>1.SQ4.030, is newer than EcoQuest 1 (but in fact it's not).<br><br>Regarding the problem with the SCI1.1 games using SCI1 data files: there are<br>ways to solve that, some of which have been mentioned already (game flags<br>or relying on certain kind of game data being available).<br><br>All in all, it's better to rely on the game data files themselves for the actual<br>version detection, rather than on interpreter versions which may or may not<br>work for all the versions of a specific game.<br><br>Regards<br>Filippos<br><br /><hr />Hotmail® has ever-growing storage! Don’t worry about storage limits. <a href='http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009' target='_new'>Check it out.</a></body>
</html>