another sprite rotation technique

If you didn't already know, I am obsessed with sprite rotation.

Designate a part of either WRAM or cartridge SRAM with an inflated copy of an 32x32 sprite pattern, with 4 bytes per pixel and 1 bit per byte. Use a really large (64kB) lookup table with an address for each pixel. For out of range pixels, I'm using the top left pixel because it is normally blank because rotating sprites have to be circular shaped to avoid clipping. I made such a lookup table with 32 steps from 0 to 90 degrees. I didn't have to go past 90 degrees, because 90 degrees would use the same addresses as 0 degrees, but in a different order.

I actually made an SNES ROM to generate the LUT which I then turned into a BIN file.

Obviously having this big of a LUT for just 1 size of sprites is really redundant, so I think I can come up with an on-the-fly "compression" format, involving linear runs of pixels.

I thought of a way to make it more compact. Using 3 bits per "pixel". 1 bit for if the pixel is in bounds, 1 bit to indicate if x is incremented, and 1 bit to indicate if y is decremented.

Although, I can just go with a 256kB LUT for 64x64 sprites and do 48x48 and 32x32 sprites with the inside pixels. It would only take up 2 megabits, so it could be considered feasible.

What just occurred to me that in a 64x64 rotating sprite, the corner 8x8 tiles won't be used (the sprite has to fit within a circle). So if I'm not calculating bounds clipping, I only need one extra row and collumn of 8x8 tiles to pad the sprite with, because the maximum distance from the center of the sprite would be 5 tiles, because 3^2 + 4^2 = 5^2.

I realized I could save both a ton of speed and memory (compared to long lookup tables) by having a bunch of routines with precalculated addresses to do one 8x8 tile, and move an index register around for every 8x8 tile to rotate larger sprites.

Have you considered to try the possibility of using the ppu memory registers to do multiplications?

It's the software rendering that takes up a lot of CPU power.

I haven't got done implementing the above yet, but I implemented the ability to jump between cartridge SRAM banks for rotating sprite buffering. I wish I started Alisha's Adventure with lorom instead of hirom, because lorom has larger sram banks in the fast ROM region.