[Scummvm-devel] Porters: Adding seeking to InSaveFile for HE games
Max Horn
max at quendi.de
Sat Apr 22 05:35:03 CEST 2006
Am 22.04.2006 um 13:55 schrieb Travis Howell:
> From: "Max Horn" <max at quendi.de>
>> currently, the HE part of the SCUMM engine has to abuse the File
>> API (no offense intended) for the _hFileTable (see scumm/he/
>> intern_he.h), to implement the file read/write APIs found in the
>> HE games.
>>
>> The HE engine uses lost of Common::File objects aggregated in
>> _hFileTable to allow read/write/seek access to files in the
>> savepath. This is not so nice. Much better (i.e. portable) would
>> be to use (In/ Out)SaveFiles and the SaveFileManager.
>
> The file opcodes in HE Games are used to read information from the
> original data files and create/update save game type files. So
> please keep in mind, that it requires access to data files
> directory and saved game directory.
Aye. Unfortunately, the code as it currently exists, is not portable
to systems that use a custom SaveFileManager / do not allow writing
via Common::File to a persistent storage. :-(
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.
ReadStrems
* 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.
Cheers,
Max
More information about the Scummvm-devel
mailing list