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

[Filippos Karapetis]

Indeed, now the concept of strings in SCI is even more confusing :(
Anyway, here's the patch I am proposing for replacing the current usage of string
fragments with something simpler. Older savegames are broken with this patch,
I haven't figured out what I'm doing wrong int he game loading code.

Patch:
https://sourceforge.net/tracker/?func=detail&aid=2859519&group_id=37116&atid=418822

> From: max at quendi.de
> To: lskovlun at image.dk
> Date: Tue, 15 Sep 2009 21:31:21 +0200
> CC: scummvm-devel at lists.sourceforge.net
> Subject: Re: [Scummvm-devel] String fragments and system strings in SCI
> 
> 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. ;).
> 
> Cheers,
> Max
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel

_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090915/db308d9a/attachment.html>