VDP special tricks around sprites

[Fonzie]

Hi,
The genesis vdp have nice features around sprites...

First i want to write down the well-known-things (correct me if there is an error):

Here are the limits in 320px mode:
-32 sprites per line max
-320 pixels of sprites per line max (10 sprites of 32pixels width, for exemple)
-80 sprites browsed per line.

Here are the limits in 256px mode:
-24 sprites per line max
-256 pixels of sprites per line max
-64 sprites browsed per line.

Now here are the less-known-things (from my experimentations):

-Sprites are drawn depending of the sprites display list order, first sprite in list is ZBottom and last is ZTop.
-Sprites are written from Ztop to Zbottom (write occurs only if transparency, code 0).
-No sprite displayed under Shadow/Highlight (since they correspond to code 14 and 15).
-When having a black background color, an highlight using sprites cannot be done over this background.

Now here are the unsure-things (to me):

-There are 4bits left in the sprite table (the 4bits before the sprite size), what are those bits used for? For Y sorting?
-I read somewhere that displaying a sprite with X coordinate of 0 and Y coordinate of Y simply disable any sprites on this line Y, true? (does it disable display on the "Y line" only or "Y> Y+sprite tall" lines ?).



Well, share your discoveries around sprites

[Stef]

I think we should concentrate these importants VDP infos in our post.
So as soon someone post a correction or add a new info, you should correct and mention it in your first post. Then everyone can quickly access them

About the sprite limit, in 256 px mode, i believe it's 24 sprites by line (not 20) but that need some test though :p

Also there is a general sprite limit per frame :
in 320 px mode, you can display up to 80 sprites.
in 256 px mode you can display up to 64 sprites.

For all these reasons, it's really recommended to always use the 320px display mode : more pixels, more sprites capabilities !

Sprites are drawn depending of the sprites display list order, first sprite in list is ZBottom and last is ZTop. You can create some funny effect by combining the sprite Z priority and their priority bit (used for the background plans). Sonic2 uses it in the intro screen.

[Fonzie]

Ok, i edited my message with your updates.

About the 4bits left in VRAM... Steve told me that the VDP was préparing something (like a preliminary Y sorting) few ms before outputing pixels to TV. I'm pretty sure it is working using those 4bits, any idea?

[Fonzie]

Ok, i investigated around the hardware line masking around sprites and i ended with this conclusion:

If you display two sprites which have same Y and X coordinate of 1 for the first one and X coordinate of 0 for the second one... It will disable any other sprite drawing on the screen Y->(Y+sprite tall) range!!!

I got confirm by Steve mad hidden and useful feature !

Thx

[TmEE co.(TM)]

-I read somewhere that displaying a sprite with X coordinate of 0 and Y coordinate of Y simply disable any sprites on this line Y, true? (does it disable display on the "Y line" only or "Y> Y+sprite tall" lines ?).

It is true, I ran across it when I was messing with GBMD. I thought that it was a bug or something, but it is a very nice feature. I use it in my current project to disable sprites drawn onto the status bar. That sprite is first in the list, so any other sprite won't display on status bar.

[cdoty]

It is true, I ran across it when I was messing with GBMD. I thought that it was a bug or something, but it is a very nice feature. I use it in my current project to disable sprites drawn onto the status bar. That sprite is first in the list, so any other sprite won't display on status bar.

Charles McDonald's VDP document talks about this (see Sprite masking, mode 2). There's a second mode listed which only requires a sprite at an x coordinate of 0.

So, let me get this straight:

If you place sprite #0 at 1, 208 that is 16 pixels tall, it will not draw any (low prioirity) sprites on those lines?

Sprite #0 wouldn't be visible, because it's off the left hand edge of the screen, correct? (It's x position is 1 and not 0x81, right?)

I wonder if it's a bug or an intended feature?

[TmEE co.(TM)]

All sprites in the list after the one placed on $00 (offscreen) will not be displayed on the lines the sprite occupies, all previous ones are, so its probably not a bug (it would be if ALL sprites won't get displayed... that's what I think). REALLY useful feature.

[Fonzie]

Yeah, the sprite mask is not a bug, its definitively a feature. We used it in Pier Solar and every single system ran it perfectly.

Few more things :
- The sprite list must be uploaded very early in VBLANK as the VDP do pre-process stuff before the next screen even starts. If you fail to do so, you will get random glitches (blue / red pixel stripes appearing near some sprites is what I could see, model2 MD is more prone to this).

- If sprite list is not "closed" (kaneda always said it to me but since I never saw any issues with it before, I really never checked that closely), it works in "most cases" BUT it increase the occurrence of the nasty glitches mentioned above. Do NOT make the sprites loop on themselves, its really loop on "sprite zero" that is needed.

Take care!