I have noted a very strange behaviour of the blue and open MSX emulators about the managementof the 5th sprite limit.

Assume you have 3 sprites definitions like the following

sprite shape 0

........
........
........
........
11111111
11111111
11111111
11111111

sprite shape 1

11111111
11111111
11111111
11111111
........
........
........
........

sprite shape 2

11111111
11111111
11111111
11111111
11111111
11111111
11111111
11111111

(where . means 0)

place 3 sprites with shape 2 at 0,100 16,100, 32,100

place sprite with shape 0 at 100,100, with colour 7
place sprite with shape 1 at 100,100, with colour 8

question :

for the 5th sprite rule, do sprite with shape 0 & sprite with shape 1 count as 2 sprites or as 1 sprite?

The emulators count for the 5th sprite rule also the "off part" of the sprites (the one at "0"
but AFAIK the real msx should ignore the off part of the sprites for the "4 sprites on one line" rule

Different matter is for sprites of color 0, where the "on part" of the sprite
should count also if of colour 0 ...
but the off part cannot count

Can anyone confirm on a true HW the behaviour of the VDP
wrt the off part of the sprites and the 5h sprite limit ?

Can anyone confirm on a true HW the behaviour of the VDP
wrt the on part of the sprites with colour 0 and the 5h sprite limit ?

I'm quite sure that 5th sprite doesn't care whether the pixels are 'on' or 'off' but I need to double check. I use 5th sprite for synchronization in my demos and I'm quite sure i use sprites with all pixels 'off'. There are some differences between the MSX1 and MSX2 VDP when it comes to sprite collision and 5th sprite in MSX1 modes but I don't think this is one.

I'm pretty sure they count as two sprites.
Think of it this way: the VDP needs to get the spritedefinition of sprite patern 0 and 1 out of the vram. Only after decoding the fetched byte the VDP can decide if it needs to draw anything on screen. now the 5th sprite limitation is due to the limited bandwith available to fetch this info. toherwise with your assumption you could draw 20 transparant sprites on one line and have the 21th sprite show some pixels. This will not work since there simply isn't enough time to read all those sprites on each scanline.

this changes a lot my sprite management....
thanks

For msx1 sprite mode, I don't think it matters whether it has empty lines or not. I'm not so sure it's the same for msx2 sprites though.

more indepth timing info can be read at http://bifi.msxnet.org/msxnet/tech/tmsposting.txt

Actually I may be confused by the collision flag,
(where the points with color 0 that are "active" count for the collisions, while points that are not active does not count - but this is normal)

BTW does anyone have done a test on real HW ?
just to be sure before deleting tons of already designed animations...

Quote:

To determine which sprite will be visible on any given scan line, the Y-position of all 32 sprites must be read from the Sprite Attribute Table (SAT) in VRAM and compared against the current scan line number. When doing the compare, the Mag bit from VDP register 1 must be taken into account, since the magnification is in both the x and y directions. If the Y-location of the sprite is such that it is to be displayed on this scan line, then the sprite number (0-32) is placed in one of four temporary holding registers (SR0-SR3), if all four registers are not already filled. SR0 fills first, SR3 fills last, and SR0 specifies the frontmost sprite plane and SR3 specifies the rearmost sprite plane.

So the VPD doesn;t take the 'empty' lines into account