EricBall's Tech Projects

On paper it sounds like a great plan - a list of pointers to sprites with width and horizontal positioning info. Very powerful and flexible, but damn difficult to use in practice.

Sounds kinda like what I did with the Dragon where I have pointers to 3 lists, 2 containing images(wings, body) and the 3rd containing the horizontal positioning for both sprites(this used to be in 2 lists, I combined them to save ROM at the expense of CPU cycles). Uses up a lot of critical cycles, so I can see the benefit if the video hardware is doing the work for you. But likewise, I can see where that would be troublesome if you're not dealing with static images like I have.

So if I read this right are you thinking of something similar to a flicker sort on the VCS?

 

I think I see what you're saying. This is what I'm gathering.

 

1) Have your sprites sorted is an array based on vertical position

2) Cycle through the display list (which is sorted)

3) Place the sprite in the appropriate display list.

4) Once sprite is placed in the list remove the sprite from the array so sort of like a merge sort.

 

Am I reading your thoughts correctly?

Nope. Don't even bother trying to sort the sprite list. Just scan through the list for each display list looking for ones with Y values in the appropriate range.

 

Actually, the sprites are sorted - back to front (although the front ones may flicker if there are too many sprites on the line).

 

I'm betting that the Y value comparison is a simple enough operation that it can be done very quickly. So the fact that you have to scan through the sprite list N times isn't a big deal.

I coded up most of the routine then did some cycle counting. Unfortunately, it's worse than the "find the display list" routine I used in BallDemo. It's a simpler routine and the not-in-list checking is fairly quick. However, when you multiply the 26 cycles each sprite takes by the number of display lists you end up with a larger number of cycles. Sigh