Re: [freesci-develop] Proposal for new direction of the project

[Lars Skovlund]

On Mon, Nov 06, 2006 at 08:53:40AM +0000, Jordi Vilalta wrote:

> 2006/11/5, Christoph Reichenbach:
> >  Simulataneously, FreeSCI would lose some of its benefits, such as scaled
> >background images and pre-scaled views.  I see the benefit mostly for SCI1
> >games, for which ScummVM's palette emulation would be very helpful.  In
> >general, I see ScummVM's gfx subsystem as a possible graphics driver for
> >FreeSCI.  I'm less clear on sound and configuration, the other areas in 
> >which
> >merging would be possible.
> 
> At the moment we haven't worked with any of the two projects so we
> don't know these details. This is one of the reasons why we want to do
> it in collaboration with the FreeSCI team, so that at least you could
> supervise our work and guide us (in the end, the idea is to move your
> development there, so you'll want to get used to the new code too).
> We'll need to learn over the time. We see it as a mid/long-term
> project, we don't want to do it fast while breaking your work.

The current graphics subsystem is over-engineered in my
opinion. Getting rid of it would make it easier for others to work on
the code, as Christoph is the only person who understands it
fully. However, it would be a regression to the pre-0.3.0 days. Also,
the current system allows us to create debugging aids like Walter did
with the pathfinding code. This would be more difficult with the
original system (which was completely bitmap-based, like ScummVM).

> >> This code move could also benefit of adding new features. For example,
> >> we've done a small look at the SCI Studio code and it seems like there
> >> are some parts that support newer SCI versions than FreeSCI does. We
> >> think it could be a great opportunity to integrate such code into
> >> FreeSCI (or directly into the new ScummVM SCI engine).
> >
> >  Before you incorporate any code into FreeSCI, please make sure that it
> >wasn't derived from illegal reverse engineering.  FreeSCI is a clean-room
> >re-implementation of SCI.
> 
> Oops, it's a picky issue. As I understand it, clean-room means to
> implement it from documentation. I think most of the ScummVM engines
> were done by direct reverse-engineering (I may be wrong). Does it
> bother you if your "clean" code lives together with "dirty" one (the
> rest of the project)? Do you want to maintain this position or would
> you change your mind with the migration?

It could potentially put all of us in some very hot water. It is a
fact that the ScummVM team has received threats from LucasArts, and it
took quite a bit of negotiation to calm them down (I'm not sure what
happened exactly, you'd have to ask the ScummVM people about
that). Christoph would have to pull out of the project completely; as
he lives in the US currently, he would be quite vulnerable to lawsuits
and the like.

> >> Of course we don't want to tell you how to rule your own project, but
> >> we think it could be a good step, and we would help with the process.
> >
> >  It's ultimately Lars' call, him being the maintainer.
> 
> Waiting to hear from him :)

I'm against it. :)
Another thing is, if you look at the complexity of the engines
included in ScummVM, the only engine that seems to match SCI in
generality is SCUMM. Many of these engines contain code that is
specific to one or two games; there is almost none of that in FreeSCI.
So we are talking about quite different approaches to VM design. 

> Regards,
> 
> Jordi Vilalta

Lars