Tile compression

[Chilly Willy]

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.

[ammianus]

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.

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.

[ammianus]

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?

[Ti_]

sixpack.exe -pack -codec lzzs filename.ext -< works
creates a file "filename.ext.lzs"

but
sixpack.exe -pack -codec aplib filename.ext -< doesn't work
nothing happens

[mic_]

sixpack.exe -pack -codec aplib filename.ext -< doesn't work
nothing happens

I never added support for any other codecs except LZSS when compressing non-images, which is why nothing happens when you try to do that
There's a tool on the aPLib webpage that you can use for packing ordinary files.

[Ti_]

sixpack.exe -pack -codec aplib filename.ext -< doesn't work
nothing happens

I never added support for any other codecs except LZSS when compressing non-images, which is why nothing happens when you try to do that
There's a tool on the aPLib webpage that you can use for packing ordinary files.

Sure, but I want pack without a header. Can u create modified windows console or gui version?

[mic_]

In the aPLib-1.01/examples/c/ directory there's a tool called appack. It does not add any headers IIRC.

[ammianus]

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

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

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.

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

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:

Code: Select all

	.comm	_text_buf,4096,4

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.

[mic_]

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.