[Scummvm-devel] SCI: Some more TODOs

[Max Horn]

Am 20.02.2009 um 18:52 schrieb Willem Jan Palenstijn:

> On Fri, Feb 20, 2009 at 11:51:02AM -0500, Max Horn wrote:
>> * I just made a big commit where I started to overhaul the file
>> handling in SCI. It's incomplete, and may cause regressions, but it  
>> is
>> a start. The biggest chunk left to take care of is engine/kfile.cpp,
>> and in there mostly handling of savegames (and possibly of writing to
>> other files -- if SCI ever does that?).
>
> Recapping a discussion on IRC:
>
> This is used for things like character exports and imports in the QfG
> series,

And.. how? I.e. why does a savegame have to be a directory to allow  
exporting a character? Some details would be nice :-)

> and for player name in Hoyle.

I don't understand (maybe because I don't know "Hoyle")-- why does the  
player name require a separate file?



> There's also a mention of this being used for deleting savegames where
> the scripts try to manually rewrite the savegame index file.
> (Search for __throwaway in kfile.cpp for this.)
>
>
> FreeSCI stored the files that were written to in ~/.freesci , possibly
> copying files from the resources first.  I suggest we do the same  
> thing
> in ~/.scummvm , and possibly prefix the names with the game target  
> name.

That's not really possible in general. What is ~/.scummvm on a  
Nintendo DS, or on a PSP? The only portable place to store files is in  
the savepath. I guess for stuff like character exporting, we could do  
a special exception, and allow it only on desktop machines, but I  
really would prefer if we did that only as a very very last resort. In  
principle, I don't see why a character import/export couldn't be  
realized via regular savestaes, just with a special naming scheme to  
make it possible to exchange those files between the different ga,es.


> One thing to worry about in the future: this makes it relatively  
> hard to
> import exported characters in QfG. We may be able to fake a directory
> structure with different games in different (fake) directories.

Again, I'd appreciate if somebody could elaborate on this. I don't  
have QfG. How does this character import/export stuff work, and why  
does it require directories?

>
>
>
>> This needs to be switched to
>> the savefile API. One problem there is that FreeSCI apparently stored
>> saves as multiple files, grouped by a directory. Does anybody know
>> whether the original Sierra SCI also did this? Our savefile API does
>> not (and will not) support subdirs. Some ideas on how to resolve  
>> this:
>> 1) Fake subdirs by turning save_0/FILE into save_0_FILE. Or even
>> better, into TARGET-FILE.0 or something like that.
>> 2) Revise the save/load code in SCI to put all those files into some
>> kind of archive file.
>> 3) Maybe we don't need all those files? In a KQ4 save I made, there
>> were only two files: state, and KQ4.id, which seems redundant (could
>> be encoded into a header prefixed to 'state', plus the filename)
>
> I just overhauled the savegame system, and went with option 3.
> To quote the commit message of r38649:
>
> "Converted SCI saving to use saveFileMan. Instead of a savegame  
> being a
> directory with an id and a state file, a savegame now consists of two
> consecutive CFSML-serialized structs: SavegameMetadata and state_t.   
> The
> former contains the savegame title, and is loaded when scanning  
> saves."

Coo, thanks :). Looking forward to reviewing your changes.

Cheers,
Max