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
>>
>