Tile compression
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Sounds like you forgot to add the screen width for each line you progress. That's why it repeats horizontally. When you reach the end of the line you are drawing/filling, you have to skip all the remaining pixels in that line of the framebuffer. That's also why it's not taller - you're using up all the lines by not advancing the line pointer correctly.
-
- Very interested
- Posts: 124
- Joined: Sun Jan 29, 2012 2:10 pm
- Location: North America
- Contact:
Ah you're right, the images are slightly different too. Time to review that assembly file, it doesn't seem to have any reference to the width of the image, I think it was written in anticipation of painting the entire screen with an image.Chilly Willy wrote:Sounds like you forgot to add the screen width for each line you progress. That's why it repeats horizontally. When you reach the end of the line you are drawing/filling, you have to skip all the remaining pixels in that line of the framebuffer. That's also why it's not taller - you're using up all the lines by not advancing the line pointer correctly.
-
- Very interested
- Posts: 124
- Joined: Sun Jan 29, 2012 2:10 pm
- Location: North America
- Contact:
I couldn't figure out the assembly code in lzss_decode.s well enough to try to modify how it wrapped lines. If _mic could explain how it works (or where we could add in a width/height argument) that would be helpful
But I created a workaround in C where I use the decode function to write to my own buffer in memory which I then manually transfer to the Framebuffer. It worked, but I guess this is a wasteful way to do this?
I have a non-related question about the sixpack tool however. If I have 5 images with similar colors (ie animations of 1 character), do I have to generate different palettes for each one? What I seem to get is that the palettes are mixed up for each separate image, so I have to switch palettes for each frame of my animation for it to look right. Is there any way to control this behavior in sixpack so that it encodes using a fixed set of colors?
I saw the -base option, but not sure what the numbers would be for the generated images? How do you know what is the index?
But I created a workaround in C where I use the decode function to write to my own buffer in memory which I then manually transfer to the Framebuffer. It worked, but I guess this is a wasteful way to do this?
I have a non-related question about the sixpack tool however. If I have 5 images with similar colors (ie animations of 1 character), do I have to generate different palettes for each one? What I seem to get is that the palettes are mixed up for each separate image, so I have to switch palettes for each frame of my animation for it to look right. Is there any way to control this behavior in sixpack so that it encodes using a fixed set of colors?
I saw the -base option, but not sure what the numbers would be for the generated images? How do you know what is the index?
Sure, but I want pack without a header. Can u create modified windows console or gui version?mic_ wrote:I never added support for any other codecs except LZSS when compressing non-images, which is why nothing happens when you try to do thatsixpack.exe -pack -codec aplib filename.ext -< doesn't work
nothing happens
There's a tool on the aPLib webpage that you can use for packing ordinary files.
-
- Very interested
- Posts: 124
- Joined: Sun Jan 29, 2012 2:10 pm
- Location: North America
- Contact:
I ran into this issue while using the sample 32X decoder for lzss provided by sixpack, not sure if it affects anyone else.
At the bottom of lzss_decode.s there are some declarations
After using this for a long time in my own game demo, I noticed the odd occasional time where it seemed one of my variables would be corrupted. I assumed this was me just making mistakes. As I was debugging some other memory and alignment issues I noticed that the _text_buf in my binary's map file was always immediately proceeding the shared variables that were being corrupted.
So I suspected that the decleration of the "buf_pos_mask:" of length 4095 had something to do with it.
I am not an assembly programmer, so I tried changing the last line to this:
This solved the corruption issue I was seeing of the following object in COMMON e.g. foregroundObjects in above output.map. lzss decoding still seems to work correctly.
This was a tricky one to diagnose, I am not sure if I am wrong about the fix, but definitely the length of 4078 was causing problems.
At the bottom of lzss_decode.s there are some declarations
Code: Select all
.align 2
text_buf:
.long _text_buf
N_minus_F:
.short 4078
buf_pos_mask:
.short 4095
.comm _text_buf,4078,4
Code: Select all
*(COMMON)
COMMON 0x0000000006002168 0x28 main.o
0x0000000006002168 BG_ObjectSprites
COMMON 0x0000000006002190 0xfee lzss_decode.o
0x0000000006002190 text_buf
*fill* 0x000000000600317e 0x2 00
COMMON 0x0000000006003180 0x1b180 shared_objects.o
0x0000000006003180 foregroundObjects
I am not an assembly programmer, so I tried changing the last line to this:
Code: Select all
.comm _text_buf,4096,4
This was a tricky one to diagnose, I am not sure if I am wrong about the fix, but definitely the length of 4078 was causing problems.
Hmm, yeah that does indeed look like a bug. I can't remember why I only reserved 4078 bytes for the buffer as it's been a couple of years since I wrote that code. Perhaps I planned to allocate the lookahead buffer separately but forgot to do so.
In any case, your fix looks correct to me. And this should only affect the SH2 version of the LZSS decoder, since it's the only one that does explicit allocation of buffers.
In any case, your fix looks correct to me. And this should only affect the SH2 version of the LZSS decoder, since it's the only one that does explicit allocation of buffers.