Basic differences to Sierra's SCI
Sierra's SCI engine, written back in the late 80s, was designed and built to be fast and efficient. Some evil compromises were made (especially in the animation cycle) that sacrificed cleanness for extra cycles. Also, it was designed to use only a very limited amount of memory, which led to more compromises.
The primary design goal of FreeSCI, on the other hand, was Portability. Written in the late 90s, memory constraints were practically nonexistant, since all game data could easily be stored in memory.[1] Thus, resource loading and hunk memory management is of no importance to FreeSCI. The kernel call "Load", which is used to load a resource to hunk space, simply returns the resource identifier of the resource it is supposed to load, as opposed to a pointer to a pointer to hunk memory.
Apart from that, FreeSCI simply abuses the fact that SCI was designed to be used by various different graphics adapters and sound devices. The graphics and sound commands each had to be interpreted by the currently active sound and graphics drivers, and FreeSCI does nothing more than to interpret them in its own way.
Of course, FreeSCI has to accomodate for versions differences between different SCI builds. These are generally minor issues (like the default alignment of text), but they have to be taken care of in one single program, as opposed to several builds as in the case of Sierra's SCI (some SCI games still ship with old versions of the interpreter, because they assume default values that were changed later on).
Finally, there is the built-in debugger. Sierra SCI used a quick and efficient design, while FreeSCI provides a Command-line interface to the debugger, and several additional commands.
Notes
- ↑ This is not true for the speech support some of the later SCI1 and SCI32/SCIWin come with, of course. At the time of this writing, SCI1 support is still non-existant, but later versions of FreeSCI will have to allow for dynamical loading of cdaudio resources.