designing levels around rotating sprites is getting hard

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
designing levels around rotating sprites is getting hard
by on (#202999)
So with rotating sprites, my game needs 16kB of ram for 64 rotation steps of 32x32 sprites, so there is typically 3 to 4 different types of sprites that can be rotated at once (I use 64kB of ram for rotating sprites, not including 16x16 sprite). However rotating sprites are hardcoded to certain RAM spaces, and I also use a table of "rotation regions" where at certain points rotating sprites are software rotated. I think I have a few ways to fix this problem.

1) If I need to do rotation more flexibly/dynamically, I would need to make the code even faster. So I am going to do the trick that I've mentioned in viewtopic.php?f=2&t=16365 where I composite 2 sprites into 1. In this case it would be a sprite at 0 degrees merged with itself at 90 degrees.

2) RAM regions are going to be automated so that I don't have to manually keep track of them myself.

3) Now here's the hard part, and probably the last step. At the start of the level, run through the object table for rotating objects, and generate a table with all the midway points between rotating objects, so that all I would need to do is place them in my level like normal objects and the engine would do the rest.
Re: designing levels around rotating sprites is getting hard
by on (#203082)
Step 1 might not be worth it, because splitting up the nibbles probably takes as long as computing the addresses.

Another approach would be to render the sprite in packed pixel first, and convert to planar twice, for both 0 and 90 degrees.