[Scummvm-devel] String fragments and system strings in SCI

[Willem Jan Palenstijn]

On Tue, Sep 15, 2009 at 07:40:24PM +0000, Filippos Karapetis wrote:
> Indeed, now the concept of strings in SCI is even more confusing :(

Let me try to rephrase it:

In Sierra-SCI, the word size was 2 bytes. For string access, the engine/scripts
occasionally do casts between short*'s and char*'s. (Desert in QfG2, LSL5
password, ...)

In FreeSCI, words take up 4 bytes, but (if they represent integers) still only
store a 2 byte integer. The relevant type is 'reg_t'. For integers, the actual
value is stored in the short reg_t::offset.

If in FreeSCI a script wants to access a char[] as a short[] (i.e, internally
in the VM as a reg_t[]), this can't be done directly if the string is stored as
a regular char*. To make this work, the string has to be stored as a list of
reg_t's, with 2 chars per word (in the reg_t::offset field). See stringfrag.cc
for the exact details on how to convert a char[] to a reg_t[] and back.


I've talked this over with Walter a bit today, and I think (if I understood him
correctly) that the way to make this work most reliably is to store all strings
as such an array of reg_t's internally. The stringfrag code that Lars wrote is
a way of doing this. (Alternatively, it might be possible to just store strings
as an array of reg_t's in the basic arithmetic segment rather than in a custom
stringfrag segment, but that's not a critical point.)

This way, if scripts use kMemory or kStrAt to access the string, they 'see'
what they used to see in Sierra-SCI: an array of 16 bit words. (Except that
they're stored internally as reg_t's.)


The problem is then that if FreeSCI kernel functions access strings, they need
to convert it to/from a more usable format. Common::String seems like a
natural candidate for this.



This is a fairly important/subtle part of the engine, so if anything about this
is wrong or unclear, please correct me :-)


-Willem Jan