Tile compression
Moderator: BigEvilCorporation
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/
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.
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.
I've released a new version with SyX's and Metalbrain's aPLib decoders for the 68k/z80.
http://jiggawatt.org/badc0de/sixpack/
http://jiggawatt.org/badc0de/sixpack/
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/
http://jiggawatt.org/badc0de/sixpack/
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/
http://jiggawatt.org/badc0de/sixpack/
I've finally implemented support for this mode in the decompressors. Though only for apLib decrunchers so far, and only for SNES and TurboGrafx.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 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/
-
- Very interested
- Posts: 256
- Joined: Tue Sep 11, 2007 9:10 pm
Zero. I've only written an aPLib decruncher for the TurboGrafx - no LZSS.tomaitheous wrote:What's the sliding window foot print in ram, for decompressing directly to vram?
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.
-
- Very interested
- Posts: 256
- Joined: Tue Sep 11, 2007 9:10 pm
-
- Very interested
- Posts: 124
- Joined: Sun Jan 29, 2012 2:10 pm
- Location: North America
- Contact:
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?
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?
Last edited by ammianus on Wed Feb 08, 2012 2:48 am, edited 1 time in total.