another sprite rotation technique

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

another sprite rotation technique

Post by psycopathicteen »

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.
Attachments
affine LUT.bin
(64 KiB) Downloaded 161 times
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: another sprite rotation technique

Post by psycopathicteen »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: another sprite rotation technique

Post by psycopathicteen »

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.
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: another sprite rotation technique

Post by Señor Ventura »

Have you considered to try the possibility of using the ppu memory registers to do multiplications?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: another sprite rotation technique

Post by psycopathicteen »

It's the software rendering that takes up a lot of CPU power.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: another sprite rotation technique

Post by psycopathicteen »

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.
Post Reply