On Tue, 13 Aug 2002, Christoph Reichenbach wrote:
> 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.
There _is_ such a thing as interpreter bug fixes.
> 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.;
Don't forget clarity. If we were to make an attribute database and
hard-code it as we do today, we would get huge structures like:
{0xCAFEBABE, TRUE, FALSE, TRUE, TRUE, foo, bar, ...},
{0xDEADBEEF, FALSE, FALSE, FALSE, TRUE, quux, quux, ...}
This places huge demands for documentation on our shoulders (we don't like
that, do we? :), otherwise it would quickly become unmaintainable.
> > ...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.
Sufficient. Well, the CRC system in itself could be said to be sufficient,
but the current system (an associative array CRC => version number) does
not handle non-numerical version numbers (like the T.A series), and the
kind of string handling we would need to support it can't be done in C
macros. A config file can be changed without recompiles - as it is now,
even the slightest change in version logic (such as changing an SCI_FTU_
constant) requires a recompile. The attribute database might turn out to
be an advantage during debugging because we can toggle the various
attributes from within FreeSCI - there is already a 'set' command in
FreeSCI that has this purpose, but it isn't used in that context.
> 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.
Depending on the implementation, the file might only need to be parsed
once per session - or could even be compiled to some binary
representation, or even C. Alternatively, since the version
determination really only needs to be done once, the attribute database
could simply be added to the existing configuration file, and an
"installgame" application could be written to make the appropriate
entries. This application would then contain the logic language, and,
since it only needs to be run once (per update per game, in the worst
case), the overhead would be insignificant.
> [...] 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
I don't quite understand what you're getting at here. You want to get rid
of the new widget system and reinstate the old system? I remember
that you were quite enthusiastic about the new gfx subsystem back
then. Granted, the new one has a few inherent problems (the computer
screen in PQ2, for instance) which require extra logic to catch.
> llap,
> Christoph
Lars
