In my game, I have a simple shuffle mechanism for meta sprites, so that they start to flicker when too many sprites are on the scanline.
I simply shift the start index of the characters array by 1 every frame. And then I switch between iterating the array from front to back or from back to front every frame.
That's pretty simple because there are about 10 characters max and the shuffling makes sure the hardware sprites get written in a different order every time.
Also, the player character is outside of the shuffling. He always gets written first so that he never flickers.
So, if I have five small meta sprites (with a width of 16 pixels each) next to each other, everything is fine: The hero never flickers and the opponents take turns in flickering.
But now I have the following situation:
I have two meta sprites: The hero with a normal size and a huge wide boss, so that the number of sprites is exceeded when both characters are next to each other.
Now, while the meta sprites are shuffled, the hardware sprites are of course written in a fixed order: The sprite output function simply reads every byte from the array that is the current character's animation phase and that's it.
So, the result is: When both characters are on the same scanline, the right side of the boss simply disappears. Because there are only two meta sprites and one of them is outside of the shuffling. And the right part of the boss is always drawn last.
Even if I included the hero into the shuffling, it would still look odd: The body of the boss wouldn't flicker equally, but it would always be its right side that flickers because that's what's written last.
So, how do games usually do this? If you have one huge boss and flickering is necessary, how do you make sure that the flickering occurs over various parts of his body?
I cannot rewrite the sprite copy function to use a shuffling mechanism as well.
Because I store the palette value for each tile in the beginning of the meta sprite animation phase definition, two bits for each tile.
And then, I have three different counters: One for the current tile position, one for the palette values position and one for the current bit shift inside this palette values byte.
If I included shuffled reading, this would make the palette value caluclation more time consuming since I'd have to recalculate the current position each time instead of simply doing it once and then incrementing the values from there.
Likewise, if I decide to shuffle the hardware sprites themselves after they have been written to an array, then this is still a huge overhead.
Because for shuffling meta sprites, I simply have to check a few conditions for each meta sprite and then the DrawMetaSpriteAsHardwareSprites function gets called with the current index.
Not only do the condition checks only occur about 10 times per frame (once for each meta sprite), but the actual copying function is called the same number of times as if I hadn't included a shuffling mechanism.
But shuffling the actual hardware sprites would require actually copying each and every byte from one array to another. And it would be many times more data.
So, it would be 10 times the call of DrawMetaSpriteAsHardwareSprites (as before) plus the copying of 10 * NumberOfTilesPerCharacter * 4 bytes from one array to another, including setting the counter offset and the iteration order every time one of these 10 * NumberOfTilesPerCharacter tiles is copied.
So, do you know about an efficient way to let each body part flicker instead of just the rightmost one if there's a huge wide boss?
I simply shift the start index of the characters array by 1 every frame. And then I switch between iterating the array from front to back or from back to front every frame.
That's pretty simple because there are about 10 characters max and the shuffling makes sure the hardware sprites get written in a different order every time.
Also, the player character is outside of the shuffling. He always gets written first so that he never flickers.
So, if I have five small meta sprites (with a width of 16 pixels each) next to each other, everything is fine: The hero never flickers and the opponents take turns in flickering.
But now I have the following situation:
I have two meta sprites: The hero with a normal size and a huge wide boss, so that the number of sprites is exceeded when both characters are next to each other.
Now, while the meta sprites are shuffled, the hardware sprites are of course written in a fixed order: The sprite output function simply reads every byte from the array that is the current character's animation phase and that's it.
So, the result is: When both characters are on the same scanline, the right side of the boss simply disappears. Because there are only two meta sprites and one of them is outside of the shuffling. And the right part of the boss is always drawn last.
Even if I included the hero into the shuffling, it would still look odd: The body of the boss wouldn't flicker equally, but it would always be its right side that flickers because that's what's written last.
So, how do games usually do this? If you have one huge boss and flickering is necessary, how do you make sure that the flickering occurs over various parts of his body?
I cannot rewrite the sprite copy function to use a shuffling mechanism as well.
Because I store the palette value for each tile in the beginning of the meta sprite animation phase definition, two bits for each tile.
And then, I have three different counters: One for the current tile position, one for the palette values position and one for the current bit shift inside this palette values byte.
If I included shuffled reading, this would make the palette value caluclation more time consuming since I'd have to recalculate the current position each time instead of simply doing it once and then incrementing the values from there.
Likewise, if I decide to shuffle the hardware sprites themselves after they have been written to an array, then this is still a huge overhead.
Because for shuffling meta sprites, I simply have to check a few conditions for each meta sprite and then the DrawMetaSpriteAsHardwareSprites function gets called with the current index.
Not only do the condition checks only occur about 10 times per frame (once for each meta sprite), but the actual copying function is called the same number of times as if I hadn't included a shuffling mechanism.
But shuffling the actual hardware sprites would require actually copying each and every byte from one array to another. And it would be many times more data.
So, it would be 10 times the call of DrawMetaSpriteAsHardwareSprites (as before) plus the copying of 10 * NumberOfTilesPerCharacter * 4 bytes from one array to another, including setting the counter offset and the iteration order every time one of these 10 * NumberOfTilesPerCharacter tiles is copied.
So, do you know about an efficient way to let each body part flicker instead of just the rightmost one if there's a huge wide boss?