[Scummvm-devel] Savefiles

[Marcus Comstedt]

Hello all.

Now that 0.3.0b has been dealt with, I've taken care of something I've
been meaning to do for some time:  a refactoring of the low level
savefile code.  The refactoring is in two parts, described below.
Anyone who has any comments before I commit this?


Part A
======

Seeing as virtual methods are now kosher in ScummVM (and has been for
some time), I decided to get rid of the NOSTANDARD_SAVE kluge.  This
means that the SerializerStream class with its preprocessor directed
contents is thrown out, and instead I created an abstract "SaveFile"
class.  This class contains the same fread and fwrite methods that the
SerializerStream had (but abstract), but the fopen and fclose methods
are gone (instead, the constructor and destructor are used to
open/close the file).  There is of course also a concrete
implementaion called StdioSaveFile, which uses the regular
fopen/fclose/fread/fwrite calls.

Then, in order to get the appropriate SaveFile implementation for the
port, I added an open_savefile() method to the OSystem class by having
it inherit the new SaveFileManager class.  The default implementation
of course creates a StdioSaveFile object.  What the ports that
previously used NONSTANDARD_SAVE (which means Dreamcast and GP32) have
to do is just override the open_savefile() method with something that
creates their own kind of SaveFile.  (I'll take care of fixing these
ports, but I can't test the GP32 stuff.)

The SaveFile stuff was put in common/ so that it can be used by
e.g. Simon as well in the future.


Part B
======

What really prompted me to start hacking away is the listing in the
save game dialog.  (The other stuff is just because when I started
poking around I remembered about the ugliness of NONSTANDARD_SAVE. :)
The save game dialog attempts to open 80 different savefiles in order
to build a list of the names of the savegames.  The thing is, on the
Dreamcast, each time there is an attempt to open a savefile, it will
have to go through all the memory cards and list their contents to see
if that savefile is there.  The memory cards are not terribly fast, so
this takes a little while.  When you do it 80 times in a row, well,
the whole thing freezes for at least half a minute (more if you have
multiple memory cards).  Not good.

So, in order to fix this I added a list_savefiles() method to the
SaveFileManager (and thus to OSystem) that can provide hints about
which savefiles actually exist.  I say "hints", since it is allowed to
generate an overestimate.  The default implementation just sets all
slots to "existing", which means the dialog will try to open all 80
just like before.

Since the list_savefiles() method has to be able to determine what is
a savefile, and in that case which one, it is passed a prefix string.
Valid savegames are assumed to have a filename which is this prefix
string followed by a decimal integer giving the slot number.


Well, that's it.  In case someone is really curious, I'm attaching the
patch (excluding changes to the DC and GP32 backends) to this mail.
If there are no protests, I expect to be committing this around
tomorrow.


  // Marcus


-------------- next part --------------
A non-text attachment was scrubbed...
Name: scummsave.diff
Type: text/x-patch
Size: 6606 bytes
Desc: Lowlevel savegame handling refactoring
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20021215/e0a19071/attachment.bin>