finishing touches of compression, attempt to fix damage calc issue

1 files changed, 21 insertions, 0 deletions

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:
 --------------------