<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Ah that clears things up a bit, thanks :)<br><br>So we got two issues, concerning strings:<br>- Accessing these strings in a ubiquitous way from the code and from game scripts<br>- Storing some of these strings in savegames<br><br>Some games (KQ5 and KQ5CD come to mind) do "invalid" reads, especially in kMemory() and in other places too (I've put relevant comments in the code). Greg's engine doesn't have the full implementation of kMemory either (some of the cases are stubs).<br><br>What Max is proposing sounds like a neater solution to the first issue, as it's a bit unclear now regarding when we should use the stringfrag functions or the regular C string functions.<br><br>Now, regarding the second issue... it's a bit unrelated to the first one: we don't need to save system strings in savegames (the savegame directory is always the same for the engine, and the error codes shown when typing something wrong are generated on the fly each time), so I think it would be best to remove these from the savegames - and break older savegames too, since they are now filled with a lot of obsolete data<br><br>Filippos<br><br>> Date: Wed, 16 Sep 2009 02:34:48 +0200<br>> From: walter@vanniftrik-it.nl<br>> To: max@quendi.de<br>> CC: scummvm-devel@lists.sourceforge.net<br>> Subject: Re: [Scummvm-devel] String fragments and system strings in SCI<br>> <br>> Max Horn wrote:<br>> > Maybe that's not necessary. After all, the advantage of using segments  <br>> > is that we can tell for all data were it comes from. The problem is  <br>> > that the four SegManager::deref*() methods "hide" this information.  <br>> > Since we are in C++, we could remove these "typeless" methods, and  <br>> > replace them by type aware ones. For example, derefString could return  <br>> > a proxy object which would automatically do the right thing depending  <br>> > on whether the dereferenced segment is reg_t or raw based...<br>> >   <br>> <br>> Yes, that's basically what I tried to suggest in my first mail on this <br>> topic. :)<br>> <br>> As I pointed out in that email, we can only do that if we store data <br>> consistently. Right now we have both raw and reg_t-based data living <br>> inside reg_t segments, which complicates matters considerably.<br>> <br>> Regards,<br>> <br>> Walter<br>> <br>> ------------------------------------------------------------------------------<br>> Come build with us! The BlackBerry&reg; 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&#45;12, 2009. Register now&#33;<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>