[Scummvm-devel] Savefiles

[Marcus Comstedt]

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.


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


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


If compression is added at a higher level in the call stack, the
scenario would look like this:

We have old save files that are zlib compressed (DC) and uncompressed
(others).  We also have new save files that use the new compression.

For non-DC, the port layer will just pass the data unmodified to the
higher level compression, so this layer has to be able to
differentiate between old uncompressed saves, and the compressed saves
it has created itself.  This can be done with a flag or a heuristic,
that's your call.

For DC, if the new compression is different from raw zlib compression,
it has to be able to able to differentiate between the following three
cases while loading:

* "new" compressed files:  These should be passed unmodified to the
  upper layer which will recognize them as compressed

* "old" zlib compressed files:  These should be uncompressed by the
  DC-specific code, and passed to the upper layer which will then
  recognize them as uncompressed.

* old uncompressed files:  These should be passed unmodified to the
  upper layer which will recognize them as uncompressed.

(The last case isn't terribly important, since it is only required for
 saves created with a really old ScummVM DC which didn't compress
 saves.)

For saving, it can just pass the data along unmodified without looking
at it, since compression should be handled by the upper layer.

So in essence, since the code can already tell "old uncompressed
files" from "old zlib compressed files", what I will need is a way to
differentiate the "new" compressed files from the "old" compressed
files so that I know whether I should attempt uncompression or not.


  // Marcus