Hi,
> > > 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.
That's a good point. We won't neccessarily have the interpreter binary
avialable, though (at least we shouldn't require it), which does give a point
in favour of a more expressive solution, though.
> > 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, ...}
That, too. In this particular example, we have a particularly tight coupling
between the CRC and the resulting flags, too; adding new flags would be
tiresome and error-prone.
> > > ...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)
Yes.
>, 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.
Well, users aren't going to change the mappings too often, unless they're
investigating certain kinds of problems-- which would be covered by allowing
them to manually set the version flags on a game-by-game basis.
> 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.
I like that idea (see above), but I still don't think we need to set
defaults from an interpreter.
> > 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.
That's what I wanted to suggest in my last mail (but I may have failed due
to most of what remains of my brain being on vacation, as indicated on IRC).
Compiling to C should give us everything we need with minimal overhead while
still maintaining all the advantages you outlined.
> > [...] 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?
Not quite the old system, but, rather the new one minus widgets (which
would still include dirty rectangle management).
> I remember
> that you were quite enthusiastic about the new gfx subsystem back
> then.
I still like it; in particular, it's extremely helpful for debugging.
> Granted, the new one has a few inherent problems (the computer
> screen in PQ2, for instance) which require extra logic to catch.
But we can catch most of them with logic. However, there are some
problems, like massive amounts of dropped dynviews (hoyle) or overlapping
widgets (HQ1 char generator) which cannot be dealt with without arguing
about the pixels overdrawn by applying a certain image (the PQ2 problem
might be different, though); we'd have to provide (or build) tables
to allow the "is-covered-by" relation for images to work better.
Also, it still does many malloc()/free()s, but we should be able to
take care of that.
Well, in summary, I'm not changing FreeSCI to go back to the old system
today, and it won't be the first thing I do tomorrow either. We
shouldn't rule out this option, but, when thinking about this
a bit more, I believe I was a bit too much in favour of going back
to it than adequate in yesterday's mail; sorry about that.
llap,
Christoph
----- End forwarded message -----
