SpritesMind.Net

Alright. The converter already supports converting to linear data before compressing, I just haven't documented it in the manual since I haven't written a decoder yet that converts the unpacked linear data back to planar. The option to use is -chain.

The converter can now compress graphics data using aPLib (use -codec aplib). So far I've only included an aPLib decruncher for the SH2 (32X). My decruncher is 236 bytes in size, so there's probably room for some optimization.

If you use SyX's decruncher for the M68000 with data generated by my converter you'll have to remove the line at the beginning of his code that says lea (24,a0),a0 since my converter doesn't add any kind of header to the compressed data.

http://jiggawatt.org/badc0de/sixpack/

Hi mic_!!!
I'm testing your Sixpack, and i like it

If you want it, fell free to include my version of the aPLib decruncher for MC68000 in it (with the modification that you comment for the lea (24,a0),a0).
And i think that my friend Metalbrain will not matter that you include his z80 version of the aPLib decruncher, i could ask him about it, if you like.

Sounds like a good idea. If you get the z80 code you can mail it to me and I'll add it along with your 68k code. The address is in the sixpack manual.

I've released a new version with SyX's and Metalbrain's aPLib decoders for the 68k/z80.

http://jiggawatt.org/badc0de/sixpack/

Nice!!!

We only need a 65816 version, anybody?? The Glory awaits!!!

I might take a stab at translating the z80 code to 65816 sometime.

I've updated Sixpack today. The two additions in this version is an aPLib decruncher for the 65816 (SNES) and a PackFire tiny mode decoder for the SH2 (32X). PackFire's tiny mode usually performs better than both aPLib and LZSS, but it can't compress files of any size.

http://jiggawatt.org/badc0de/sixpack/

Great Work mic_!!! ... I need some of free time to test it!!!

There's a new version available. Nothing new on the Sega front this time, but I've added an apLib decruncher for the HuC6280 (TurboGrafx), as well as an example program.

http://jiggawatt.org/badc0de/sixpack/

mic_ wrote:Alright. The converter already supports converting to linear data before compressing, I just haven't documented it in the manual since I haven't written a decoder yet that converts the unpacked linear data back to planar. The option to use is -chain.

I've finally implemented support for this mode in the decompressors. Though only for apLib decrunchers so far, and only for SNES and TurboGrafx.


I've also added an aplib_decrunch_vram routine for the TurboGrafx that decrunches to VRAM instead of RAM. It's pretty slow because of how the VDC buffers VRAM accesses, but it has the advantage of letting you decrunch more than 8kB of tiles data at once.

Both the SNES and TurboGrafx apLib decrunchers have also been optmized to make use of block move instructions (TII on TurboGrafx, MVN on SNES).

http://jiggawatt.org/badc0de/sixpack/

What's the sliding window foot print in ram, for decompressing directly to vram?

tomaitheous wrote:What's the sliding window foot print in ram, for decompressing directly to vram?

Zero. I've only written an aPLib decruncher for the TurboGrafx - no LZSS.
It uses some ZP variables of course, but no window/buffer. The only buffer involved is if you use the linear-to-planar post-processing routine, which uses a 32-byte buffer in ZP RAM.

Ohh. I thought aPLib was based on LZSS scheme. Didn't realize that.

New developer question here.

I've used sixpack to encode a 256-color, 64 X 136 px, bitmap to display once on a 32X screen using the following options:

-pack -height 136 -width 64 -image -preview prev.bmp -format l8 -q 256 -opt -sizefilter 1 -target 32x

(The preview bmp looks very similar to my source.)

I built my C code using the demo 32x's lzss_decode.s and lzss_decode.h

Now, it may be my ignorance overall:

What I get in my emulator is a very squashed image, with the image repeated 5 times across the screen horizontally. Each image in the row is about the right width 64px but height is like 45 px.

So I guess, I can see you specify the offset in framebuffer when calling lzss_decode(), and I can move the row of images vertically around the screen, but should I not be using the lzss_decode directly? Or did I do something wrong in the encoding of the image to lszz so that it repeats across each line?