This works well for most cases, except when I get need to do the following

1. I need to indicate where in the sprite buffer the sprite attributes need to go (since the player can go "behind" other sprites)2. Indicate where the tile date should be put in CHR-RAM (tile index) when it's loaded.

Unless you hardcode specific positions in the sprite buffer (which is horribly ineffecient when you want to make full use of all 64 hardware sprites, but a lot of old games actually did that), I'd say it's all in the order you decide to write to your buffer.

What I have done previously is two separate solutions:

1. Make a separate "draw" routine at the end of my main loop which reads object information in the order I want to send them to the sprite buffer. Basically, the items I write first get the highest priority. So if a sprite needs to be in front, I'll make a special routine to handle those objects first, and then maybe the player character followed by data from a generic object table, etc., proceeding until no objects are left, or my "X" register (used to index the position in the sprite buffer, same as you do) rolls over.

2. Keep my X index saved to a variable in memory that I dig out whenever I want to draw a sprite during my object update routines. This is less neat to look at, but gives you more freedom to draw different items in different ways. However you'd still have to consider the order you draw them in, if you want to give some of them higher priority.

The biggest issue is of course if you want to have some kind of sprite cycling method to keep your sprites blinking instead of disappearing if you expect to go over 8 on the same scanline. This makes it difficult to always give some objects higher priority, so if that's important to you I'd say it's a good idea to keep a seperate "draw" routine which always draws the high priority sprites first, and then loops through the remaining object in a ways that differs on each frame.

Yeah, make your sprite drawing routines concatenate to the end of the sprite list, and then it's just a matter of calling the draws in order of priority.

If you have something that does that already, it's not too hard to then randomize or otherwise vary the order to get sprite flickering. (e.g. you could call the draws in reverse order every second frame)

Who is online

Users browsing this forum: Google [Bot] and 2 guests

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