+-----------------+
|                 |
| +-+ +-+ +-+ +-+ |
| |0| |1| |2| |3| |
| +-+ +-+ +-+ +-+ |
|  |   |   |   |  |
| ++---+---+---++ |
| | Prio Enc.   | |
| +------+------+ |
|        |        |
+--------|--------+
      Result

This is the sprite engine. It has 4 processing cores. Each sprite core has its own SAT and SPT cache for 32 sprites. The priority encoder passes on the sprite pixel and other attributes of the sprite that's valid for a given screen X/Y. The inputs to the engine are not drawn, but they are the screen X/Y and a start wire. Maybe this will show why linking to a "previous" sprite is not as easy as you think. The 4 cores are independant and do not cross reference each other. Apart from the pipeline latency, a sprite is fully processed in only one clock cycle. After 32 cycles the cores together will have processed 128 sprites (32x4).

THus, sprites are processed in this fashion:
0 1 2 3
4 5 6 7
8 9 11 11
12 13 14 15
...
124 125 126 127

So, for linking to work in this model, you have to stick to one core. Only per core there is a previous sprite. Sprite 4, 8, 12, 16, 20 could all link to sprite 0. Sprite 5, 9, 13, 17 could all link to sprite 1. But sprite 3 can not link to sprite 0 as you are then crossing the core boundary.

Quote:

@MagicBox You already told the sprite attributes are read in some buffer somewhere at the beginning of a frame. Wouldn't it be possible to adjust this buffer while fetching it from RAM (with only a couple of clockcycles delay)? That way the rest of the sprite system (e.g. the split-up in 4 processing cores) remains unaffected. Anyway, just an idea, use it as you see fit.

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.

Well, this morning I did some wave-form test benches and am pleased to say that the sprite engine works perfectly (still with the sprite-mode, flip bits and the collision category system). Sprite linking however is not yet incorporated and will need to be sorted out well before I modify the engine again.

As for the sprite size i do not consider linking sprites , nor other forms of sprite aggregation, a *must* feature.

I'm also not thinking that 128 sprites will be fully used. Even if so writing the entire SAT, that if i'm not wrong is 128*8=1024 bytes is not a huge work for cpu....
I think instead having to manage 128 sprite AI could become a limit for CPU.

So why bother about some bizzarre features like those?

Simplicity always pay...

just my 2 cents

Can you show us a movie of it?
Or some pictures of the results and dev. board.

Quote:

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 + flip-X = rotate 90
transpose + flip-Y = rotate 270
(flip-X + flip-Y = rotate 180)

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...

Quote:

I would love to recode YsIII for VDPX

maybe YS: oath of Felghana(spiritual remake of Ys3).

just joking.

@MagicBox: any news?

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.

Quote:

Yes, it's going very bad with family of mine whom is in the hospital

I am very sorry for what is happening to your family, MagicBox. Let me express my best wishes about the situation.

ahhhh, because you are using XY sign as flip indications? how the flip works? rendering the pattern from right to left and down to up?

I no see why the linking is uncompatible with flip.... just prevents again that sprite using the flip system..

the programmer with knows that if you want to link , you can't do fliping.

flyguille: i do not think MagicBox is in the spirit of argue about VDPX internals.

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?