Re: A86: Saving Memory


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

Re: A86: Saving Memory




well, I guess I will look at those, but isn't there a way to do something in
which you can extract the first and second bite - ex:

.db $11, $12, $15, ...

would make the entire screen 44 bytes, wouldn't it?
and then how would i get the sprite number into a?

I think that since most coding is done, I should try to find something that
compresses the levels and end of story on that.

-Ahmed

-----Original Message-----
From: Dave <scheltem@aaps.k12.mi.us>
To: assembly-86@lists.ticalc.org <assembly-86@lists.ticalc.org>
Date: Sunday, November 15, 1998 3:43 PM
Subject: Re: A86: Saving Memory


>
>Truly all you need for compression is an algorithm that will shorten the
>length of the code by performing tasks on it.  It should not be that big of
>a deal to do if you have a good algorithm.  Like JBrett said those are some
>of the most commonly used algorithms used for compression.
>Dave
>_____________________________________________
>ACZ
>assembly coders zenith member
>e-mail: scheltem@aaps.k12.mi.us
>ICQ #16817590
>-----Original Message-----
>From: Thomas J. Hruska <thruska@tir.com>
>To: assembly-86@lists.ticalc.org <assembly-86@lists.ticalc.org>
>Date: Sunday, November 15, 1998 12:28 PM
>Subject: Re: A86: Saving Memory
>
>
>>
>>At 03:09 PM 11/15/98 -0500, you wrote:
>>>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
>>
>>There are two different ways to compress your levels.  Both ways use a
>>buffer to extract the level into, but most of the time the program is made
>>smaller.  I personally like to use the PCX format to compress my levels
>>since it is easier to understand.  HUFFLIB (I think this is the right
name)
>>compression is the other technique which is said to work better.  I've
>>never tested the library since it is not for the 82 platform (which is the
>>platform I use).  If you want to take the time to convert my PCX-like
>>loader over to the 86, then I'll send the code to you in its current
state.
>> I use a much more advanced loader system than what you need it for, but
it
>>will work none-the-less.  Under the current code, your level would have to
>>look like this:
>>
>>NumLevels:
>>.db 1
>>
>>Level1:
>>.db 8, 8
>>.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,255
>>.dw Level2
>>  ret
>>
>>Level2:
>>
>>
>>I know the level is not compressed (I'm too lazy I guess), but you see why
>>you would need to change the code.  The current game engine that I'm
>>developing copies the level into the buffer (in this case it would be 8 *
8
>>= 64 bytes needed) and runs the code following the level (allows for easy
>>custom level development...notice the ret).  Well, I hope this helps.
>>
>>
>>                 Thomas J. Hruska -- thruska@tir.com
>>Shining Light Productions -- "Meeting the needs of fellow programmers"
>>         http://www.geocities.com/SiliconValley/Heights/8504
>>                    http://shinelight.home.ml.org
>>
>