Saturn transparency confusion. Someone please explain. (screenshot example)

[shownomercyomer]

I see this in many many Saturn games where games use two types of transparency - Mesh and true. Why use mesh when true transparency is already achieved? For example in the game Bulk Slash , transparency on the mech's shadow is mesh whereas real transparency is used on the HUD and radar. Can someone please explain this?

The TV im using is a glorious CRTV - 32"Sony WEGA 32FS210 made in 2003
S-video Saturn console (J) with fenrir

 

[nando]

It's because of how the hardware works. there are 3 ways basically to get transparencies on Saturn:

• Mesh sprites - works in basically any mode, 3D graphics, 2D sprites, etc.
• half-transparent sprites - works basically only for 2D sprites. due to how VDP1 renders, 3D transparencies will be broken because the same pixel gets written multiple times. sprites can disappear behind other sprites due to how VDP2 works.
• VDP2 color calc modes for backgrounds - it basically adds a portion of the background colors together. doesn't work for sprites/quads.

the shadow is a mesh, because otherwise it would end up covering the mech instead. the HUD is using a VDP2 background layer and one of the transparent color calc modes.

XL2 gets transparencies by drawing off-screen, then copying that part of the frame buffer to a background layer, and using VDP2 to achieve "true" transparencies. I don't know that anyone did that back in the 90s - they used mesh because you simply turn it on with a boolean and call it a day.

 

[Amiceli1983]

It's because of how the hardware works. there are 3 ways basically to get transparencies on Saturn:

• Mesh sprites - works in basically any mode, 3D graphics, 2D sprites, etc.
• half-transparent sprites - works basically only for 2D sprites. due to how VDP1 renders, 3D transparencies will be broken because the same pixel gets written multiple times. sprites can disappear behind other sprites due to how VDP2 works.
• VDP2 color calc modes for backgrounds - it basically adds a portion of the background colors together. doesn't work for sprites/quads.

the shadow is a mesh, because otherwise it would end up covering the mech instead. the HUD is using a VDP2 background layer and one of the transparent color calc modes.

XL2 gets transparencies by drawing off-screen, then copying that part of the frame buffer to a background layer, and using VDP2 to achieve "true" transparencies. I don't know that anyone did that back in the 90s - they used mesh because you simply turn it on with a boolean and call it a day.

I believe only burning rangers did to the frame buffer, that's where XL2 got the idea

 

[fafling]

Grandia does a similar stuff during combats, the difference is that it transfers a 1st pass of vdp1 background sprites to a vdp2 layer displayed under a 2nd pass of sprites made semi-transparent by vdp2.

I see this in many many Saturn games where games use two types of transparency - Mesh and true. Why use mesh when true transparency is already achieved? For example in the game Bulk Slash , transparency on the mech's shadow is mesh whereas real transparency is used on the HUD and radar. Can someone please explain this?

This is a good presentation of the different possibilities and limitations to achieve semi-transparencies on Saturn : [Low Score Boy] Sega Saturn Graphic In-depth Investigations (English/French subtitled)

A complement to that video is that VDP2's basic color blending capability is one blending operation per screen pixel in normal resolution. So where 2 semi-transparent VDP2 layers overlap, the 2nd one becomes opaque to what's behind it. By enabling a mode called extended color calculation, it's possible to make VDP2 do an additional blending operation per pixel, but it has a fixed half-transparency ratio, and it generally requires to halve VDP2 color ram size. That extended color calculation mode wasn't used often (the most intensive use of it I know of is in Sonic R). There are various reasons for that :

• The documentation was at the end of the beefy VDP2 manual and it was explained in a rather convoluted manner.
• It was not well exposed in programming libraries.
• It didn't always fit well with how the games graphics were set, or the amount of VDP2 color ram they needed.