Difference between revisions of "SCI/FreeSCI/Savegames"
(Merging of the FreeSCI documentation. Page done.) |
(No difference)
|
Latest revision as of 15:00, 20 January 2009
Savegames
FreeSCI attempts to store savegames portably; for this reason, most of the game data is saved as plain text, while the graphics are written to png[1] files.
Savegame directory policy
The general FreeSCI directory policy is simple: If there is a $HOMEm use ~/.freesci/[game name]/ as your playground, if there is no home, use the current working directory. Savegames are true to that policy. Each save game has a directory associated with itself, and this directory is relative to the directory mentioned above. For example, if you execute ``save_game frobnitz in SQ3 on your *BSD box while your $HOME is set to /home/rogerw, the save game files would be written to /home/rogerw/.freesci/SQ3/frobnitz/.
Files
- state
- This is the main save file. It contains huge amounts of text data, which are an almost-complete replication of the game internal state_t structure. The code used to read and write this file is automatically generated by a script called cfsml.pl, and it is believed to be rather flexible; i.e. you should be able to insert blank lines, comment lines, (Using the hash ('#') sign), move assignements around, and change values. The identifiers used in this file are identical to the identifiers used in the c code.
- heap
- This is a binary copy of the heap data. Heap data is internally structured to be identical to SCI heap data (little endian, 16 bit), so it is portable to all platforms.
- hunk*
- These files contain raw hunk data. SCI code may allocate raw hunk data, but it can't do anything with it (except unallocate it again). It is unlikely that you are going to encounter a hunk file in normal SCI code. This may change for later SCI versions.
- song.*
- Songs stored by the sound subsystem.
- sound
- Contains the state of the sound subsystem. The syntax is identical to the used in the "state" file.
- *.id
- Savegame name file for one SCI game. The file names are chosen by taking the game's "unique" identifier and appending a suffix of ".id". This file contains the savegame name in plain text.
Obsolete files
The following files were generated by earlier versions of FreeSCI, but are no longer used:
- map.png
- The four maps of the main picture are stored in four separate png files:
- visual_map.png
- priority_map.png
- control_map.png
- auxiliary_map.png
- The meanings of those files should be rather obvious.
- visual_map.png contains regular palette or color information, so it is, in fact, a screenshot of the game (the mouse pointer is not shown, since it is not stored in the display maps). The other three png files each contain a greyscale gradient palette.
- buffer*
- These are png files containing the various graphical buffers used in the game. buffer_x.1 is the visual buffer, buffer_x.2 is the priority buffer, and buffer_x.4 is the control buffer. Any combination of these three buffers is possible.
- Control and priority buffers contain a grayscale gradient palette.
Caveats
FreeSCI's file saving and restoration functionality isn't perfect. Please be aware of the following flaws and limitations before you dig out your flame thrower:
- File handles
- Open file handles are NOT stored or loaded. If you try to save the game with the built-in debugger while file handles are still open, you will be warned about this and saving will abort, unless you preceed your save directory name with an underscore ('_').
- Kernel functions
- SCI kernel functions are able to call the virtual machine. In practice, this means that you may have two or more vm function calls on your system stack; it is not easily possible to store the game state in this case. FreeSCI does not allow it, and, as far as I know, no Sierra SCI code ever tries to do that.
- To determine whether or not this applies to you, run "bt" in the debugger; the "base" number in the first line must be zero, or you won't be able to save the game (restoring should work, though).
Notes
- ↑ Portable Network Graphics. A very portable graphics format with lossless compression, a free reference implementation, and dozens of useful features.