[Scummvm-devel] Porters: Adding seeking to InSaveFile for HE games
max at quendi.de
Wed Apr 26 03:10:04 CEST 2006
Am 25.04.2006 um 02:49 schrieb Travis Howell:
> From: "Max Horn" <max at quendi.de>
>> The way to implement this properly (unless I miss something) is
>> roughly this:
>> * You replace _hFileTable by two tables (_hReadFileTable and
>> _hWriteFileTable or so), which hold pointers to WriteStreams resp.
>> * When opening a file for writing, you use the SaveFileManager
>> API and insert the new object into the _hWriteFileTable.
>> * When trying to open a file for reading, you first try to open
>> it via the SaveFileManager. If that works, insert the returned
>> pointer into _hReadFileTable. If that failed, create a File
>> object (via new), and try to open the file that way. If that
>> works, insert the returned pointer into _hReadFileTable, else get
>> rid of it.
>> * When closing files, obviously one has to delete & remove the
>> pointer in the corresponding array. Thanks to virtual destructors,
>> no need to worry where the stream came from.
> Yes, that implementation sounds like it should cover all file
> access by HE games. There are currently similar problems when
> accessing an external config file by o80_readConfigFile/
> o80_writeConfigFile too.
OK. Since nobody voiced any fundamental concerns, I am going to start
working on this conversion. I hope I won't cause too much breakage
(besides forcing porters to do some work, anyways).
> This might be a good time, to ask about the possible support of
> deleting and renaming save game files too? as this would allow the
> original load/save system of HE games to be used.
This is rather independent from the discussion at hand, but certainly
a reasonable question.
So, what are you suggesting precisely? Adding two new calls to
int rename(oldName, newName)
where the int return value could be used to indicate errors (like
"file is protected and can't be deleted). Also, what happens if a
file is renamed, and the new name equals that of an existing file?
Generate an error (as return value)? Overwrite the target file?
Another thing we still badly need to do is improved handling of save
failures: I.e. if saving fails, we should tell the user with a nice
helpful dialog containing a message like "Saving failed because..."
"the savepath FOO is invalid", "... can't write to the savepath
(write protected?)", "media full", etc.
Ideally, openForSaving/openForLoading would return some nice error
codes (just like Engine_FOO_Create should :-).
More information about the Scummvm-devel