Difference between revisions of "SCI/Roadmap"

From ScummVM :: Wiki
< SCI
Jump to navigation Jump to search
(Initial roadmap proposal)
 
m (linkify lars)
Line 15: Line 15:
 
* Keeping Glutton around
 
* Keeping Glutton around
  
Glutton currently has problems with strings in some games; a reimplementation is underway (by lskovlun) to rectify this. Some may think that this is a good reason to keep the VM as close to Sierra's as possible (see the recent reimplementation); but I believe that the Glutton VM (if the string fixes turn out to work) would work equally well with SCI1.1 and earlier and SCI32, whereas the reimplementation would have to do something else for SCI32.
+
Glutton currently has problems with strings in some games; a reimplementation is underway (by [[User:Lskovlun|lskovlun]]) to rectify this. Some may think that this is a good reason to keep the VM as close to Sierra's as possible (see the recent reimplementation); but I believe that the Glutton VM (if the string fixes turn out to work) would work equally well with SCI1.1 and earlier and SCI32, whereas the reimplementation would have to do something else for SCI32.
  
 
* What is this thing about SCI32?
 
* What is this thing about SCI32?
  
 
Whereas SCI1.1 and earlier have a 64 kilobyte heap space which is addressable via pointers, SCI32 uses memory handles exclusively. That means that all the string handling functions have been replaced by a single String() call, array handling (which used to be primitives) is now a kernel call Array(), etc. '''Direct pointer addressing is no longer possible!'''
 
Whereas SCI1.1 and earlier have a 64 kilobyte heap space which is addressable via pointers, SCI32 uses memory handles exclusively. That means that all the string handling functions have been replaced by a single String() call, array handling (which used to be primitives) is now a kernel call Array(), etc. '''Direct pointer addressing is no longer possible!'''

Revision as of 22:28, 18 January 2009

This is an incomplete roadmap of what I'd like to see in FreeSCI in the near future:

  • Complete objectification

Syke (i.e. Matt Hargett) has a point about top-down work, of course ... but I am thinking that Glutton (the VM itself) should be converted last. I would rather see things like the resource manager converted first (a bottom-up approach), with Glutton coming in last. If anything in Glutton should be objectified first, it would be the segment manager (which has no direct counterpart in Sierra SCI and is therefore already abstracted from the original semantics).

  • Non-reliance on the kernel table (vocab.999 / 999.voc)

This resource is notoriously unreliable, and should not be used. Instead, we should use the ScummVM autodetection mechanism to choose an appropriate built-in kernel table. The other vocabulary resources are generally reliable and should be used to the extent that it makes sense (vocab.997 / 997.voc -- the property name table -- is a good example while vocab.994 / 994.voc is not. The information in 994.voc was meant for a computing era when class information lookups were expensive; they aren't anymore, so using the plain 997.voc will do nicely - FreeSCI does this already, while the reimplemented SCI engine does not).

  • Removal of the graphics subsystem

The graphics subsystem is currently incompatible with much of the UI in SCI1 and later, and certain rooms in SCI0. It would be nice here to revert to a plain bitmap-based approach (like ScummVM). However, we want to keep the graphics subsystem around as it is well suited for SCI32; a battery of unit tests is desired to make sure that this remains possible.

  • Keeping Glutton around

Glutton currently has problems with strings in some games; a reimplementation is underway (by lskovlun) to rectify this. Some may think that this is a good reason to keep the VM as close to Sierra's as possible (see the recent reimplementation); but I believe that the Glutton VM (if the string fixes turn out to work) would work equally well with SCI1.1 and earlier and SCI32, whereas the reimplementation would have to do something else for SCI32.

  • What is this thing about SCI32?

Whereas SCI1.1 and earlier have a 64 kilobyte heap space which is addressable via pointers, SCI32 uses memory handles exclusively. That means that all the string handling functions have been replaced by a single String() call, array handling (which used to be primitives) is now a kernel call Array(), etc. Direct pointer addressing is no longer possible!