[Scummvm-devel] Residual: Savegame format

[Christian Neumair]

Am Freitag, den 26.05.2006, 22:52 +1000 schrieb Jonathan Gray:
> On Thu, May 25, 2006 at 09:09:47PM +0200, Christian Neumair wrote:
> > Dear ScummVM community,
> > 
> > First of all, thanks to all the ScummVM and Residual hackers out there. You do a great job! :)
> > 
> > 
> > I'm very interested in hacking on Residual. I'm currently trying to figure out the details of the Grim Fandango
> > savegame format, and I noted that the SaveGame::SaveGame SAVEGAME_HEADERTAG assertion doesn't hold
> > for Grim Fandango savegames, and the savegame support of residual is far away from being complete.
> > 
> > I wonder whether anybody is working on the savegame code, and to what degree the .gsv format is known.
> > 
> > Thanks in advance for your efforts!
> > 
> > 
> > PS: Sorry for the previously sent half-written email.
> 
> From http://lua-users.org/lists/lua-l/2000-09/msg00111.html
> 
> "I'd suggest that as you write your Lua code you make sure you can throw
> pieces of it that you're not using out of memory, and get them back when
> you need them.  We didn't do this on Grim.  As the game grew, we had ALL
> of our code loaded at once, even for rooms you probably hadn't played in
> for several hours, with about 2MB of overhead just to have it all
> loaded.  Our savegame dumped out the entire Lua environment; despite
> using zlib, our savegames were quite, uh, hefty.  =)  The first thing we
> did when we started Escape from Monkey Island was to modularize the code
> so that only what was needed for your immediate surroundings was loaded
> at any given time... Think of this as level-specific or region-specific
> code.  Any resource management you do that manages textures, geometry,
> sounds, etc. for a given part of your region should incorporate the
> availability of Lua code.
> 
> This also makes things a lot easier to debug.  =)  Of course, this was
> just a matter of being sloppy about coding in the first place.  Lua
> itself is tiny."

Thanks for that interesting link. I had exactly the same impression when
gunzipping the .gsvs from GF, i.e. there's a lot of crap saved, probably
the state of all the LUA objects. Even the text of the main menu items
is saved in the current locale - although it is probably overwritten
when a .gsv is stuffed into an unlocalized GF.

We clearly need to get a clue on how the .gsv format looks like.

I never reverse engineered a file format, maybe there is a HOWTO or some
general guideline? Where should one start? Disassemble GRIMFANDANGO.EXE,
slightly change the state and diff the files?

How can we know the tags of the various section, and how is it usually
guaranteed that the section tags are not used in some random string? I
can find {...} character sequences, maybe that is some protector?

-- 
Christian Neumair <chris at gnome-de.org>