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

Max Horn max at quendi.de
Tue Sep 15 21:31:21 CEST 2009

Hi Lars,

thanks for the explanations. However, after your post it is even less  
clear to me where the issue at hand comes from. :-(.

Am 15.09.2009 um 21:09 schrieb 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*.

Right, but that seems to me an tangential implementation detail,  
though :). I.e., in Filippos post it sounded a bit as if switching to  
Common::String would fix some kind of problem. AFAIK it is just about  
convenience, but neither cause nor cure of the actual "problem", right?

> (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.

This part is where my confusing comes up. So far, I thought the  
problem is that in some places we store string data as a "raw" string;  
in others as reg_t array, with each reg_t containing two chars. And  
the code has to deal with that, by detecting which format the data is  
in and then acting appropriately -- that is why e.g. kStrAt() is doing  
all sorts of checks.

Now if I understand correctly, kStrAt and the Memory opcode were more  
or less interchangeable in some scripts seems to indicate to me that  
the original engine did not store string and array data in separate  
formats. Isn't that right? Or did it also contain magic tricks to  
distinguish strings from arrays?

My impression was that "being clever" about data types was cause (not  
cure) of the issue was based on the assumption that the original  
engine indeed was not troubled by the issues we are facing. Because if  
we did it like the original engine, then there would be no issue at  
all, would there?. After all, it should be "easy" to implement both  
string and "memory" opcodes for either format (string or reg_t array),  
and then use only one of the two exclusively, right?

So now I am thoroughly confused. Hope somebody can tangle this up :)

BTW, I wouldn't be too concerned about breaking savegame compatibility  
at this point. Just announce it before doing it, so that I can perform  
my own patch of breaking changes right afterwards (such as changing  
the savegame header to a saner format and dropping some now obsolete  
stuff etc. ;).


More information about the Scummvm-devel mailing list