Pattern Data Compression

[koilazka]

updated

Though id write about data compression.

Ive designed the ones below for Pattern Data.
This is a way of designing decompressor-compressors.
So you can write your own complex ones later.

You'll find it easier to follow if you can translate hex-bin without a calculator.

+8+4+2+1+8+4+2+1+8+4+2+1+8+4+2+1
1 0 1 1 1 0 1 0 1 1 0 1 0 0 0 1
$ _____b ______a ______d ______1

Pattern Data: 64 pixels, One pixel = 4bit colour.

B: Binary.
C: Condition.
X: Add.
S: Switch.


BBBB -> BBB

BBBB -> BBB: Limited Colour Compression: 8 colours
BBBB: cccccccccccccccc: 4bit
BBB: ccccccccxxxxxxxx: 3bit

BBBB -> BBB is limited to 8 Pallet colours.
Good if you have loads of Pattern that only use 8 colours.

BBB
000: 0
001: 1
010: 2
011: 3
100: 4
101: 5
110: 6
111: 7

BBBB -> BBB is quite clean, it has no padding, and no complex bit checking.
BBBB -> BBB will compress one 32bit Pattern line into a 24bit Pattern line.

Decompressed: 0001 0010 0011 0100 0101 0110 0111: 32bit 4byte
Compressed : _001 _010 _011 _100 _101 _110 _111: 24bit 3byte

So one complete pattern will be compressed from 32bytes to 24bytes.
This one is easy, i hope you get it, now for some complicated ones.


C vs CXXX

C vs CXXX: Limited Colour Compression: 9 colours
C___: cccccccccxxxxxxx: 1bit Compressed
CXXX: cccccccccxxxxxxx: 4bit Not

C vs CXXX is limited to 9 Pallet colours.
The first colour, Transparent, is compressed, the rest are Translated.
You can allways shift Pallet numbers around after they are decompressed.
So you can compress any colour you like.

CXXX
0___: 0
1000: 1+XXX
1001: 1+XXX
1010: 1+XXX
1011: 1+XXX
1100: 1+XXX
1101: 1+XXX
1110: 1+XXX
1111: 1+XXX

C vs CXXX will usually end with padding, the first bit is a Condition bit.
A pad is string of zeros at the end that fill the last byte.

___Hex Pattern: $01234567
___Bin Pattern: 0000 0001 0010 0011 0100 0101 0110 0111 ________32bit
Bin Compressed: ___0 1000 1001 1010 1011 1100 1101 1111 ________29bit
Bin Compressed: PPP0 1000 1001 1010 1011 1100 1101 1111 ________29bit + 3bit pad

Nooo it didnt compress.. :/
For C vs CXXX to compress, it needs compress >7 bits.
Heres an example with 3 Transprent pixels.

___Hex Pattern: $01204507
___Bin Pattern: 0000 0001 0010 0000 0100 0101 0000 0111 ________32bit
Bin Compressed: ___0 1000 1001 ___0 1011 1100 ___0 1111 ________23bit
Bin Compressed: ____ ____ P010 0010 0101 0111 1000 1111 ________23bit + 1bit pad

C vs CXXX compression size is variable, and you get an extra colour.


CC vs CCS

CC vs CCS: Limited Colour Compression: 7 colours
CC_: cccccccxxxxxxxxx: 2bit Compressed
CCS: cccccccxxxxxxxxx: 3bit Compressed

CC vs CCS is limited to 7 Pallet colours.
Every colour is compressed, only the Transparent colour is 2bit.

CCS
00_: 0 _: 0
010: 1+S: 1
100: 2+S: 2
110: 3+S: 3
011: 1+S: 4
101: 2+S: 5
111: 3+S: 6

S
0:0
1:3

CC vs CCS will usually end with padding, the first 2bits are Condition bits,
The last bit is Switch, Add 0 or 3.

___Hex Pattern: $01234560
___Bin Pattern: 0000 0001 0010 0011 0100 0101 0110 0111 ________32bit
Bin Compressed: __00 _010 _100 _110 _011 _101 _111 __00 ________22bit
Bin Compressed: ____ ____ PP00 0101 0011 0011 1011 1100 ________22bit + 2bit pad

C vs CXXX compression size is variable.
You get one less colour than BBBB -> BBB, and you get one super 2bit colour.


Loads more like, BBC vs BBCX, BC vs BCXX, etcetra, they become easy after a while.
Ive added a bbb compressor to the pattern program, mega drive decompressor included.