[Scummvm-devel] SCI: Some more TODOs

Max Horn max at quendi.de
Sun Feb 22 21:55:02 CET 2009


Am 22.02.2009 um 10:26 schrieb Willem Jan Palenstijn:
>
>
[...]

>> One simple approach would be to prefix the file names with qfg_
>> automatically.
>
> I'm not yet really familiar with game IDs, but would it be easy to
> determine this prefix? We'd probably want all QfG games (including
> Hero's Quest) to share a prefix (qfg sounds good), but as far as I  
> know,
> all other games should probably use a unique one (targetName?).

Sometimes the targetname is what one should use, sometimes the gameid:  
The former if data is specific to game variants (like, english and  
german version using incompatible savegames); the latter is OK if all  
variants use compatible files.

And sometimes a special prefix could be used, as for the QfG character  
files. I don't know how hard it will be to add support for this  
special case, though. If it is only QfG that needs this special  
treatment (for exchanging data between *different* games), then we  
could just add a special case: If the running game is from the QfG  
series, then in addition to listing all regular savestates for the  
game (with the regular prefix, which we would hide from the SCI  
engine) also list the files with qfg_ prefix.


>
>
>> 3) All the other file code in kFileIO may have to be extended to work
>> with both savefiles and files in the game's resource directory. That
>> is, when writing a file, a savefile would always be used. When  
>> reading
>> a file, we would first check whether a savefile with the right name
>> (after mangling) exists. If not, we'd look in the gamedir. (We do
>> something similar in SCUMM HE.)
>
> Yes, agreed.
>
>> 4) The SCI code doesn't seem to clearly distinguish between opening a
>> file for reading and for writing. We may have to hack around that.
>
> file_open seems to open a file for reading/writing with
> _K_FILE_MODE_OPEN_OR_FAIL and for writing (truncating existing files)
> with the other two modes (_K_FILE_MODE_OPEN_OR_CREATE,
> _K_FILE_MODE_CREATE). I guess we could do the same for the writing
> modes. Maybe for the _K_FILE_MODE_OPEN_OR_FAIL mode we could open the
> file for reading, and then re-open it (properly seeking to the right
> offset) for writing when necessary?


I wonder whether we actually need that? In typical programs, files are  
*either* read *or* written. Does any SCI game really alternate between  
reading and writing a file, without reopening it?


Bye,
Max




More information about the Scummvm-devel mailing list