[Scummvm-devel] File handling revamp

peres peres at scummvm.org
Wed Jul 30 06:08:11 CEST 2008


>> SaveFile is not interesting since the engine manages all its existence
>> (provided the user doesn't mess with it!), but the remaining 3
>> incarnations all show the same pattern, that is the creator of the file  
>> is
>> not the same as its user.
>
> Aye. And it is handled by the savefilemanager, so we don't really need to
> concern ourselves with it.

This is another matter, but how come save files are implemented using  
FILE* instead of FSNode?



>> GameFile
>> would be a thin layer over FSNode, with the responsibility of handling
>> case, and it would have a companion called GameDirectory, to aid keeping
>> filish and directorish stuff separated.
>
> You mean: FSNode stays as it is, and GameFile is a wrapper / different
> layer which makes use of FSNode, but adds such things as locating files
> regardless of case;

Yes.

About case, in my mail I said the engine would have to configure  
GameFile/GameDirectory according to its needs, so it might be case  
sensitive as well as insensitive. Anyway, there is no game we support that  
needs this so far (and hardly will be), so I guess we can safely scrap  
this additional feature.

I've been thinking about this, and we don't even need a GameFile. We could  
just open resources from GameDirectory, which would implement the  
searching criteria (maybe leveraging on trait classes), and then return a  
SeekableReadStream*. Searching can be requested in sub-directories, with  
patterns... (paste your fantastic ideas here). We can even inhibit  
Common::File usage from engines!

Dropping Common::File would let us without the DefaultDirectory thing, but  
we can reproduce it using a collection of GameDirectory, or  maybe a  
GameDirectories object. This feature is not so much different than the  
SearchDirectory that appeared in some previous posts in this thread  
(provided I got the SearchDirectory thing right).


> ignoring trailing dots in filenames (as in "GAMEPC"
> vs. GAMEPC."; see also common/file.cpp:296) ?

This is ugly ;) Is the trailing dot stuff in the current File::open() only  
needed in detection? In this case, couldn't we enhance the detector to  
take alternative/multiple names for the same resource instead?

>
>> The root GameDirectory would be returned by a method in OSystem (there
>> were plans for getting/setting ConfigFile as well, no?),
>
> I am not sure I understand what the "root GameDirectory" is meant to be
> (an object somehow corresponding to the game "path" config entry? if so,
> what does it got to do with OSystem ?)

Late night stuff... I confused the existing OSystem with the hypothetical  
FileManager you were talking about in a previous mail. The current way of  
retrieving the 'root' game directory via ConfMan is fine, of course  
(though the name 'path' sucks). Anyway, you got it right.

bye
Nicola




More information about the Scummvm-devel mailing list