That may actually work at no additional time cost, but it prevents proper flipping. You'd get something like this:
Normal:
0 1 2 3
Flipped:
3 2 1 0
.. where individual sprites are flipped too. As you can see, the 'hotspot' for normal is as expected, top-left. But for the flipped chain, it's still at sprite 0, which is not top-left any more. Since at sprite 0 I don't know how many sprites are linked to its right, I won't be able to put the hotspot at the top left for the flipped version, which would be sprite 3.
Exactly, that's what I meant in my original post with "it may not work well in combination with flip X/Y". I only proposed it as an alternative for the fixed multi-sprite modes. And I agree with PingPong it has low priority (so feel free to drop it).
I still have one other suggestion: in some games do don't want to flip a sprite around X/Y, but you want to rotate the sprite 0, 90, 180 or 270 degrees. This can be implemented with one extra bit in the sprite attribute table: "transpose".
Transpose is very easy to implement in hardware, just swap the X and Y address bits in the sprite pattern table (at least if you don't require burst memory reads).
I thinks that the linking with previous sprite can be done easily without modifying the core itself.... if the problem is that the four cores gets its copy of SAT... so , that means that you can to precalculate XY ABS coordinates of each sprite in the process to LOAD those SAT's copy.
so. if loading the SAT's buffers are like an LDIR... you can just to do a binary PLUS calculation on each X and Y register if the bit of link is set.... so, that will mean, that the engine will be loaded with the SAT all filled with ABS coordinates, while in VRAM is the original SAT unmodified...
Yes, it's going very bad with family of mine whom is in the hospital, VDPX was last on my mind past couple days.
The rotate bit I will be adding to the SAT. Spritelinking I won't be doing; it's easy enough to update sprite X/Y yourself. I will also be adding helper registers for that later on (Write "Update Sprite X/Y" command to comman register, followed by sprite start number. Then you can issue X/Y data to data register with sprite index auto inc.
Like flyguile said, that would be the method of updating sprite X/Ys during copy. However, flipping would not work properly, at least, it would work the way I explained before, so I'll just not be adding it.
Just out of curiosity: Given that few of needed chips are still manuafctured or available (even the V9990 is long "out of print") how are parts going to be accquired? From scrapped machines? Through FPGA programming? I'd really like to know?
