[Scummvm-devel] String fragments and system strings in SCI
max at quendi.de
Tue Sep 15 21:31:21 CEST 2009
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
>> 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