The idea of the "RTS trick" (also known as jump table) in this context makes perfect sense, you have 4 highly optimized sprite mazing routines for all 4 orders. However that's not what I had in mind. The idea was just to use normal indexed mode. The LDX $xxxx,Y or LDY $xxxx,Y instructions would be more useful here than a LDA $($xx),Y.
Just pasting your code modified to use what I had in mind.
Code: Select all
; Warning. Code is written in place, not tested. But I hope it explains what I intended
MAX_SEQUENCE = 2
.byte 0, 3, 7, 11, ..., 252
.byte 0, 11, 3, 7, ..., 252
.byte #<spriteSequence1, #<spriteSequence2
.byte #>spriteSequence1, #>spriteSequence2
adc #64 ; Size of a sequence
cmp #MAX_SEQUENCE*64 ;MAX_SEQUENCE can only be 2 or 3 for this to work, if it's 4 the CMP instruction should be removed, if it's more than 4 it won't work at all
; assuming spriteSequence is a pointer to one of the shuffle arrays
; and array contains the offsets in oam, not IDs (eg 0, 3, 7)
; Fill the rest
bne FinishSprites ; ??? not sure this will work
Now there is no right or wrong, it just depends on what you want to do. A thing I like to do when mazing sprites is to constantly keep the index in either X and Y, and only use the remaining 2 registers for all others operation. Your idea to store and load the "curentspriteId" in a zero-page variable instead of keeping in a register is a source of inneficiency.
Also I like to generate what you call the "sequences" on the fly, that is the sequence is not stored anywhere in ROM, it's just the result of a computation. This has its limits, though.