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

[Lars Skovlund]

On Tue, Sep 15, 2009 at 05:03:32PM +0200, Max Horn wrote:
> 
> Am 15.09.2009 um 16:31 schrieb Filippos Karapetis:
> 
> > Further to this: I've now created a patch which removes string  
> > fragments, and uses Common::String instead, with no ill-effects.  
> > Should I apply it to the trunk, or upload it to the tracker?
> 
> Post it to the tracker first. BTW, I don't see at all how  
> Common::String is related to the issue at hand

Well, my original idea for a practical stringfrag implementation
involved conversion of the engine backend to use Common::String
exclusively, rather than char*.

 (which is that the  
> Glutton engine tries to be clever and recognize the "type" of data and  
> then store each kind differently

Actually, that's a description of the cure rather than the
disease. The problem is that our reg_t's (or whatever they are called
these days) are 32 bits wide. There are occasional places where the
script code tries to be clever, and parse strings by indexing into a
16-bit array for example (QfG2 character import). Or conversely, use
StrAt() to read/write an array of integers (QfG2 desert). These kinds
of hackery are handled very poorly in Glutton ATM.

Our (me and Christoph) proposed cure would be to actually support
"polymorphic" strings that could be interconverted, based on where the
original data came from and what the script tries to do with it. One
of these representations would be the stringfrag representation (where
each reg_t is exactly two ASCII characters - as in 16-bit SCI -
coupled with a special segment value). The other representation would
be the original binary representation (i.e. what we have now).

The idea then was to have every kernel call that needs to read/write
strings, convert their argument into some internal representation
first, regardless of what the source of the argument is. 
Common::String seems to be a good choice here. 

This would be the "generic" way of doing things, and certainly in
Christoph's spirit. However, game-specific workarounds are also an
option. We are already using them in the GUI code (save/load
buttons). And since stringfrags are not fully operational yet, we
would have to break savefiles for that.

> Just because we don't know of any other places where this turns into a  
> problem doesn't mean there aren't any... at the very least, our code  
> should be able to detect this situation and warn about it. Also, I  
> would like to hear what Lars has to say :)

I haven't seen Filippos's patch yet, and I am having a little bit of
trouble figuring out what he's changing with it.

> Cheers,
> Max

Lars