[Scummvm-devel] Porters: Adding seeking to InSaveFile for HE games

[Max Horn]

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