[Scummvm-devel] Savefile changes (ATTN porters)

[Max Horn]

Am 18.02.2007 um 12:37 schrieb Marcus Comstedt:

>
> Max Horn <max at quendi.de> writes:
>
>> Hi folks,
>>
>> as you may have noticed, I made two changes to the savefile system
>> today:
>>
>> 1) I introduced OutSaveFile::finalize(). This method is supposed to
>> be called just before client code disposes a OutSaveFile --
>
> Just before client code calls ioFailed() to check if everything
> went ok, I take it that you mean...  :-)

Yeah, that's indeed what I should have written (and meant, too :-).  
Thanks.


>
>
> [...]
>> The DC port justs uses zlib's (un)compress -- with some luck, the new
>> compression code can already open such savegames (in theory it should
>> be able to load both the gzip and the zlib format...). Alas, I can't
>> test that.
>
> I shouldn't think so, given the code
>
>                 bool isCompressed = (toBeWrapped->readUint16BE() ==  
> 0x1F8B);
>
> in wrapInSaveFile().

OK, once again I expressed it badly: The new (de)compression code  
should be able to decode such games, and once we change the code  
which detects whether compression is present to also detect zlib  
compressed games, it should be able to load these, too. Right now,  
the code is set to check for a gzip header (i.e. 0x1F8b, see http:// 
www.faqs.org/rfcs/rfc1952.html).

Sadly, the zlib format doesn't feature a fixed magic header (see  
http://www.faqs.org/rfcs/rfc1950.html) and hence is a bit trickier to  
detect reliably.
Since I didn't have any savegames to test, I didn't want to just add  
detection for zlib headers. If you could send me a savegame made on  
the DC, I'll be happy to work on this. :-)


> zlib compressed data starts with 0x08, 0x18,
> 0x28, 0x38, 0x48, 0x58, 0x68, or 0x78, depending on the compression
> window size used.

Aye, and depending on the compression type (which should always be 8  
in the current version of the spec, though). And the first two bytes  
together, read as BE, must be a multiple of 31, by the spec (and the  
def of the FLG.FCHECK field).

> Never 0x1f.  If the first Uint16BE is stored in x,
> the correct method of checking for a zlib header is
>
>   ((x & 0xf00) == 0x800 && (x % 31) == 0)

Precisely :-). Feel free to add this check (in two spots -- the wrap  
method, and the CompressedInSaveFile class), and if it works for you,  
commit it. Or send me a sample savefile, and i'll be happy to  
experiment with it.



Bye,
Max