[Scummvm-devel] Savefiles

Max Horn max at quendi.de
Sun Dec 15 09:50:02 CET 2002


At 18:34 Uhr +0100 15.12.2002, Marcus Comstedt wrote:
>Max Horn <max at quendi.de> writes:
>
>>  I am not happy at all with the idea of subclassing OSystem from a
>>  SaveFileManager class. That seems just plain wrong to me, it makes no
>>  sense from a logic point of view.
>
>Well, it was mainly to have the prototypes and default implementations
>in the same file as the SaveFile declaration.  I can put them directly
>in OSystem if you like it better.

In my opinion, the OSystem should not contain any save game releated 
stuff. OSystem should be game independent, and the save game list 
code definitly is not.

>
>>  Rather, either add a SaveFileManager *getSaveFileManager(); method to
>>  OSystem, or find some other way to obtain a reference to the
>>  SaveFileManager. But changing OSystem to subclass that from it is an
>>  abuse of the design.
>
>That is also a possibility of course.  It does complicate memory
>management a bit though, since the SaveFileManager object would have
>to be constructed and destructed somewhere.

BTW are you aware that we already have an API (namely in 
backends/fs/) that is there to allow listing of directory content? 
Did you consider using/adapting that instead of rolling yet another 
API?



>
>>  Otherwise, I think this is a good idea. It'll clash a bit with the
>>  savegame compression patch I have here, but then we are still waiting
>>  for permission to use LZO under the LGPL.
>
>A generic compressor would simply wrap the SaveFile object with an
>outer layer I suppose, so the main question there is where the actual
>wrapping takes place (should open_savefile do it, or the caller of
>open_savefile?).

Of course. Still I'll get merge conflicts since you modified the same code :-)


>If the compression is added, could you make it compatible with the
>compression that the Dreamcast port currently does?  (It just puts the
>whole save through zlib.)

Since Ender seems to be opposed to using zlib, no :-/ I am in favor 
of zlib. Alas, I haven't looked at what code you use to compress, so 
I am pretty sure my compression code is different from yours. So even 
if we used zlib, then to make it compatible, that would mostly mean 
that *you* have to take your code and rewrite it for general use 
(somebody else could do it, but only you or some other DC user can 
verify if it is compatible). The crucial question here is, did you 
use a flag in the header that tells whether a savegame is compressed 
or not, i.e. so that we can support both compressed and uncompressed 
save games.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer




More information about the Scummvm-devel mailing list