Hi, > On Tue, Aug 06, 2002 at 10:20:10PM +0200, Lars Skovlund wrote: > > Obtaining the game ID would be nearly useless for this purpose, since a > > game may have been re-released with a different interpreter. As for CRC32, > > The game ID is useless. But CRC-32ing resource.00[01] sounds like the > ideal way of distinguishing stuff. If the game were to be re-released > with a different interpreter, the resource files will also change -- > otherwise, there's no practical difference between the two interpreter > versions as far as the game is concerned.
I believe the problem wrt this approach Lars meant was that it would require all games to be listed with full CRC, rather than allowing an "educated guess" based on an interpreter version, binary file type etc.; also, from a more mathematical point of view, it might require more redundant information to be stored, although this is probably a rather academic argument, considering the scope we're traveling in. [...] > The various subsystems will still have to care about all of the little > quirks of each interpreter version, so you won't be saving any > complexity there; you'll only be changing the "if (sci_version < > 1.001.210) then do Y else do Z" call to "if (FLAG) then do Y else do Z". > > Now IMO that's a good thing; it would be very nice to have the various > versions nicely defined in one place. Agreed (note that we at least have preprocessor "constants" instead of literal numbers ATM). This second part of Lars' proposal-- using flags as predicates instead of version number checks-- unconditionaly makes more sense than what we're doing ATM, so let's consider that change "official". I'll add it to the TODO list. > ...but is it worth the effort of building a generic versioning/behaivor > system with its own runtime-dynamically-parsed config file? The set of > SCI games (or rather, interpreters) is quite finite, and will not be > growing. Your solution has the merit of being simpler and sufficient. > I mean, this sounds awfully complicated, and my allergy-ridden brain > just can't come up with a reason why it all can't be done in a header > file. Especially that once the mappings are written, they won't ever > change. unless we discover a new quirk. Which would almost certianly > necessitate other source changes to compensate. While that's true, more compact descriptions would allow us to understand the issues related to this much better. The problem I personally see wrt the use of an implementation of a logic language is solely the overhead it imposes; I don't think making the FreeSCI runtime system (as opposed to an optional debugger) depend on too many features is a good idea-- particularly when looking at ports to more lower-end systems, which are slowly getting into our reach. This is also why I'm no longer enthusiastic about force-including the proposed new debug interpreter (again, as opposed to making it a debug feature); this might also justify ultimately removing the widget system we are currently using in favour of letting Sierra SCI handle many of the problems our system tries to solve, but not quite yet (it's very helpful when debugging, after all...) An alternative would be to generate plain C code from more expressive patterns, thus removing the need for an interpreter; this would allow sophistication at a comparatively small price [we'd still have to get all the information the decision mechanism needs, of course]. llap, Christoph
