Forums

I guess I care about the Sega systems first, but I'll have the fallback hidden behind a .define so people can choose. My stuff is very WLA DX specific anyway so just likely people will need to alter it as needed. The main thing I'm adding is the VRAM targeting.

Latest decompressors are now up. Here's a comparison graph:

benchmark.png (63.66 KB)

What kind of data was compressed? Graphics? Tilemaps? Code?

Viewing the results, It seems, to me, zx7 is the clear winner here, as It has one of the best compressions ratio, with almost no RAM usage, smaller Code size and good overal time.....

As an z88dk developer who uses the free RAM to run zx7 compressed Code, i Must include zx7 functions, being a killer feature favoring the zx7 flavor.

This is only compressing a single tile set. Across a whole game you'd have a lot more, plus non graphics data, but I'm assuming tile data is the majority of the compressible data, not least because you can decompress into 16KB of VRAM and only 8KB of RAM.

Across a whole game, it may be possible that aPLib can compress better, and use fewer bytes overall. But ZX7 seems to mainly win by being designed for fast decoding on a Z80, which really helps.

Compressing code is weird... I guess it's a workaround for the limitations on using paged code in SDCC.

Maybe compressing Code is weird, but It helps me to have about 3kb more for Code without bank switch troubles with z88dk, so, while i learn assembly, It is a good solution for bigger ANSI c Code generation.

nice graph. it shows pretty clearly which compression schemes are less interesting, IMO

@eruiz: whatever works for you it's OK, but in case you can't spend 3 KB of RAM for code or if you need more code space, check my other topic about bank switching for code. It might interest you :)

Maxim wrote

I'm putting everything here: https://github.com/maxim-zhao/bmp2tilecompressors/tree/master/decompressors

Thanks! I took your "aPLib decompressor (fast).asm" and placed it into UNSAFE_SMS_loadaPLibcompressedTiles (of course after placing some DI/EI around the usual places and after a small fight with those pesky ixh/iyh/iyl register access... I had to swap them for the corresponding h/l register and prefix them with a byte, as in here...).

But it just works perfectly! :)

On real hardware? Screen on or off?

just like ZX7, it's the version for screen OFF. I suspect there isn't much demand for the screen ON version (but I might be wrong)

just stumbled upon this:

; Make hl a read address
ld a,h
xor $40
ld h,a

( https://github.com/maxim-zhao/bmp2tilecompressors/blob/master/decompressors/aPLi... )

is there any reason I'm missing why this can't be replaced with a simple

res 6,h

? (I mean, that XOR puzzles me...)

No - I have made that change in my version, I missed it when I pushed.

OK thanks - fixed mine too.

Actually it looks like my push is not there :) the timestamps are too old. I'll give it another go later.
Edit: done. This also includes an optional screen-on version of the ZX7 decompressor, as shown in the graph above.

It surprises me that Sonic1 compression is so effective. Couldn't anybody improve and optimize that further? I know, for example, that it works on chunky tile rows and you might get better compression using bit planes because it is more likely that rows of pixels share bit-planes more often across the entire tileset than rows of coloured pixels.

Resurrecting this thread, I've added two new implementations of the aPLib compressor which achieve better compression by spending a little (apultra, https://github.com/emmanuel-marty/apultra ) or a lot (oapack, https://gitlab.com/eugene77/oapack ) more CPU and RAM on the compression. The result is 2-3% smaller files than the official aPLib compressor. Note that it's still a bit of a trade-off between compressed data size and decompression speed. Also, I haven't actually tested the compressed output yet...

https://github.com/maxim-zhao/bmp2tilecompressors/releases/tag/Build-29

I also need to re-do the performance tests using the "fast aPLib" decompressor.

Author	Message
Maxim Site Admin Joined: 19 Oct 1999 Posts: 13493 Location: London	Posted: Fri Feb 09, 2018 8:06 pm
	I guess I care about the Sega systems first, but I'll have the fallback hidden behind a .define so people can choose. My stuff is very WLA DX specific anyway so just likely people will need to alter it as needed. The main thing I'm adding is the VRAM targeting.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13493 Location: London	Posted: Sat Feb 10, 2018 10:08 am
	Latest decompressors are now up. Here's a comparison graph: benchmark.png (63.66 KB)

eruiz00 Joined: 28 Jan 2017 Posts: 388 Location: Málaga, Spain	Posted: Sat Feb 10, 2018 2:27 pm
	What kind of data was compressed? Graphics? Tilemaps? Code? Viewing the results, It seems, to me, zx7 is the clear winner here, as It has one of the best compressions ratio, with almost no RAM usage, smaller Code size and good overal time..... As an z88dk developer who uses the free RAM to run zx7 compressed Code, i Must include zx7 functions, being a killer feature favoring the zx7 flavor.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13493 Location: London	Posted: Sat Feb 10, 2018 6:48 pm
	This is only compressing a single tile set. Across a whole game you'd have a lot more, plus non graphics data, but I'm assuming tile data is the majority of the compressible data, not least because you can decompress into 16KB of VRAM and only 8KB of RAM. Across a whole game, it may be possible that aPLib can compress better, and use fewer bytes overall. But ZX7 seems to mainly win by being designed for fast decoding on a Z80, which really helps. Compressing code is weird... I guess it's a workaround for the limitations on using paged code in SDCC.

eruiz00 Joined: 28 Jan 2017 Posts: 388 Location: Málaga, Spain	Posted: Sat Feb 10, 2018 8:03 pm
	Maybe compressing Code is weird, but It helps me to have about 3kb more for Code without bank switch troubles with z88dk, so, while i learn assembly, It is a good solution for bigger ANSI c Code generation.

sverx Joined: 05 Sep 2013 Posts: 2806	Posted: Sun Feb 11, 2018 10:34 am
sverx Joined: 05 Sep 2013 Posts: 2806	nice graph. it shows pretty clearly which compression schemes are less interesting, IMO @eruiz: whatever works for you it's OK, but in case you can't spend 3 KB of RAM for code or if you need more code space, check my other topic about bank switching for code. It might interest you :)

sverx Joined: 05 Sep 2013 Posts: 2806	Posted: Mon Feb 12, 2018 11:01 am
sverx Joined: 05 Sep 2013 Posts: 2806	Maxim wrote I'm putting everything here: https://github.com/maxim-zhao/bmp2tilecompressors/tree/master/decompressors Thanks! I took your "aPLib decompressor (fast).asm" and placed it into UNSAFE_SMS_loadaPLibcompressedTiles (of course after placing some DI/EI around the usual places and after a small fight with those pesky ixh/iyh/iyl register access... I had to swap them for the corresponding h/l register and prefix them with a byte, as in here...). But it just works perfectly! :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13493 Location: London	Posted: Mon Feb 12, 2018 12:44 pm
	On real hardware? Screen on or off?

sverx Joined: 05 Sep 2013 Posts: 2806	Posted: Mon Feb 12, 2018 12:47 pm
sverx Joined: 05 Sep 2013 Posts: 2806	just like ZX7, it's the version for screen OFF. I suspect there isn't much demand for the screen ON version (but I might be wrong)

sverx Joined: 05 Sep 2013 Posts: 2806	Posted: Tue Feb 13, 2018 10:31 am
sverx Joined: 05 Sep 2013 Posts: 2806	just stumbled upon this: ; Make hl a read address ld a,h xor $40 ld h,a ( https://github.com/maxim-zhao/bmp2tilecompressors/blob/master/decompressors/aPLi... ) is there any reason I'm missing why this can't be replaced with a simple res 6,h ? (I mean, that XOR puzzles me...)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13493 Location: London	Posted: Tue Feb 13, 2018 1:19 pm
	No - I have made that change in my version, I missed it when I pushed.

sverx Joined: 05 Sep 2013 Posts: 2806	Posted: Tue Feb 13, 2018 2:33 pm
sverx Joined: 05 Sep 2013 Posts: 2806	OK thanks - fixed mine too.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13493 Location: London	Posted: Tue Feb 13, 2018 8:13 pm
	Actually it looks like my push is not there :) the timestamps are too old. I'll give it another go later. Edit: done. This also includes an optional screen-on version of the ZX7 decompressor, as shown in the graph above.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Feb 16, 2018 9:03 pm
Kroc Joined: 08 Dec 2013 Posts: 200	It surprises me that Sonic1 compression is so effective. Couldn't anybody improve and optimize that further? I know, for example, that it works on chunky tile rows and you might get better compression using bit planes because it is more likely that rows of pixels share bit-planes more often across the entire tileset than rows of coloured pixels.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13493 Location: London	Posted: Sat Jul 11, 2020 9:14 pm
	Resurrecting this thread, I've added two new implementations of the aPLib compressor which achieve better compression by spending a little (apultra, https://github.com/emmanuel-marty/apultra ) or a lot (oapack, https://gitlab.com/eugene77/oapack ) more CPU and RAM on the compression. The result is 2-3% smaller files than the official aPLib compressor. Note that it's still a bit of a trade-off between compressed data size and decompression speed. Also, I haven't actually tested the compressed output yet... https://github.com/maxim-zhao/bmp2tilecompressors/releases/tag/Build-29 I also need to re-do the performance tests using the "fast aPLib" decompressor.

Forums

View topic - BMP2Tile new compressors (was: ZX7 support in BMP2Tile)