Hi Petr,
On Sun, 19 Nov 2000, Petr Vyhnak wrote:
> 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:
(Actually, lower values are used in earlier versions of SCI1, AFAIK).
> >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 ?
I tried using some of the zlib functions, but none of them worked. There's
quite a number of custom functions that might help here, though
(I'm not really working on SCI1 anyway, except for a separate project).
As for unzip: AFAIK, not all of the code contained therein is compatible
with the GPL, which means that we might have to re-implement some of it if
it turns out that unzip is suited for this compression scheme.
> At least
> Deflate is patent-free as far as I know, unlike LZW used in SCI0 (method 1)
Note that lzw decompression has been patented by Unisys for programs
or sets of programs that perform both compression and
decompression; stand-alone decompression programs are not covered by
this. (Unisys claims otherwise; AFAIK, the issue has not yet been tested
in court).
llap,
Christoph
