[freesci-develop] Future work

[Christoph Reichenbach]

Pizza,

> > (2) auto-detect version number from SCIV.EXE or similar
> 
> Well, we do have this sorta in-place, but we use resource.00[01]
> instead, I believe.

Ah, that's something different. What you're talking about is using
checksums (or, rather, our very coarse approximation of the idea of
what a "checksum" is supposed to be) to distinguish game versions; this
idea, rather, is to string-detect the version stored within the original
SCI interpreter, if available-- that's a fast and seemingly reliable
way to get this number under the condition that this file is available.

Most importantly, this approach would support certain games even if
they were not stored within some built-in database.

>  We identify the game that way, and use the
> appropriate SCI revision. I don't recall if anyone came up with an
> example of any games shipped with identical resource file(s) but
> different interpreters..  (and if that's the case is there any reason to 
> not use the newest known interpreter?)

Good point, but we only compare a value derived from resource files with
another such value; we're not really comparing resource files. As such,
I'm somewhat less confident about this.

> > - backport 0.6 soundsystem as an option (!) once it's done
> > - backport 0.6 "per-resource palettes" stuff
> > - come up with a few nice-looking per-resource palette settings for
> >   a game or two
> 
> Personally, I really don't think backporting stuff is worth it, instead 
> the effort should go into fixing up the problems glutton has with SCI0 
> games.

While you have a point there, both backports would be fairly straight-
forward. However, Walter's recent fix to Win32 timing may turn out to make
the soundsubsystem backport largely unneccessary-- I'd still like to hear
back from the Win32 front first, though.

>  Certianly a showstopper of sorts is wider sound support, right?

For Glutton? Definitely. Here's a a rough overview of what's been going
on and what's missing:

The new sound subsystem now is based on an abstraction on sound called
/song iterators/. A song iterator is (roughly speaking) an abstract data
type with a 'clone' operation, and it encapsulates song state. We now use
two separate song iterators: One for finding song cues, and one for
actually producing sound output (for this, the iterator is configured for
the active driver's platflags and returns the next MIDI operation of rele-
vance, a delta time, or an end-of-track (or cues, but these can be dis-
regarded there). Song iterators also encapsulate PCM data, although they
don't really iterate over it at the moment.
  Song iterators are used by abstracted /song players/, of which the only
one in existence today is the /realtime player/; this particular player
tries to play ahead far enough to avoid audible latency. It makes use of
a /timer/ (currently we use sigalarm() in our only implementation, which
was sufficiently inaccurate to drive home the point about no longer
depending on an accurate timing mechanism), and a /sequencer/. The only
sequencers we have at the moment are a highly specialised OSS/OPL2 driver
and a more general MT-32 driver, for which there exists one /device/,
namely an ALSA MIDI driver (relying on ALSA timers, using the 0.9 API--
this should be as good as it gets for Linux-based MT-32 users).
  The most recent implementation on this field is the implementation of
a software mixer API and a default mixer implementation (with linear
interpolation) (which is, however, likely to be slower than the opti-
mised versions shipped in SDL etc.; still, it maintains our library and
platform independence on the architectural level). This is based on the
notion of polling; the mixer actually needs to be driven by a timer
(like the 'realtime' player).

Work to be done in this field includes, but is not limited to:
 - A configuration mechanism-- right now, we just pick the defaults
   everywhere. As there isn't much to pick, no one has complained
   so far ;-)
 - Forward-ports of our PCM drivers. I'm not sure how straight-
   forward this would be.
 - Extraction of timers provided by individual PCM subsystems: These
   are likely to be the most useful timers we're going to get; how-
   ever, as they're closely tied to individual PCM devices, this will
   require an extension to the PCM driver API to recover a /timer/ from
   them.
 - Timer extensions
   Timers must be able to call two objects now. I'm actually not sure
   if this requires a change in their API, or only in the way they are
   used internally by the sound kernel.
 - Software sequencers: Something which is both a sequencer and a /PCM
   feed/ (pollable stateful PCM mixer input thingy, or monad, if you're
   into that stuff). Note that indivudual sequencers have much in common,
   which should be exploited in a somewhat elegant fashion.
 - Testing and bugfixing: Shockingly enough, we may have to do that.

>  - Pizza [yeah, still alive. :)]

Great to hear back form you, by the way! :-)

(and sorry for abusing this as an opportunity to shout out the current
state of affairs to the rest of the world).

-- Christoph