Jump to navigation Jump to search


570 bytes added, 17:48, 5 September 2009
SCI32 implementation roadmap
==What is this thing about SCI32?==
Whereas SCI1.1 Clone2727 has been working on (very) early SCI32 support and earlier have a 64 kilobyte heap space which the VM itself is addressable via pointers, working well. The memory model in SCI32 uses is based exclusively on memory handles exclusively. That means that all the string handling functions have been replaced by a single String() call, array handling (for which used to be primitives) the current segment manager is now a kernel call Array()well-suited. However, etcthe handle types we need are completely different. '''Direct pointer addressing So this is no longer possible!'''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.


Navigation menu