Just to make this clear: I have no fundamental problem with adding a SCI engine to ScummVM. If somebody wants to start one from scratch, or if the FreeSCI team tells us to take over (*and* somebody spends the considerable effort to "port" it -- the current FreeSCI code doesn't even compile with a C++ compiler).
But: I do mind taking the FreeSCI code, GPL or not GPL, w/o the assent of the FreeSCI team. Partially because I know and like those guys, partially because it just doesn't feel "right", and partially because we'd have a hard time maintaining such a fork w/o the support of those people who know the code best, i.e. the FreeSCI staff.
FreeSCI in ScummVM
Moderator: ScummVM Team
Just to follow up on fingolfin's response here, which I appreciate: The current FreeSCI situation is that Christoph is working on his PhD - this is taking most of his time, and he has therefore ceded maintainership to me. I have historically had an analyst role in the project, only occasionally contributing code. This was a role I was very comfortable with. Unfortunately, it also means that there are parts of the FreeSCI design that I have only a passing acquaintance with; the game engine is where my most of my code is. Being in charge is therefore a huge task in itself. In that sense, merging FreeSCI with ScummVM might be a good thing. However, our approaches to reverse engineering are very different, and this might lead to conflicts, whether personal or concerning the code. From that perspective, a merger would not be a good idea.
For my part, I wish people around here would stop bitching about our rate of development and instead join the FreeSCI mailing list. Knowing that there is an interest in what you do is for me a large part of undertaking such a project, and being basically down to one coder at this point, I would really like some encouraging words once in a while. It has worked in the past
For my part, I wish people around here would stop bitching about our rate of development and instead join the FreeSCI mailing list. Knowing that there is an interest in what you do is for me a large part of undertaking such a project, and being basically down to one coder at this point, I would really like some encouraging words once in a while. It has worked in the past
well, I can imagine then that it's very hard to do anything if you are the only coder.. Is there any more info on the VGA SCI now (as Provinciano said on his website that he had a VGA version of SCI studio running or at least a decompiler)
The code he released was not of the last version of SCI Studio..
The code he released was not of the last version of SCI Studio..
I disagree with this. I worked on AGI after Sarien was merged with ScummVM. But then again, that's roughly the time I joined ScummVM, and AGI was a good starting point, as it's quite simple and compact. But as a rule of thumb, fingolfin is right: developers don't usually appear magicallyfingolfin wrote:Two reasons: The FreeSCI team is not in favor, and there is nothing to be gained, since what FreeSCI is lacking is active developers, and those won't magically appear when "merging" it in. No AGI developers magically popped up when we merged Sarien, either!
I did readed this from mailing lists and IRC logs...lskovlund wrote:However, our approaches to reverse engineering are very different, and this might lead to conflicts, whether personal or concerning the code. From that perspective, a merger would not be a good idea.
(b) dependencies matter: If FreeSCI was to depend exclusively on _clean_ ScummVM modules, then it _should_ be possible to avoid any legal and practical problems by forking off again and copying those clean modules. (Of course, I'm only using logic, as opposed to the letter of the law, to arrive at this conclusion.)
I own a 100% legal Larry collection for a magazine that has FreeSCI, DOSBOX and Sarien. I think Sierra Entertainment (owned by Vivendi) changed their corporate politics about this to a sane one, as you can see with the development of The Silver Lining.3:35:45 syke TMM: given that sierra forced several fan sites to take down community-created games and artwork, I don't think it makes sense to give them cannon fodder
FreeSCI has traditionally not only been re-implemented, but also re-engineered (things like sound iterators, widget subsystem, ...). The most recent example is the pathfinding code; the main obstacle here was a patent that Sierra had on their particular algorithm. Walter van Niftrik engineered a different approach as a university project last year. It was long overdue at that point. I note that iMuse is patented too.comp1 wrote:I'm intrigued by the differences in reverse engineering between SCUMMVM and FreeSCI. Any posts anywhere that contrast these differences?
Clean room reimplementation is all about creating code that in the abstract works like the original, but in the concrete does not. Because of the FreeSCI development model, I can confidently say that FreeSCI is like this. I am not totally convinced about this with ScummVM. Of course things get done faster if such concessions are made.
Sounds just like our SAGA engine code. It was based on Reinherit project started by Daniel Balsom. Later we obtained original code, but our engine is so much better structured. Several key technologies such as event queues make it more easy to work with and extend.lskovlund wrote: FreeSCI has traditionally not only been re-implemented, but also re-engineered (things like sound iterators, widget subsystem, ...). The most recent example is the pathfinding code
Eugene
Yeah, but SAGA was not clean room RE'd, which is the key difference here, from a legal point of view.
Of course, many of our engines underwent at least some "re-engineering" (to non-insiders, this is something very different from "reverse engineering", which often is abbreviated REing). E.g. some bits in the SCUMM code where re-engineered by me in the past.
Of course, many of our engines underwent at least some "re-engineering" (to non-insiders, this is something very different from "reverse engineering", which often is abbreviated REing). E.g. some bits in the SCUMM code where re-engineered by me in the past.