[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