|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Goto page Previous 1, 2 |
Author | Message |
---|---|
|
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. | |
|
Posted: Sat Feb 10, 2018 10:08 am |
Latest decompressors are now up. Here's a comparison graph:
|
|
|
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. |
|
|
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. |
|
|
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. | |
|
Posted: Sun Feb 11, 2018 10:34 am |
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 :) |
|
|
Posted: Mon Feb 12, 2018 11:01 am |
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! :) |
|
|
Posted: Mon Feb 12, 2018 12:44 pm |
On real hardware? Screen on or off? | |
|
Posted: Mon Feb 12, 2018 12:47 pm |
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) | |
|
Posted: Tue Feb 13, 2018 10:31 am |
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...) |
|
|
Posted: Tue Feb 13, 2018 1:19 pm |
No - I have made that change in my version, I missed it when I pushed. | |
|
Posted: Tue Feb 13, 2018 2:33 pm |
OK thanks - fixed mine too. | |
|
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. |
|
|
Posted: Fri Feb 16, 2018 9:03 pm |
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. | |
|
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. |
|
|
LZSA1, LZSA2, ZX0 compression, other updates
Posted: Thu Aug 19, 2021 9:24 pm
|
I've recently added support for the new-ish ZX0 compression library, and not so recently added LZSA and LZSA2, coming from other retro computing authors. I've also collected updates to some of the libraries and collated some more stars on the various libraries.
https://github.com/maxim-zhao/bmp2tilecompressors |
|
Goto page Previous 1, 2 |