bug in the VDP emulation (?)

Por ARTRAG

Enlighted (6828)

Imagen del ARTRAG

24-10-2006, 23:58

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 ?

Login sesión o register para postear comentarios

Por dvik

Prophet (2200)

Imagen del dvik

25-10-2006, 00:23

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.

Por turbor

Champion (496)

Imagen del turbor

25-10-2006, 00:26

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.

Por ARTRAG

Enlighted (6828)

Imagen del ARTRAG

25-10-2006, 00:26

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

Por Edwin

Paragon (1182)

Imagen del Edwin

25-10-2006, 00:27

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.

Por turbor

Champion (496)

Imagen del turbor

25-10-2006, 00:29

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

Por ARTRAG

Enlighted (6828)

Imagen del ARTRAG

25-10-2006, 11:00

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

Por Huey

Prophet (2687)

Imagen del Huey

25-10-2006, 11:41

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 Crying