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

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
 

Attachments

  • IMG20240604215404.jpg
    IMG20240604215404.jpg
    1.5 MB · Views: 0
  • IMG20240604215417.jpg
    IMG20240604215417.jpg
    1.7 MB · Views: 0
  • IMG20240604215429.jpg
    IMG20240604215429.jpg
    1.3 MB · Views: 0
Last edited:
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.
 
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
 
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.
 
  • 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.
VDP1 half-transparency won't make sprites "disappear", it will in fact create proper transparencies regarding sprites underneath them (as long as every sprite is in RGB format). But it has the pixel rewrite bug, and sprites will appear opaque on top of backgrounds which looks horrifying. It is the VDP2 transparency that has the "disappear behind other sprites" problem, because VDP2 transparency works by averaging together a sprite and a background, and whatever was "under" the sprite was already overwritten in the VDP1 framebuffer.

Meshes worked on both sprites and backgrounds equally, and had no performance penalty.

That extended color calculation mode wasn't used often (the most intensive use of it I know of is in Sonic R).
I think Cotton Boomerang may have used it, it has 4-5 transparent layers on some levels.
 
I think Cotton Boomerang may have used it, it has 4-5 transparent layers on some levels.
Although Cotton Boomerang does display many semi transparent elements at the same time, if you look closely frame by frame, where 2 semi transparent layers overlap, only the 2 topmost layers are blended and the 2nd one is opaque to what's behind. So it doesn't use extended color calculation.

For example, in the ice cave level, the light blue background area at the top right becomes progressively hidden by 2 semi transparent ice layers as they overlap on top of it :
1723151885771.png


https://youtu.be/5WQeJjgopB0?t=926

In fact if that game used extended color calculation, it would be a bit jarring as extended CC forces half transparency ratios between the lowermost layers instead of whatever CC setting there is on those layers.
In the case of Cotton Boomerang, it doesn't use ratios, but "as is" CC, which is additive blending.
So if extended CC was enabled in that game, a layer going behind 2 semi transparent others would go from additive to half transparency blending, which I can guarantee would be obvious even without using frame by frame because an area faintly visible with additive blending becomes a dark area in half transparency.
 
Back
Top