A86: Re: Saving Memory

[Prev][Next][Index][Thread]

A86: Re: Saving Memory


Well, if they're all going to look like that, then all you need is two
bytes!  If your levels (which I assume they are for a Vexed like game) are
going to have alot of repeats, the RLE compression would be the best choice.

RLE or Run-Length-Encoding is probably the simplest and easiest compression
scheme to implement.  This is the format that PCX files use.  The idea of it
is to reduce "runs" of repeated bytes into a single set of bytes.  Here's an
example:

.db 1,1,1,1,1,3,4,1,3

could be compressed to

.db $ff,5,1,3,4,1,3

What happened here is the run of 1's were reduced to the "run indicator
byte" ($ff), followed by the run length (5), ending with the actual byte
value (1).  Granted it's not alot (only 2 bytes), but it is much more if the
runs are longer (such as in graphics like title screens).  If the byte isn't
a run, it is encoded as normal (as itself).

This is the method that my title screen compressor, Pic2RLE uses.  I use the
byte $91 as the indicator byte because it doesn't seem to appear very often
in pictures.  What if the byte IS $ff?  Then you encode it as a run of 1.
Since a run takes 3 bytes, it doesn't make sense to encode a run of 2 bytes
as a run, so you encode them as single bytes.  But the value $ff won't come
up often in your levels, if at all.  Bringing up something else...

I'm going to guess that you don't have 256 tiles (sprites) in your game.
Therefore, $ff will never be used.  You probably don't have more than 100 or
so, if that many (I'm guessing maybe 25-30).  So instead of wasting a byte
for the run indicator, that byte could actually do something useful.

For runs, the byte value would start at $80.  This would be a run of 0 (or
you could make it 3 or whatever, but we will say $80 = 0 for simplicity
sake).  If the run is 8 bytes of value 3, then it would be encoded as

.db $88, 3

When decompressing it, if you find something less than $80, then it is the
actual byte value.  If it is greater than $80, then subtract $80 (actually
just mask off the highest bit with AND %01111111...) to get the length, then
read the next byte to get the byte value.

Now, if you only have 16 tiles, then you could store the values using
nibbles (4 bits, half a byte), effectively getting double compression
without actually doing any compression.  This could be added with RLE (the
first method) for great compression results.  This could also be applied if
the data set is limited to any power of two (for < 64, you could use 6
bits), but using something other than nibbles (since there are nibble or BCD
[binary coded decimal, numbers that look decimal when printed in hex...]
instructions for just this purpose) might cause your decompression routines
to be bigger than the original data was.

If you need help, email me.  The source code to the compressor and
decompressor are included in Pic2RLE and aren't too hard to figure out,
either.  Then there's always the vast internet filled with info about
everything except what you need, though you will find it by accident a week
after you needed it...

--
David Phillips <electrum@tfs.net>
ICQ: 13811951
AOL/AIM: Electrum32
86 Central: http://www.tfs.net/~electrum/

-----Original Message-----
From: Ahmed El-Helw <ahmed@ticalc.org>
To: assembly-86@lists.ticalc.org <assembly-86@lists.ticalc.org>
Date: Sunday, November 15, 1998 2:22 PM
Subject: A86: Saving Memory


>
>Hello,
>    I was working on Brix and thinking about this.. my maps in Brix are
like
>this:
>
>Level:
>.db 1,1,1,1,1,1,1,1,1,1,1,1,1
>.db 1,1,1,1,1,1,1,1,1,1,1,1,1
> .db 1,1,1,1,1,1,1,1,1,1,1,1,1
> .db 1,1,1,1,1,1,1,1,1,1,1,1,1
> .db 1,1,1,1,1,1,1,1,1,1,1,1,1
> .db 1,1,1,1,1,1,1,1,1,1,1,1,1
> .db 1,1,1,1,1,1,1,1,1,1,1,1,1
> .db 1,1,1,1,1,1,1,1,1,1,1,1,1
>
>which is 88 bytes [8x11, 11 sprites horizontally..]  each number represents
>a sprite [ex. 1=block, 2=....]  there is a way to compress them, but I am
>not sure how to.. any suggestions? Thanks.
>-Ahmed
>
>
>Ahmed El-Helw <ahmed@ticalc.org>
>   Program Ideas and Upcoming Programs
>   the ticalc.org project - http://www.ticalc.org/
>________________________________________
>http://hail.icestorm.com/asm/
>ICQ: 3350394