[Scummvm-devel] Savefiles

[Max Horn]

At 19:28 Uhr +0100 15.12.2002, Marcus Comstedt wrote:
>Max Horn <max at quendi.de> writes:
>
>>  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.
>
>It tries to be.  The only "game dependent" assumption it makes is that
>the savefile name ends with a decimal number.  It could be made
>totally game independent by instead allowing the caller to pass a
>callback which will analyze the filename and reply with the slot
>number (if any), but I though that was a bit overkill.  Do we
>anticipate radically different naming conventions for other games?
>
>
>>  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?
>
>Yes.  Since savegames are just a flat structure, I considered the fs
>stuff serious overkill for this.  Also, fs (currently) only allows one
>"root", while at least on the Dreamcast the filesystems for games and
>saves are completely different and would require two different
>(incompatible) fs implementations at the same time.
>
>It just seemed like a lot of extra work for no real gain (since the fs
>things solve a different problem than the one I'm trying to solve).
>You are free to disagree of course.

No I trust you know what you are doing, just asked :-)


>
>>  Of course. Still I'll get merge conflicts since you modified the 
>>same code :-)
>
>Right.  That's your punsihment for keeping uncommitted changes in your
>source tree.  :-)

I *have* to keep them out until license issues are resolved.

>
>
>>  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.
>
>I already support both compressed and uncompressed save games.  There
>is no explicit "flag", however the header for zlib compressed data is
>different from the header used in the uncompressed data:  The
>uncompressed data starts with "SCVM", so the first octet is always
>0x53.  Compressed data always starts with an octet that is 0x*8, since
>this is the identifier of the "deflate" method in the zlib header.
>The second nybble in the file is thus enough to tell the formats
>apart.

Well, assuming you only ever get proper save game files of course. 
What happens if a malevolent/stupid users feeds you a .png he 
renamed? :-)

I am not compressing the whole file. The header stays uncompressed, 
only the actualy data is compressed.

Hence you could again differentiate it from your old compression format.


Cheers,

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