It is currently Mon Jun 18, 2018 2:44 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Fri Mar 02, 2018 8:53 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2694
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 32 times
Top
 Profile  
 
PostPosted: Sat Mar 03, 2018 5:40 pm 
Offline

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


Top
 Profile  
 
PostPosted: Mon Mar 05, 2018 4:01 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sun Mar 18, 2018 6:21 pm 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 45
Have you considered to try the possibility of using the ppu memory registers to do multiplications?


Top
 Profile  
 
PostPosted: Mon Mar 19, 2018 10:05 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sat Apr 07, 2018 4:07 pm 
Offline

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group