My thing was sprite-multiplexers. In theory it's very simple. You sort the sprites by y-position, then use raster interrupts to reprogram the sprite registers for "(spriteN++ & 7)".
The hardest part is sorting. It takes quite some time to sort data on a 6502. I "invented" my own sorting routine for this, but I later learned that most coders used bubblesort since most of the time sprites move just a little so it's mostly sorted already.
My routine used half the stack. I took ypos >> 2 and used that as an index to the bottom half of the stack. If the position was occupied I used the next pos etc. To collect I simply used a PLA(pop) instruction. There were holes of course, so you had to check for empty slots.
That routine took about the same time every frame.
Yes, bubble sort was an obvious choice given it's easy to understand and implement, I came across this article some time ago which goes through many different ways to sprite sort for general multiplexing and presents 'continous insertion sorting' as the winner, was a fantastic trip down memory lane.
The hardest part is sorting. It takes quite some time to sort data on a 6502. I "invented" my own sorting routine for this, but I later learned that most coders used bubblesort since most of the time sprites move just a little so it's mostly sorted already.
My routine used half the stack. I took ypos >> 2 and used that as an index to the bottom half of the stack. If the position was occupied I used the next pos etc. To collect I simply used a PLA(pop) instruction. There were holes of course, so you had to check for empty slots.
That routine took about the same time every frame.
32 sprites was not very hard to do, sorting-wise.