[A82] the compression
[Prev][Next][Index][Thread]
[A82] the compression
hi all again - i decided to just go and release the information on how this
compression format works because I need someone to write the encoder,
because it would be impossible (And impossibly slow) to do it in QuickBasic,
which is the only other language I know well besides Z80. Furthermore I've
written the decoder but I need help debugging it.
I also noticed that I haven't gotten replies on the first message mostly
because I know you all didn't believe me, thats OK I know it was a dumb
message but I just had to announce it! :D
Anyway, here's the format:
"header"
1 bit - 0 - tile has at least one repeated byte and at least one $FF or $00
1 - tile has no repeated bytes BUT at least one $FF or $00.
if 1st bit was 0 add these 2 bits:
00 - no compression because tile has no repeated/common bytes AND
no $FF's or $00's
01 - 1 "common" byte
00 = $00
01 = $FF
10 = byte0
11 = ??
10 - 2 "common" bytes
00 = $00
01 = $FF
10 = byte0
11 = byte1
11 - 4 "common" bytes
00 = byte0
01 = byte1
10 = byte2
11 = byte3
if header bits were:
000 - no common bytes
001 - 1 common byte goes here
010 - 2 common bytes go here
011 - 4 common bytes go here
then the bytes are listed
1 bit - 0 (raw) - next 8 bits are straight from the source
1 (common) - next 1 or 2 bits represent bytes as directed by the
header
If a tile is compressed using the “4 common byte” mode, each “chunk” is 2
bits instead of 3 because the “compressed”-bit is not needed because ALL the
bytes in that tile were encoded. Also, if the tile only has $FF’s and $00’s
but no other bytes that can be encoded, it’s 2 bits instead of 3 because the
2nd bit is used to say if its $FF or $00.
Please let me know if there are any confusions.
Note: This compression format isn't intended to work for ALL graphics data,
in fact if you tried to use it on a fullscreen image with lots of
information on it you would probably get 7:8 or worse because it relies on
bytes being reused only within 8 byte ranges, and also the number of $FF's
and $00's that exist in the set. However if we had the encoder we could test
it out and see how it performs. I derived this format by evaluating a couple
tilesets that I've finished for Metroid, and it just happens to work very
VERY well for Metroid, but we will just have to try and see if it will work
for other games. The nice thing about the format is that if a tile can't be
compressed at all or only has one $FF or $00 in it, you only lose 3 or 2
bits, respectively. So, the advantage outweighs the disadvantage, because
say if the tile has TWO $FF's and/or $00's, the tile loses 5 bits! So let me
know what you all think of this. Anyone who wants to help by writing the
encoder, please e-mail me and I'll give you the info on how it should work,
to save you the trouble of racking your brains over it. We will share the
credit.
- Roger
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com