[Scummvm-devel] ScummVM PS2 backend - to be or not to be... a directory

[Max Horn]

Hi Max!

[...]

>  Back to scummvm and savefiles:
>
> Let's take The Dig:
>
> In PS2 ::listSavefiles I get a regex "dig.s*" and the current
> PS2 savefiles manager stores them in "mc0:/ScummVM-dig" with
> names like: "s00.ucl", "s01.ucl", etc.

Ugh! I wasn't aware of that (I guess nobody on the team but Robert  
was ;-). I wonder why that was done?

Also, I always wondered why the PS2 port uses ucl instead of zlib. Is  
zlib to slow / uses to much memory? At least in theory, it would be  
nice if the PS2 port would simply use the zlib compression code we  
provide for the "default" SDL port, too. In particular, backends/ 
saves/compressed/compressed-saves.h provides two functions  
wrapInSaveFile() and wrapOutSaveFile() which can be used to  
transparently add zlib support to any port which supports zlib. See  
also DefaultSaveFileManager::openForLoading() and  
DefaultSaveFileManager::openForSaving() in  backends/saves/default/ 
default-saves.cpp for a usage example.


> Now I have to return a
> StringList of matching files...
>
> 1) should I list the 'full' path or the just the name ?

To quote the Doxygen comment:
    * @return list of strings for all present file names.

So, only the name. The savefile manager is in fact completely unaware  
about "paths". It only provide an API to open "savestates" using a  
name (which can be mapped to files with the same name, but could in  
theory also be mapped differently), and to query for a list of these  
savestates, and some more. Paths do not play a role here (although of  
course implementations of the savefile manager API are free to use  
paths internally).

I will update the Doxygen comments to be clearer about this, in  
particular, drop bad references to "filenames" when we really are  
talking about "savefile names". Maybe we should in fact change all  
occurrences of "savefile" to "savestate", to make it even clearer  
that there does not *have* to be a 1-1 mapping between files and  
savefiles.


>
> 2) since we are short of time before 0.11.1, without
>    changing the current PS2 implementation, I wonder:
>
>    should I just return all the s??.ucl files that are
>    stored in the per games folder in the memory card?
>    (quick).

Well, ideally, it should translate the filenames internally, if  
that's possible: I.e. the file "mc0:/ScummVM-dig/s00.ucl" is mapped  
to the savename "dig.s00" and back. I imagine the PS2 port already  
does that anyway. So, if you have that "conversion table" anyway, it  
should be possible to perform pattern matching on that.

Or maybe this is not feasible, because it would require reading *all*  
savestate dirs. Well, then the second best solution would be to parse  
the pattern "dig.s??" and extract from it the dir name "dig" (which  
causes the port to look at dir "mc0:/ScummVM-dig"), and the extension  
patter "s??" (which you translate to "s??.ucl" and then perform  
matching). Of course this relies on the pattern being of the form  
"basename.extension". However, we already violate that assumption in  
one or two spots, I think (for Indy3 IQ points, for example). So care  
has to be taken to handle the case where no "." is present in the  
pattern. (I wonder whether the current PS2 save code does that?)


>
>    Or should I change it to save them in dig.s?? format
>    and then regex between those? (less quick)

On the long run, this *might* be preferable, if being able to  
exchange savestates with a PC is a desirable feature for the PS2  
port. Naively, this seems like an interesting thing, but I have no  
idea whether it would even be possible, so I think the folks who know  
(i.e. you, Robert, PS2 users) should say what they want :-)


> I just started working on the file saves, so I apologize if I am
> asking something terribly stupid. And I can, of course, eventually
> figure it out by myself, but having this two answers will speed
> things up.

Max, you are most welcome to ask. Me and others are always happy to  
share what we know about the internals of ScummVM. The more people  
know about them, the better. I don't think any of your questions are  
stupid. ScummVM is a big program which sadly is rather  
underdocumented, so it's very natural to ask many questions. And it's  
better to ask them than to make possibly wrong assumptions anyway.

Keep 'em coming! :-)

Cheers,
Max