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

Max Horn max at quendi.de
Wed Sep 16 01:53:35 CEST 2009


Am 16.09.2009 um 01:13 schrieb Walter van Niftrik:

> Max Horn wrote:
>>
>> OK, to go one level deeper: why do we base some segments on reg_t at
>> all? :)
>
> The original design document for glutton can be found here:
> http://freesci.linuxgames.com/docs/fsci-final-revision-A-pdf.pdf
>
> In glutton, raw data and numbers could still be stored in uint16s, but
> pointers, handles, etc all have a segment part that needs to be  
> preserved.

Excellent! Now I feel I have a full understanding of what's going on.  
Thanks for patiently explaining everything :).

Back to what you wrote earlier:

> My comments were based on the current practical situation, where not
> every segment is reg_t-based. For some it should be easy to correct
> this, but e.g. there are also strings that are embedded in the  
> scripts.
> As we don't want to change the whole script to reg_t, maybe the best
> solution there is to relocate the strings to another reg_t-based  
> segment.

Maybe that's not necessary. After all, the advantage of using segments  
is that we can tell for all data were it comes from. The problem is  
that the four SegManager::deref*() methods "hide" this information.  
Since we are in C++, we could remove these "typeless" methods, and  
replace them by type aware ones. For example, derefString could return  
a proxy object which would automatically do the right thing depending  
on whether the dereferenced segment is reg_t or raw based... Well, one  
would have to take a closer look at the code and actual examples in  
game scripts to see if that suffices, but on a quick glance it might...

Bye,
Max

P.S.: I am playing lsl5 right now to take a look at that copy  
protection screen, and seeing tons of these warnings:
WARNING: [VM] validate_variable(): Attempt to use invalid param  
variable 0002 (out of range [0..1])!
WARNING: [VM] validate_variable(): Attempt to use invalid param  
variable 0007 (out of range [0..6])!

Always  n+1 outside the range [0..n]. Makes me wonder if our  
validation logic itself is flawed -- maybe the range should be [1..n 
+1] or eveb [0..n+1] ? At least for that SCI version?




More information about the Scummvm-devel mailing list