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

Max Horn max at quendi.de
Mon Aug 4 21:44:40 CEST 2008


Am 04.08.2008 um 17:55 schrieb peres:

> Hi
>
>
> * we base this on FSNode::openFileForReading/Writing() methods.
>
> Ok, that's needed and will be done :)

Fine. Note to everybody: I also updated the DefaultSaveFileManager (in  
backends/saves/default/default-saves.cpp) today to use the FSNode API  
& FSNode::openFileForReading/Writing. Also, the default "savepath" is  
now set there, not in base/commandline.cpp.

This gets us one step close to the goal, I think.


> * 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?

My first thought was to store the FSNodes directly -- that way we  
avoid converting from nodes to "paths" then back to nodes. So,  
HashMap<String, FSNode>.
However, this might increase the memory foot print of this quite a  
bit, so maybe we should avoid it.


[...]

> * 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.

I don't see why that is a problem, though? Of course if there are both  
RESOURCE/foo.dat and resource/foo.dat, we have a clash, but as long  
as  "resource" and "RESOURCE" contain different files, there would be  
no problem there... After all, we would retain the case on the strings  
when storing them in the hashmap.

> 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!).

Again, I don't see why we would need to...?

[...]

> * 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!).

A short alias would be a good idea, I guess. But that's all getting  
too much into details already (of course all my fault *g*).


>
>
> * 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?

Not sure. About the smallest is Touche, but it doesn't use  
addDefaultDirectory (which makes conversion probably easier, but  
doesn't highlight how to handle addDefaultDirectory). The ones I know  
best are Tinsel and SCUMM, the latter being highly complex, stressing  
lots of details, but also being huge, so nothing you want to tackle  
quickly.

Maybe sword1 / sword2 would be good targets, as they make heavy use of  
subdirs, yet are not that complex, I think.

>
>
> Please, engine guys! Say something!!!

Hahah, good one ;)

Cheers,
Max




More information about the Scummvm-devel mailing list