From 7ac76fb4e4117887f6fd80ca7d6659be88209313 Mon Sep 17 00:00:00 2001 From: "B. Watson" Date: Wed, 6 Jan 2016 17:38:48 -0500 Subject: finishing touches of compression, attempt to fix damage calc issue --- titlecompression.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'titlecompression.txt') diff --git a/titlecompression.txt b/titlecompression.txt index 5f6bf3f..9c30232 100644 --- a/titlecompression.txt +++ b/titlecompression.txt @@ -22,6 +22,27 @@ likely to have large areas of all 0 bytes, but e.g. it can't compress an ASCII or ATASCII text file at all (because there are pretty much never any null bytes in a human-readable text file). +Apologia: +--------- + +I'm aware that cc65 has a zlib implementation, but it doesn't quite meet +the requirements: it's slow, large (linking it adds 781 bytes to the +executable size), and the best DEFLATE compression I could manage for +my title screen was 2806 bytes (using 7z). Add to that the 781 bytes of +zlib code and the other required libs for a C program, and I end up with +something like a 65% compression ratio (since I'm counting the code size +as part of the file size), and it takes 2/3 of a second to decompress. So, +it meets one of my requirements, but not all of them. Which should not be +taken as a criticism of cc65's zlib implementation: It's amazingly small, +efficient, and easy to use. It's just that deflate is a general-purpose +compression algorithm, and I thought I could do a better job with a +purpose-built one... which I think I've done. + +I didn't know exomizer existed, before I started on my compression scheme. +If I'd known, and if I'd tried it out, I probably would have just used +it instead. It has a better compression ratio (55% for my title screen, +including decomp code) and decompresses fast enough. + Theory of operation: -------------------- -- cgit v1.2.3