Page 2 of 2

Re: Tile compression: How can it ever pay off?

Posted: Sat Feb 11, 2017 10:11 am
by Drew Sebastino
tokumaru wrote:6502 doesn't do that, you need to ASL twice.
It's the same with the 65816. It's a pseudo opcode. I've also seen him do "adx", which isn't a real instruction (you need to transfer the data from an index register, add, and then transfer it back).

Re: Tile compression: How can it ever pay off?

Posted: Sat Feb 11, 2017 10:19 am
by psycopathicteen
I never used adx. Maybe you're thinking of inx #2.


I thought about another approach. If you're doing vertical RLE, you can designate 16 registers (32 in the case of the SNES), each with 1 bit. Update the bits when there is a vertical color change, and for every row (except for entire rows being copied) "asl" and "ora" with every bit (for SNES, 2 bits at once). Now that I think about it, you can do a hybrid of vertical and horizontal RLE, using this method too.

Re: Tile compression: How can it ever pay off?

Posted: Sat Feb 11, 2017 11:10 am
by tokumaru
psycopathicteen wrote:This takes 9.75 cycles per pixel, whereas doing the typical shifting takes 14 cycles per pixel.
I know it's faster, but that's assuming you're working with packed pixels in the first place. If the algorithm outputs bits that you can buffer in planar form right away, there's no need for any conversions at all.

Re: Tile compression: How can it ever pay off?

Posted: Sat Feb 11, 2017 3:10 pm
by tepples
tokumaru wrote:
psycopathicteen wrote:

Code: Select all

asl #2
6502 doesn't do that, you need to ASL twice.
I assume this assembler has a nonstandard feature to turn asl #2 into 0A 0A or asl #3 into 0A 0A 0A.

Re: Tile compression: How can it ever pay off?

Posted: Sun Feb 12, 2017 3:55 pm
by psycopathicteen
I got started working on an RLE-based compression scheme for the SNES that would be fast enough but compact enough to run Darkstalkers on the SNES. Not sure if it's possible or not.