Re: [freesci-develop] Debian

[Christoph Reichenbach]

Hi,

sorry that this reply took so long...

> You might have heard that Debian is to release a new stable version
> (named Sarge) on december first.

That was the first time I heard of that (being an addicted user of
the unstable branch, I don't care too much about this stable stuff
anyway, though ;-)

> Currently, Sarge contains freesci
> 0.3.4a.

That's the most recent version I'd consider to be reasonably
stable right now.

> I was wondering wether it might be a good idea to include a
> glutton version.  Is the glutton stable enough already to run most games
> also supported by 0.3.4a?

No. I wouldn't even consider it for sid at the moment.

I'd love to see a new stable release, but we don't really have anything
to show for a 0.3.5 at the moment. I don't know if this is going to change
until december; I don't see anyone seriously working on this branch now,
though, and I don't think anyone wants to commit to anything ATM.


As a reminder for everyone on the list, here's the TODO:
(1) update calle, callk docs
(2) auto-detect version number from SCIV.EXE or similar
(3) operations.c: Add full state->visible_map support (to allow the
    priority or control map to act as the visible map)
(4) optimise pic drawing
(5) Add graphical game selection screen

I believe I have a pretty good idea of what these things entail. (1)
can't be finished until the doc transition to LaTeX is complete, of
course, but if anyone wants to know any gory details, feel free to
ask me.
  Here are some rough estimates of how long a semi-skilled programmer
would probably need for that:

(1) (10 minutes), assuming that the programmer knows LaTeX and knows
  where the VM code is.
(2) (45 minutes), this includes testing and fallback in case the number
  can't be extracted
(3) (8h) Assuming that the programmer has some understanding of the
  graphics subsystem and doesn't care about performance too much (this
  is really just support for an SCI debug feature anyway).
(4) (40h) This is pretty involved. While there's a nice optimised
  algorithm Claudio and I once worked out, it wouldn't be trivial to
  implement, although the existing algorithm could be used to perform
  regression testing rather neatly.
(5) (3h) This includes learning our widget layer. However, for a
  /graphical/ game selection screen, it might be nice to have icons
  or images associated with each game, that might take more time.


Other ideas:
- 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

-- Christoph