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

LavosSpawn lavosspawn at g-trans.de
Fri Feb 22 09:37:30 CET 2008


Hi!
>>
>> 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?
>   
It's because the PS2 Memory Card's filesystem only allows 13 (IIRC) 
files per directory, so if I had made a generic scummvm directory, I 
quickly would've run out of file slots.
So instead I decided to split the filename up create a directory for 
each filename.
e.g. "TENTANCLE.S00" becomes mc0:/ScummVM-Tentacle/s00.ucl
But this also has the advantage that the ps2's bios recognizes these as 
separate sets of data, so if the user decides to delete old savegame 
data from his memory card, the bios won't only show "ScummVM Savegames" 
(and allow you to erase _ALL_ scummvm savegames) but instead you'll have 
one entry per game, called "Tentacle Savegames", "ComI savegames" and so on.


> 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.
>   
It's because back in the early days of my port I didn't manage to make 
zlib compile for the ps2. Support for zlib was introduced later on.
Actually, I thought I even changed the port later on to save all data 
using zlib. Apparently I was wrong and it's only used for SAN sequences 
etc. :)
I'm not sure if it's actually much of a difference, it's a royal pain to 
copy the savegames from a memory card to the pc, so I suppose that most 
users don't care.

>> 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.
>   
Yes, you should definately do the conversion internally. I don't know 
what the api calls for that function look like, but back when I last 
worked on the port it always passed patterns like "dig.s*", which are 
easy to translate to the memory card's structure and back.

> 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?)
>   
Yes, there's a special case in the code for those files.
I think the IQ points get stored in mc0:/ScummVM-iqpoints/ps2file.ucl
or something similar.
>>    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 don't think that actually exchanging the files is an important feature...
and for the reasons outlined above I suggest keeping the file structure 
as-is. (Okay, changing the compression scheme to zlib might be worth a 
shot, but even that is not an important change IMHO. UCL is quite quick 
and compresses equally well as zlib).

Keep up the good work
Robert.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20080222/58c9dbaa/attachment.html>


More information about the Scummvm-devel mailing list