[A82] Re: the compression
[Prev][Next][Index][Thread]
[A82] Re: the compression
So, how to compress these bricks?
.db %11111111
.db %10000000
.db %10000000
.db %10000000
.db %11111111
.db %00001000
.db %00001000
.db %00001000
.db %11110111
.db %00000111
.db %01111111
.db %01100011
.db %01111111
.db %01110000
.db %11110111
.db %00110110
(the first one looks EXTREMELY compressable)
>From: "Roger Levy" <trip_n_save@hotmail.com>
>Reply-To: assembly-82@lists.ticalc.org
>To: assembly-82@lists.ticalc.org
>Subject: [A82] the compression
>Date: Sat, 24 Feb 2001 14:48:35 -0000
>
>
>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
>
>
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com