Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
aplib decompressor for ZX Basic.
#16
britlion Wrote:Boride gets better and better. Going to add in aplib support too? Smile
Thanks. Yes, I will...
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#17
britlion Wrote:
na_th_an Wrote:1. Download the compressor -> <!-- m --><a class="postlink" href="http://www.mojontwins.com/warehouse/apack.exe">http://www.mojontwins.com/warehouse/apack.exe</a><!-- m -->

I don't think this link is working, Na_th_an?

Sorry, it looks like our server is blocking exe files. Aw.

I zipped it, this should work: <!-- m --><a class="postlink" href="http://www.mojontwins.com/warehouse/apack.zip">http://www.mojontwins.com/warehouse/apack.zip</a><!-- m -->

Editting first post in progress Smile
Reply
#18
slenkar Wrote:thanks for the explanation,

how is @mapdata first defined? is it an array,a memory address?

"mapdata" is a label, look at the code. It marks a "spot" in memory. Just afterwards, you have an "asm - end asm" block which includes a defs "command" which is just defining 2400 zeroes.

So @mapdata is the address of such space with 2400 zeroes where compressed maps will decompress in my example. Think of it like an unsigned byte array:

Code:
Dim mapdata (2399) as uByte

I think that would be exactly the same thing.
Reply
#19
na_th_an Wrote:
slenkar Wrote:thanks for the explanation,

how is @mapdata first defined? is it an array,a memory address?

"mapdata" is a label, look at the code. It marks a "spot" in memory. Just afterwards, you have an "asm - end asm" block which includes a defs "command" which is just defining 2400 zeroes.

So @mapdata is the address of such space with 2400 zeroes where compressed maps will decompress in my example. Think of it like an unsigned byte array:

Code:
Dim mapdata (2399) as uByte

I think that would be exactly the same thing.
Arrays uses an extra binary data header. To obtain the address of the first element, use @mapdata(0) instead ;-)
Reply
#20
Nice to know Smile
Reply
#21
na_th_an Wrote:
slenkar Wrote:thanks for the explanation,

how is @mapdata first defined? is it an array,a memory address?

"mapdata" is a label, look at the code. It marks a "spot" in memory. Just afterwards, you have an "asm - end asm" block which includes a defs "command" which is just defining 2400 zeroes.

So @mapdata is the address of such space with 2400 zeroes where compressed maps will decompress in my example. Think of it like an unsigned byte array:

Code:
Dim mapdata (2399) as uByte

I think that would be exactly the same thing.


this will be useful for an R-Type or double dragon game with lots of scrolling background graphics
Reply
#22
I did some tests. Aplib is slightly better at compression than MegaLZ. On average. Not always - text seems to be a weakness, with MegaLZ winning for one of my text tests.

The difference is very thin, however. How big is the decompressor in bytes, is the next question. Compared to MegaLZ. If it's the same size or smaller, Aplib is probably always the right choice. If it's bigger...you've got a dilemma Smile
Reply
#23
britlion Wrote:I did some tests. Aplib is slightly better at compression than MegaLZ. On average. Not always - text seems to be a weakness, with MegaLZ winning for one of my text tests.

The difference is very thin, however. How big is the decompressor in bytes, is the next question. Compared to MegaLZ. If it's the same size or smaller, Aplib is probably always the right choice. If it's bigger...you've got a dilemma Smile
From the compiler point of view, I will include both of them. The user must then try packing the binary data with both compressors and choose the smallest result, IMHO.
Reply
#24
boriel Wrote:
britlion Wrote:I did some tests. Aplib is slightly better at compression than MegaLZ. On average. Not always - text seems to be a weakness, with MegaLZ winning for one of my text tests.

The difference is very thin, however. How big is the decompressor in bytes, is the next question. Compared to MegaLZ. If it's the same size or smaller, Aplib is probably always the right choice. If it's bigger...you've got a dilemma Smile
From the compiler point of view, I will include both of them. The user must then try packing the binary data with both compressors and choose the smallest result, IMHO.

Surely if one decompressor is larger, you have to take that into account?

10 bytes smaller for data, and 100 bytes larger for decompressor isn't a win Smile
Reply
#25
britlion Wrote:
boriel Wrote:
britlion Wrote:I did some tests. Aplib is slightly better at compression than MegaLZ. On average. Not always - text seems to be a weakness, with MegaLZ winning for one of my text tests.

The difference is very thin, however. How big is the decompressor in bytes, is the next question. Compared to MegaLZ. If it's the same size or smaller, Aplib is probably always the right choice. If it's bigger...you've got a dilemma Smile
From the compiler point of view, I will include both of them. The user must then try packing the binary data with both compressors and choose the smallest result, IMHO.

Surely if one decompressor is larger, you have to take that into account?

10 bytes smaller for data, and 100 bytes larger for decompressor isn't a win Smile
That's right. The programmer must keep this trade-off in mind. But I think we must left this decision on the programmer's side, and include both libraries.
Reply
#26
boriel Wrote:That's right. The programmer must keep this trade-off in mind. But I think we must left this decision on the programmer's side, and include both libraries.

I completely agree - I was just asking if anyone had the relative sizes of the decompressor code handy...
Reply
#27
Just take the decompressing assembly, put it in an .asm file, and assemble it with pasmo :

The decompressor looks complicated. It's probably big. But it's not very slow and has always floated my boat. In combination with RAM paging it makes wonders (Maritrini is about 215K of uncompressed map data and graphics fit in less than 96K).

By the way, off-topic... I believe the graphic library we developed for Maritrini could be easily adapted to work in a ZXBasic program.
Reply
#28
na_th_an Wrote:Just take the decompressing assembly, put it in an .asm file, and assemble it with pasmo :

I know :-) Being completely lazy Smile
Reply
#29
na_th_an Wrote:J

By the way, off-topic... I believe the graphic library we developed for Maritrini could be easily adapted to work in a ZXBasic program.

You know, we never heard back from na_th_an about this one. Sad

We need more graphics engine type things. An easily accessible sprite library would be pretty epic.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)