[Scummvm-devel] ENGINE AUTHORS: case-insensitivy and directory handling

peres peres at scummvm.org
Mon Aug 4 17:55:00 CEST 2008


Hi


* we base this on FSNode::openFileForReading/Writing() methods.

Ok, that's needed and will be done :)

* Caching the contents of the given dir is mandatory. Just keep a
HashMap of the files. Easy to do (case insensitive) lookups against
that, too. I think I would lazily create it, the first time somebody
tries to access a file in the dir.

This is sensible. Since we are not dealing with very deep trees, maybe
we want to cache subdirectories into the same map. We could use
the full path provided by FSNode as the key into the HashMap. I was
planning to use HashMap<String, bool>, where the bool stores a bit to
tell directories from plain files. Or did you mean to cache FSNodes
instead?

* GameDirectory::getSubDirectory() doesn't support error handling in
its current form. I.e. if you try to do it on a non-existing dir.  Right  
now
it'll just crash, I think.

It already returns an empty GameDirectory now.

* But a typical use case is that we  might want to also search for files
in the "resource" or "RESOURCE"  subdir, if it exists. That is not really
possible right now.

This would make the above caching strategy (base + subdirs) worthless,
since the planned HashMap would ignore case. We could change the
cache to only keep the files name on the base level, but then deep
searches would become more trickier to perform, unless we ignore cache
and resort to lookupFile on FSNode, much like the code is doing now.

If we cache subdirs like I said before, this becomes tricky, unless we
use CaseSensitive comparators (and kill the whole purpose of
GameDirectory!).

* In getSubDirectory, I think I wouldn't want to error out on a name
clash. Just print a warning. Better to just run as good as possible
(by only using the first of the matching dirs) than to do a full
crash, isn't it? At least in this case...

OK!

* Resource managment: One nice thing about class File is that it
automatically takes care of closing the file and freeing any used
memory when it goes out of scope. With GameDirectory::openFile(), we
loose that nice bit. Well, I guess we can use Common::SharedPtr to
resolve that. I.e. advice engine authors to do
    SharedPtr<SeekableReadStream> file = dir.openFile("test.dat");
Of course, they would still have to check the returned value to be non-
zero to detect errors, but that's not worse than current code, I guess.

Can't think of any drawbacks, except the long declaration needed by
client code. Maybe we should have an alias like GameDataStream or
GameStream that hides the extra indirection by SharedPtr (users must
be informed, though!).

* Finally, I guess a (pseudo) example of how to *use* GameDirectory
would help people to understand and comment on your proposal much more
than any (lengthy) text would

OK. I will be *very busy* until Aug, 11th, but I will try to find some time
to implement a sample (and everything else we are talking in this mail).
Any idea on which engine would be faster to convert to this approach?

Please, engine guys! Say something!!!


bye
Nicola




More information about the Scummvm-devel mailing list