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

[Christoph Reichenbach]

Lars,

On Mon, Nov 06, 2006 at 07:14:02PM +0100, Lars Skovlund wrote:
> > 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.

  There is something to be said for that 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.

  I would support getting rid of (most of) the widget layer (excluding ports
and dirty rectangle tracking).  While this would make debugging a bit more
difficult, the primary justification for the widget layer was serialisation,
which I would argue we can do differently by limiting our savegame scope to
the same situations supported by Sierra SCI.

> However, it would be a regression to the pre-0.3.0 days.

  Depends on how much you rip out.

> 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).

  In general, if we retain the operational gfx layer (which is reasonably
well-tested now, though there certainly are reasonable API improvements that
can be made, also to the gfx drivers) we shouldn't have too hard a time
supporting ``still-screen'' debugging aids, which should be enough in most
cases.

  (Mind you:  Arguably, there is still over-engineering even in the
operational gfx layer; it wasn't exactly developed with agile methodologies in
mind.  Still, it seems to work, it doesn't get in the way, and it occasionally
enables us to do some graphical hackery such as the per-resource palettes
stuff, so I see no reason to eliminate it.)

> > 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.

  The same would apply to Matt, of course.  (It will take me another 1.5 years
or so until I can get out of here, I'm afraid, but I don't think Matt has any
such plans.)  The main question is what the ScummVM team has done wrt ensuring
legality, as I outlined in my other mail.


-- Christoph