Difference between revisions of "SCI/Roadmap"

From ScummVM :: Wiki
< SCI
Jump to navigation Jump to search
(→‎Keeping Glutton around: add note about string progress)
(Deleted the now obsolete SCI roadmap page)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
This is an incomplete roadmap of what I'd like to see in the SCI engine 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).
 
 
==So what are these vocabulary resources?==
 
 
vocab.999 / 999.voc contains names of the kernel functions which are implemented by the interpreter. In Sierra SCI, they are used exclusively by the debugger, which is why keeping the file up to date was less important. This resource is notoriously unreliable, and should not be used.
 
 
vocab.997 / 997.voc contains the names of every selector in the class hierarchy. Each method and property '''name''' consumes one id, but if a name is shared between classes, one id will do.
 
 
vocab.994 / 994.voc contains offsets into certain classes of certain properties. This enables the interpreter to update these properties in O(1) time which was important in the era when SCI was initially conceived. What we have previously done in FreeSCI is to simply figure out what '''property''' a certain offset refers to (which requires one to guess what class a pointer points to) and then simply use the property name and vocab.997. This results in much more readable code.
 
 
==How does the SCI engine use vocab.997 ?==
 
 
The SCI engine loads vocab.997 on startup, and fills in an internal structure that allows interpreter code to access these selectors via #defined macros. It does not use the file after this initial stage.
 
 
==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 [[User:Lskovlun|lskovlun]] and wjp) 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.
 
 
Note: since r44388 most of this string problem should be solved.
 
 
==What is this thing about SCI32?==
 
 
Clone2727 has been working on (very) early SCI32 support and the VM itself is working well. The memory model in SCI32 is based exclusively on memory handles, for which the current segment manager is well-suited. However, the handle types we need are completely different. So this is how I would proceed:
 
 
* Abstractify the current segment manager and create a new subclass from that.
 
* Add new segment types. I would recommend doing this on an as-needed basis instead of following the original engine strictly. As an example, I think that the segment type for SCI32 strings could be a simple wrapper around Common::StringList.
 
* By now, the first few kernel functions should be easy to implement, such as GetSaveDir and String.
 
* The next step would be an adaptation of the widget-based graphics layer to meet the needs of SCI32.
 
* Who knows?
 
 
Of course, since I am not responsible for the current SCI32, this is only a suggestion.
 
 
__NOTOC__
 

Latest revision as of 07:10, 20 July 2010