[Scummvm-devel] File API

Max Horn max at quendi.de
Thu Feb 5 18:42:01 CET 2004


[note, this is in no way targeted at Travis/Kirben, his CVS commit just 
reminded me :-)

[...]
>
> Add extra paths for international version of Simon the Sorcerer 1, so 
> game can be played from CD.
>
>
> Index: file.cpp
> ===================================================================
> RCS file: /cvsroot/scummvm/scummvm/common/file.cpp,v
> retrieving revision 1.54
> retrieving revision 1.55
> diff -u -d -r1.54 -r1.55
> --- file.cpp	6 Jan 2004 12:52:08 -0000	1.54
> +++ file.cpp	6 Feb 2004 00:58:24 -0000	1.55
> @@ -78,6 +78,14 @@
>  		"execute/",
>  		"EXECUTE/",
>  		// Simon the Sorcerer 2 Amiga/Mac
> +		"french/",
> +		"FRENCH/",
> +		"hebrew/",
> +		"HEBREW/",
> +		"italian/",
> +		"ITALIAN/",
> +		"spanish/",
> +		"SPANISH/",
>  		"voices/",
>  		"VOICES/",

This highlights another sore spot in our codebase which I wanted to get 
fixed for quite some time now... having dozens of subdirs listed here 
really is bad.

One thing (which is also listed in our TODO) I'd like to do is cleanup 
the File code (and also the code in backends/fs/fs.h,  and ). Which 
will require some assistance of the porters. Of course all this will be 
post-0.6.0.


Right now our file code is split in three blocks: class File; then, 
SaveFile & SaveFileManager; finally, FilesystemNode & FSList. I'd like 
to see this cleaned up and unified.  I am not yet fully sure how the 
result could look, but the design would be driven by our needs, of 
course. So I try to list them here.

* We need to access the following three file types:
  1) read only (game data) files (regular file, ROM handle, etc.)
  2) read/write (savegames) files (also config file)
  3) write-only files for debug/dumps (optional, could be implemented as 
a dummy on systems w/o big storage space)
  The distinction is important for e.g. the Dreamcast. To that end, we 
should enforce that no plain file API (fopen/fread/fwrite/etc.) is used 
in our code base

* We need to browse the filesystem / contents of a directory:
   1) For listing savegames - this is essentially what SaveFileManager 
does right now
   2) For listing the directory hierarchy, if applicable (this is used 
by the launcher, to let the user select games)
   3) The game detector code wants to know all files in a given directory

* We need a way to check whether a given file exists (stat on Unix like 
systems; other implementations on other systems)

* For convenience, we implemented a system in our current class File 
which automatically searches a set of subdirectories for data files. 
Right now, we hard code paths for this. At the very least, the list of 
paths should be customizable by the client code (in particular, each 
engine only needs a subset of the current long list). Maybe this should 
also be moved to more high level code.

* One idea for a new design might be to have a (singleton) FileManager, 
which is used to create File objects (of one of the tree types listed 
above). That class would also deal with the other points listed above 
(browsing, existence check, searching multiple dirs for files, etc.). 
The implementation of it would be left to porters. We'd provide a 
default implementation, but porters could provide their own. Not yet 
sure how that would look exactly, though. Maybe part of the system 
would be in common/file.h (the portable parts), and another part would 
reside in backends/file (or backends/fs like now).


Anyway, I need to get to bed now, I'll leave this for you think about 
and comment (esp. porters may want to point out any problems they 
notice or add suggestions on how we could ease their life).


Cheers,

Max





More information about the Scummvm-devel mailing list