At 12:55 19.11.2000 +0100, you wrote:
>Hi,
>
>On Sun, 19 Nov 2000, Petr Vyhnak wrote:
>
> > I have made a little research on the SCI1 engine (I have looked at the one
> > used in the QFG1 VGA remake) and I have found a few things (differences)
> > from SCI0 in the RESOURCE.xxx
> > and RESOURCE.MAP format. I did not figure out the decompression algorithm
> > yet (someone mentioned here PKWARE I think). Anyone interested in the
> > details ? (I can post it here if anyone is interested).
>
>Sure, go ahead. We're not using resource.map anywhere, but this is
>something that ought to be added to the docs eventually.
OK.
The old RESOURCE.MAP (for comparison - it is as I believe described
somewhere already)
Is pretty simple: I consists of 6-byte entries, last one FF FF FF FF FF is
the terminator.
The first 2 bytes encodes resource type (high 5 bits) and number (low 11
bits). The next 4 bytes
is a double-word that contains in the high 6 bits is the resource file
number and the low 26 bits
is the offset to the file. SCI0 performs a linear search to find the
resource (which can be sometimes
duplicated in more than 1 RESOURCE file to help playing from floppies.
The new RESOURCE.MAP is a bit more complicated. First of all in new SCI1
games there
is no limitation to 999 resources of one type, the maximum resource number
is 65535.
The new RESOURCE.MAP starts with an array of 3-byte structures where 1st
byte is
the resource type (0x80 ... 0x91) and next 2 bytes is a WORD offset to the
RESOURCE.MAP where
entries for this resource type starts. The whole thing is terminated by
3-byte entry that has 0xFF as a type
and the offset points to the 1st byte after the list for the last resource
type. SCI1 first goes through this list
to find the start of list for the correct resource type and remember this
offset and the offset from the next entry
to know where it ends. Here it gets 2 offsets to RESOURCE.MAP indicating
start and end of array of 6-byte
structures, where the first WORD is the resource number 0-65535 and the
next DWORD contains RESOURCE
file number in the high 4 bits and offset in this file in the low 28 bits.
The header that precedes the compressed data in the RESOURCE.nn is also
different (to allow
resource numbers higher than 999) :
offset type meaning
----------------------------------------------
0 byte resource type (0x80 .. 0x91)
1 word compressed length
3 word uncompressed length
5 word compression method (???)
The method is usually 0x12 - the SCI1 engine of QFG1 VGA just checks it for
zero:
if zero do memcpy (uncompressed data) otherwise calls the decompression engine
that I don't understand.
>As for the decompression algorithms: Early versions of SCI1 use some of
>the algorithms we have implemented already (see
>src/scicore/decompress*.c). They also use an algorithm that has been
>implemented by Carl Muckenhoupt (should be in
>doc/misc/decrypt.c). Finally, later versions use an algorithm based on the
>PKWDCL library from PKware (Lars figured that one out). There is some
Ah, that makes a good sense. The decompression code looks like a foreign code
in the SCI.
>general discussion of and documentation for the related deflate algorithm
>in the Internet RFC 1951 (by Peter L. Deutsch). Related material can be
>found in RFCs 1950 (ZLIB) and 1952 (GZip). Nobody has managed to produce
>working decompression algorithm for Sierra's resources yet, though.
Maybe we can use the code from UnZip if it is the Deflate algorhitm ? At least
Deflate is patent-free as far as I know, unlike LZW used in SCI0 (method 1)
Petr
