rainwarrior wrote:
A good shuffler should be changing the relative order of sprites. Changing the start position doesn't accomplish this very well. If you start on 2, you still have 2 before 3 before 4, etc... the only order you've changed by doing that is that 1 is now after things, but every other order relationship is intact.
That's why I used an offset
and and order switch. Have a look again:
Code:
Start with 1, go forward: 1 2 3 4 5 6
Start with 2, go backward: 2 1 6 5 4 3
Start with 3, go forward: 3 4 5 6 1 2
Start with 4, go backward: 4 3 2 1 6 5
Start with 5, go forward: 5 6 1 2 3 4
Start with 6, go backward: 6 5 4 3 2 1
So, would you say this is a good method or do you see any shortcomings?
This of course only shuffles the characters, but not the sprites within each character (which was my original reason I wrote this thread). But this other issue, I will talk about now.
Regarding the shuffling of the hardware sprites themselves:
Thanks for all your input.
There are two versions that fit my taste best:
Either I take gravelstudios' one byte randomizer.
However, it does have the shortcoming that I have to delete all sprites after every frame.
In the moment, my deletion is optimized: If the previous frame drew fewer sprites than the current one, no deletion is necessary at all.
And if the previous frame drew more spites, I only have to delete from the current maximum index to the previous maximum index.
Or I use FrankenGraphics round robin suggestion as an inspiration.
I don't know if I understood it correctly, but in any case, I would do it like this:
I would still read my meta sprite as usual (i.e. in the correct order). But for rendering, I would use a round robin offset that only refers to the sprites that I'm about to draw now.
So, if the character consists of 10 sprites, then I take the next 10 sprites of the gloabl sprite shadow copy and use a round robin method on these 10 sprites only, with an offset value that is stored and incremented per character.
This makes sure that the sprites within the same character are always drawn from a different start value.
And for the order between different characters, I still use my method that I described above. (Or have a look at rainwarrior's alternatives if he still says it's no good.)