<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Indeed, now the concept of strings in SCI is even more confusing :(<br>Anyway, here's the patch I am proposing for replacing the current usage of string<br>fragments with something simpler. Older savegames are broken with this patch,<br>I haven't figured out what I'm doing wrong int he game loading code.<br><br>Patch:<br>https://sourceforge.net/tracker/?func=detail&aid=2859519&group_id=37116&atid=418822<br><br>> From: max@quendi.de<br>> To: lskovlun@image.dk<br>> Date: Tue, 15 Sep 2009 21:31:21 +0200<br>> CC: scummvm-devel@lists.sourceforge.net<br>> Subject: Re: [Scummvm-devel] String fragments and system strings in SCI<br>> <br>> Hi Lars,<br>> <br>> thanks for the explanations. However, after your post it is even less <br>> clear to me where the issue at hand comes from. :-(.<br>> <br>> <br>> Am 15.09.2009 um 21:09 schrieb Lars Skovlund:<br>> <br>> > On Tue, Sep 15, 2009 at 05:03:32PM +0200, Max Horn wrote:<br>> >><br>> >> Am 15.09.2009 um 16:31 schrieb Filippos Karapetis:<br>> >><br>> >>> Further to this: I've now created a patch which removes string<br>> >>> fragments, and uses Common::String instead, with no ill-effects.<br>> >>> Should I apply it to the trunk, or upload it to the tracker?<br>> >><br>> >> Post it to the tracker first. BTW, I don't see at all how<br>> >> Common::String is related to the issue at hand<br>> ><br>> > Well, my original idea for a practical stringfrag implementation<br>> > involved conversion of the engine backend to use Common::String<br>> > exclusively, rather than char*.<br>> <br>> Right, but that seems to me an tangential implementation detail, <br>> though :). I.e., in Filippos post it sounded a bit as if switching to <br>> Common::String would fix some kind of problem. AFAIK it is just about <br>> convenience, but neither cause nor cure of the actual "problem", right?<br>> <br>> ><br>> > (which is that the<br>> >> Glutton engine tries to be clever and recognize the "type" of data <br>> >> and<br>> >> then store each kind differently<br>> ><br>> > Actually, that's a description of the cure rather than the<br>> > disease. The problem is that our reg_t's (or whatever they are called<br>> > these days) are 32 bits wide. There are occasional places where the<br>> > script code tries to be clever, and parse strings by indexing into a<br>> > 16-bit array for example (QfG2 character import). Or conversely, use<br>> > StrAt() to read/write an array of integers (QfG2 desert). These kinds<br>> > of hackery are handled very poorly in Glutton ATM.<br>> <br>> This part is where my confusing comes up. So far, I thought the <br>> problem is that in some places we store string data as a "raw" string; <br>> in others as reg_t array, with each reg_t containing two chars. And <br>> the code has to deal with that, by detecting which format the data is <br>> in and then acting appropriately -- that is why e.g. kStrAt() is doing <br>> all sorts of checks.<br>> <br>> Now if I understand correctly, kStrAt and the Memory opcode were more <br>> or less interchangeable in some scripts seems to indicate to me that <br>> the original engine did not store string and array data in separate <br>> formats. Isn't that right? Or did it also contain magic tricks to <br>> distinguish strings from arrays?<br>> <br>> My impression was that "being clever" about data types was cause (not <br>> cure) of the issue was based on the assumption that the original <br>> engine indeed was not troubled by the issues we are facing. Because if <br>> we did it like the original engine, then there would be no issue at <br>> all, would there?. After all, it should be "easy" to implement both <br>> string and "memory" opcodes for either format (string or reg_t array), <br>> and then use only one of the two exclusively, right?<br>> <br>> So now I am thoroughly confused. Hope somebody can tangle this up :)<br>> <br>> BTW, I wouldn't be too concerned about breaking savegame compatibility <br>> at this point. Just announce it before doing it, so that I can perform <br>> my own patch of breaking changes right afterwards (such as changing <br>> the savegame header to a saner format and dropping some now obsolete <br>> stuff etc. ;).<br>> <br>> Cheers,<br>> Max<br>> <br>> <br>> ------------------------------------------------------------------------------<br>> Come build with us! The BlackBerry® Developer Conference in SF, CA<br>> is the only developer event you need to attend this year. Jumpstart your<br>> developing skills, take BlackBerry mobile applications to market and stay <br>> ahead of the curve. Join us from November 9-12, 2009. Register now!<br>> http://p.sf.net/sfu/devconf<br>> _______________________________________________<br>> Scummvm-devel mailing list<br>> Scummvm-devel@lists.sourceforge.net<br>> https://lists.sourceforge.net/lists/listinfo/scummvm-devel<br><br /><hr />Hotmail: Free, trusted and rich email service. <a href='http://clk.atdmt.com/GBL/go/171222984/direct/01/' target='_new'>Get it now.</a></body>
</html>