[Scummvm-devel] FreeSCI integration

Eugene Sandulenko sev at scummvm.org
Fri Feb 13 11:29:45 CET 2009


Hi Team,

In order not to clutter That Thread(TM), I will write the history of
FreeSCI merge separately in this e-mail.

As you all know, we were trying to talk to FreeSCI folks for a quite
time now. Our main reasons for that were that the project seems to be
in all-time dormant state, and that some of our folks were interested
in the development.

Of course, you all, or at least every major team member were aware of
that as I personally spoke with every one of you.

In short. We wanted to merge in FreeSCI for couple of years now.

Thus, there were certain reasons why it could not happen at the time.
One main thing is difference in RE approaches. FreeSCI folks used a
Chinese Wall approach, that is: one person performs the disassembly
and writes specs, and completely different one writes the code. I
consider this as one of the reasons of slow(er) development.

Another important reason was that certain FreeSCI team members, who,
being accomodated in USA had some concerns with our RE approaches when
we use the disassembly more directly.

This was on and off, there were many discussions in the past. Finally
we managed to show FreeSCI folks true benefits of at least using
OSystem, and jvprat started to work on it, later GSoC task was born.
FreeSCI team really saw the benefits of using OSystem, as it would
off-load burden of supporting many platforms. Also we cover some of
the features such as enhanced sound playback or gfx scalers. All of
that was a big plus for everyone.

>From the other hand, being compatible in ScummVM infrastructure meant
moving at least some part of code to C++, and making everything
C++-compatible. That was the GSoC task to do it.

In the meantime, FreeSCI team was a bit worried of the issue. Little
statistics: ScummVM is 50 times more popular than FreeSCI in Ubuntu
popcon.Though that's of course, is not an true reference-quality
indication, you get the idea. Besides portability and low resources
they lacked a good PR. The absence of PR was so big, that even me, the
one, who closely watches their development was not aware that they
have support for SCI1 engine.

Next thing which happened is that SCI1 engine. A dirty work of one man
with all IDA-related comments scattered across the code. Still, after
several months of the guy's effort (Greg Fieger that is), we got the
engine which worked like a charm in most cases.

Thus, it was the last drop to FreeSCI team. They were forced to talk
about it, raising questions of doubled effort and overall project
pace. We took part in it, as they're the only guys on the planet who
know SCI the best and because we were always concerned about SCI
development.

Now the main concern was that which codebase to work on. They had an
impression that we prefer to use that SCI1 engine code and work from
that, however that was not the case. We wanted to use it as a last
resort, as the merge seemed impossible. Thus, this was quickly
clarified, that we are all for using FreeSCI code as a basement and
continue development from that.

Let me roll back a bit. SCI1 engine arrived quite some time ago, in
April 2008, still since that was a bit controversal topic, I kept it
silent to general public. I did not want to piss off the FreeSCI
developers until we see that the code is truly good and that I will be
sure that the development will continue. I spoke with some of the guys
who in the past expressed their desire to work on SCI engine, and some
of them started to look into it in our private repo.

Also during the GSoC code fest Max, Joost and me (mainly Max)
performed a bit of work on SCI1 engine, bringing it to more usable
state, mainly by reusing parts of FreeSCI code directly. It let us see
wider number of games playable just in several hours of work.

So, when FreeSCI guys renewed their talks about the possible merge, I
stopped development of SCI1 engine, informing every one who was
working on it, and pointing them to the #freesci channel.

FreeSCI guys had some a bit heated discussions among themselves,
leading to the current state when Cristoph is refusing to work on the
merged engine at least for the time being. The main concerns are the
same, RE approach. I am yet to describe our approaches in a more
formal way, this will help us to show the world our cleanness in the
sense of not breaking the laws, but I have to wait until some very
important issues will develop a bit more.

Last week GSoC FreeSCI task was finally merged into FreeSCI darcs
tree, and then the work started to slow down again. Max raised this
question in freesci-develop mailing list, and the folks gave us a
green light for the immediate merge.

Now (if you read till this place) let me explain why I am writing this
letter so "late" as some folks stated.

I was going to announce it, and do it beforehand (GOG.com affiliation
tought me 10-th time). But I needed to keep in mind several important
factors (in assorted order):
 * Ongoing work on release. I don't want to suck up resources.
   People keep fixing bugs in Tinsel instead of other engines
   to my disappointment (not that that is too bad, mind you)
 * Sensitivity of the issue, esp. towards discussions in the past
 * Technical problems yet to resolve (darcs -> svn conversion)
 * I had an impression that there will be NO questions anyway
   as everyone in the team always welcomed the idea.

Now I see that some folks put some other folks in a quite heated
discussion on IRC. Moreover I was a bit disappointed to see some folks
who were _aware_ of the issues stating the opposite. Not nice. I
completely admit that it was my fault to not talking more, but please,
bear with me.

Now I have several merge-related questions, but I will address them in
a separate letter.


Eugene




More information about the Scummvm-devel mailing list