[Scummvm-devel] SCI: Some more TODOs
Max Horn
max at quendi.de
Sat Feb 21 03:50:16 CET 2009
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
More information about the Scummvm-devel
mailing list