aplib decompressor for ZX Basic.

[LCD]

Boride gets better and better. Going to add in aplib support too?

Thanks. Yes, I will...

[na_th_an]

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

[na_th_an]

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.

[boriel]

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

[na_th_an]

Nice to know

[slenkar]

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

[britlion]

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

[boriel]

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

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.

[britlion]

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

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

[boriel]

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

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

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.

[britlion]

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

[na_th_an]

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.

[britlion]

Just take the decompressing assembly, put it in an .asm file, and assemble it with pasmo :

I know :-) Being completely lazy

[britlion]

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.

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