I'm experimenting a bit with sprites and the CC-bit of the sprite attribute table. Somehow it doesn't seem to work as I expect. From what I read in the V9938 manual, I understand that when two sprites overlap, and the CC-bit is set for the overlapping lines,

• sprite priority is canceled
• the resulting color is an OR of the colors of the sprites and
• no collision is detected

Now, I made a small BASIC program that creates two striped sprites (16x16, enlarged), sets the CC-bits for all sprite lines and displays them on top of each other. Here's the listing:

10 COLOR 15,0,0: SCREEN 5,3                      ' 16x16 enlarged sprites
20 FOR S=0 TO 31: PUT SPRITE S,(0,180),0,0: NEXT ' all sprites out of the way
30 OPEN "grp:" AS 1
40 SPRITE$(0)=STRING$(32,&HAA)                   ' a striped pattern
50 C1$=STRING$(16,66)                            ' color 2 + OR
60 C2$=STRING$(16,68)                            ' color 4 + OR
70 PUT SPRITE 0,(0,0),,0: COLOR SPRITE$(0)=C1$   ' sprite 0, color 2 + OR
80 PUT SPRITE 9,(1,0),,0: COLOR SPRITE$(9)=C2$   ' sprite 9, color 4 + OR
90 PRESET(128,10),15:PRINT #1,"<-- result"
100 '
110 LINE (0,90)-(1,121),2,BF                     ' create an pixel image
120 LINE (1,90)-(2,121),4,BF,OR                  ' of what I'd expect
130 FOR X=1 TO 4
140 COPY(0,90)-(X*4-1,121)TO(X*4,90)
150 NEXT
160 PRESET (128,100),15: PRINT #1,"<-- expected"
170 A$=INPUT$(1)

The second part of the listing (line 110 and up) displays what I would expect to see as a result. Instead, I see nothing 



Tested on openMSX emulating a Philips NMS 8250 and on a real 8250...

you expect too much

Hm, indeed. Apparently

• I should not set the CC for both sprites, but for only one
• The resulting color of course applies to the whole enlarged pixel, so I won't get the three 1 pixel wide lines.

Here's a slightly modified and trunkated listing that shows the effect. I'm not gonna spoil the suspense by including a screen shot this time

10 COLOR 15,0,0: SCREEN 5,3                      ' 16x16 enlarged sprites
20 FOR S=0 TO 31: PUT SPRITE S,(0,180),0,0: NEXT ' all sprites out of the way
40 SPRITE$(0)=STRING$(32,&HAA)                   ' a striped pattern
50 C1$=STRING$(5,66)+STRING$(11,2)               ' color 2 + OR
60 C2$=STRING$(11,4)+STRING$(5,68)               ' color 4 + OR
70 PUT SPRITE 0,(0,0),,0: COLOR SPRITE$(0)=C1$   ' sprite 0, color 2 + OR
80 PUT SPRITE 9,(1,0),,0: COLOR SPRITE$(9)=C2$   ' sprite 9, color 4 + OR
170 A$=INPUT$(1)

{edit: Well, ok then... here's the result

}

@AuroraMSX:
You should not set the CC bit for lowest sprite number.
Pratically when the VDP see the CC bit set it start to compute the color like in a temporary variable:
It's initially set to 0 and each time a sprite is processed, if:

a) CC = 1 the color is or-ed and the result is stored in a temporary place
b) CC = 0 the color is or-ed the result is 'committed' and the temporary variable goes to 0. Ready for another cycle.


So if you have three blocky overlapped sprites like this:

sprite 0 -> color 1 CC=0
sprite 1 -> color 2 CC=1
sprite 3 -> color 4 CC=1

example of how the vdp process the colors:

1) tmpcolor = color = 4 of sprite 3
2) found sprite 1, color is 2 and CC = 1? OK! tmpcolor = 4 or 2 = 6
3) found sprite 0, color is 1 and CC = 0? OK! tmpcolor = 6 or 1 -> 7 AND BECAUSE CC = 0 the color is 'COMMITTED', then tmpvar=0

Basically the CC bit if = 0 'commit' the or-ed color, and reset the vdp to assume color = 0. So if the vdp does not find a CC bit = 1 it does not save the final result

I once started to write an article called 'MSX and his sprites', which tries to summarize all I know (and could find elsewhere ) about this topic.

At the moment it is still an incomplete draft. I created a pdf from it and it contains atm some 30 useful pages, were I try to explain all this, including all this confusing CC bit stuff, the differences between MSX1 and MSX2, EC bits, common mistake when mixing sprite colors, other VDP registers and their influence on the sprites, pitfalls of turning sprites off,...

If somebody is interested in the draft (maybe to correct/complete it ? ) just let me know.

Quote:

If somebody is interested in the draft (maybe to correct/complete it ? ) just let me know.

I'm interested, send to spambin@ T I S C A L I N E T! IT
(Remove space and convert ! into .)

thx

PingPong:

Quote:

Basically the CC bit if = 0 'commit' the or-ed color, and reset the vdp to assume color = 0. So if the vdp does not find a CC bit = 1 it does not save the final result

Ah.. I see.That's why the result in the original listing was just black/background....

turbor:

Quote:

If somebody is interested in the draft (maybe to correct/complete it ? ) just let me know.

I'm definitely interested It would e.g. make a nice addition to the MRC Articles section!