Jump to navigation Jump to search


829 bytes added, 22:51, 18 January 2009
Clarified the use of vocabulary resources
* 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 (. * 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. 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 table -- is a good example while shared between classes, one id will do. vocab.994 / 994.voc is notcontains offsets into certain classes of certain properties. The information This enables the interpreter to update these properties in 994.voc O(1) time which was meant for a computing 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 information lookups were expensive; they aren't anymore, so using a pointer points to) and then simply use the plain property name and vocab.997.voc will do nicely - This results in much more readable code. * How does FreeSCI use vocab.997 ? FreeSCI does this alreadyloads vocab.997 on startup, while the reimplemented SCI engine 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


Navigation menu