VDP Sat Rotation & blitter

Par PingPong

Prophet (3680)

Portrait de PingPong

05-04-2021, 19:31

Hi, all, as we know, in sprite mode 2 there is and additional vram area used to store sprite color attributes.
Unfortunately, this is 512 bytes in size, and must be rotated (to handle sprite flickering) in conjunction with the usual 128 byte SAT.

I've thought to issue some kind of vdp copy command in order to rotate, (at blocks of 128 bytes->8 sprites at time) the sprite color area by issuing in screen 5 a copy command of one line to the previous or next. This does work, but i think could be done better than my solution, any idea about?

Basically i would like do this kind of command:

Y=sprite vram color area/128
(A) COPY (0,Y)-(255,Y) to (0, Y+5) -> first 8 sprite color
(B) COPY (0, Y+1) - (255, Y+3) to (0,Y)
(C) COPY (0, Y+5) -(255, Y+5) to (0, Y+3)

the last copy could be avoided if instead of using Y+5 would be Y+4, issuing a bigger copy in (b), this would interfere with the address of SAT that is contiguous with the color attribute area so i cannot use it.

Basically i store a 128 bytes somewhere in vram that is the first color attribute table for 8 sprites, then i move each line upper of 1 line that would be rotate the 8 sprites color attr . then i restore the line stored "somewhere" as the last line of area.

Someone can suggest a better approach? my issue is the speed optimization and the ability to keep up with 60hz fps in order to reduce the flickering.
thx in advance.

!login ou Inscrivez-vous pour poster

Par thegeps

Paladin (736)

Portrait de thegeps

05-04-2021, 19:50

You need rotation or is it enough reverse both sat and sprites colors tab?

Par santiontanon

Paragon (1348)

Portrait de santiontanon

05-04-2021, 21:59

Can you have 2 copies of the sprite color/attribute tables and just alternate between them using registers 5/11?

Par PingPong

Prophet (3680)

Portrait de PingPong

05-04-2021, 22:37

16 sprites/scanline should be enough however what is your proposal using the blitter to achieve this?

Par PingPong

Prophet (3680)

Portrait de PingPong

05-04-2021, 22:38

if you mean double buffering i do not see the gain can you explain a bit more what is your proposal?

Par thegeps

Paladin (736)

Portrait de thegeps

06-04-2021, 00:30

Maybe I'm mistaken (because I still haven't studied the v9938) but I think that time ago I've read about using both vdp commands and cpu to write faster in vram.

So if you have your sat and sprite color tab both in RAM and in VRAM you can set in vram 1 more sat and sprite color tab destination area. Then split the work:
Cpu, using unrolled otir will write the first half to dsstination sat amd destination sprite color tab
Blitter will do the second half (obviously both processes have to reverse data)
Then when data copy to destination is done you can swap original sat and original sprite color tab with the destination ones by changing their addresses

Par santiontanon

Paragon (1348)

Portrait de santiontanon

06-04-2021, 03:04

Oh, what I was suggesting, is that instead of rotating, you just have two versions of the SAT. One where sprites are in forward order: 0, 1, 2, 3, 4, ... and the other where they are in backwards order: 31, 30, 29, 28, ...

And you can swap between then with just two register writes. It's not "full rotation", but it would still accomplish the same effect in 95% of the cases. It'll only fail if you have more than 16 sprites in the same line, which should be rare, ideally.

Par PingPong

Prophet (3680)

Portrait de PingPong

06-04-2021, 08:41

Actually i do a kind of work splitting, the CPU moves the SAT (128 bytes) while the VDP is processing color sprite table.

Par PingPong

Prophet (3680)

Portrait de PingPong

06-04-2021, 10:30

santiontanon wrote:

Oh, what I was suggesting, is that instead of rotating, you just have two versions of the SAT. One where sprites are in forward order: 0, 1, 2, 3, 4, ... and the other where they are in backwards order: 31, 30, 29, 28, ...

And you can swap between then with just two register writes. It's not "full rotation", but it would still accomplish the same effect in 95% of the cases. It'll only fail if you have more than 16 sprites in the same line, which should be rare, ideally.

this schema also work with full rotation, it just need 4 sats.
by the way i also think to have the sat splitted into two groups, (0-15) and (16-31) each one reversed. in this way i minimize the chances of sprite flickering because is unlikely that the sprite overflow occours across the two groups , each one made of 16 sprites.

Another solution found is to copy the 128 line row of the last 8 sprites color table at color table address - 128 then issuing a vdp command to move from 0,Y-1 for 4 lines of 128 bytes lines to 0, Y while doing sat write via CPU