Saturn graphics question

I'm curious about something. Saturn is well-known for having awesome 2D sprite power. That said, I've seen several games in which there is an ugly checker board effect on some sprites. In Mortal Kombat Trilogy, the characters' shadows are checkered. Cyber Speedway also has checkered textures. I've seen checkering in many other games as well, but I don't remember their names off the top of my head.

My question is, was that just style choice, or was there a technical reason for it?
 
Have you ever played a Saturn on a CRT?
If you did, you would likely use S-Video or composite video. These video signals mask the checkerboard pattern and turn it into transparency.
That is what you are looking at; it is an antiquated but very cheap and effective way to achieve 50% transparency.

Make no mistake; this method is preferable in many situations since it always works, provided the video is being output via composite\s-video to a CRT. The other methods of hardware transparency are more complicated and computationally expensive.
 
Yeah I always play my '90s consoles on a CRT. My Saturn is connected with composite video.

Although the games I mentioned above when I saw the checkering were from videos I watched on a computer. I don't have a very big physical library for Saturn. Now that you have explained that, I might look up videos of games I have so that I can see if I see the checkering on my computer screen, and then compare that to my CRT.

Update: I have GunGriffon, so I looked that one up. It did show checker board effects on YouTube, but not on my CRT. You are right. Thank you, I never knew that resulted in translucency on CRTs. That's pretty cool; I learned something.
 
Last edited:

It's a pity that this article is wrong on this : "The Saturn is not capable of handling transparency effects between sprites."

Fortunately, the Low Score Boy video the article is based on doesn't do that mistake :
https://www.youtube.com/watch?v=f_OchOV_WDg

With its half transparency mode, VDP1 can blend RGB sprites together (but not with VDP2 or palette sprites background where it's opaque).

The article confuses VDP1's half transparency with how VDP1 can set a palette sprite to be blended by VDP2 to the VDP2 background (but not with other sprites). VDP2 blending can be set to use a set of 32 ratios or additive blending, not just half transparency. Case in point, in the articles's Guardian heroes example, the cape sprite is indeed blended by VDP2 with the background, but not with a half transparency ratio, it's using additive blending.

On top of being limited to RGB sprites to work correctly, VDP1's half transparency is about 6 times slower than opaque drawing and exhibits overdraw artifacts where it's applied several times inside a sprite when the sprite shape is pinched.

VDP1's mesh effect has the advantage of making a sprite semi-transparent to both other sprites and to the VDP2 background, whatever the texture type of the sprites, whatever their shape, and without performance penalty. The drawback, aside of the dithered look on sharp displays, is that mesh is not a cumulative effect : it erases any sprite already drawn with mesh on the same area.
 
I'm interested in this and asked an AI.
The Sega Saturn utilised two separate video display processors:

  • VDP1: Handled 3D polygons and sprites.
  • VDP2: Handled 2D background layers, scrolling planes, and the final image composition.
VDP1 had a fatal flaw regarding transparency. It could theoretically do half-transparency (alpha blending), but it wrote directly to its own frame buffer. If you tried to overlap two transparent VDP1 polygons (like a laser beam passing behind a transparent window), the hardware couldn't accurately read the pixel data underneath to calculate the Math. The result was severe graphical corruption, black boxes, or artifact.

To avoid this, most developers simply abandoned true transparency on the Saturn, relying on "mesh" (a chequerboard dither pattern) to fake translucent surfaces.

The Solution: The VDP2 Bitmap Target​

While VDP1 was terrible at blending, VDP2 was an absolute powerhouse at colour Math. It could perfectly blend multiple layers together using up to 32 levels of smooth transparency, but it only worked on 2D background layers.

To get flawlessly transparent 3D objects (like the water in Sonic Jam's Sonic World or the energy shields and fire in Burning Rangers), programmers effectively hijacked VDP2 by turning it into a secondary renderer for VDP1:

  1. Isolate & Render: The engine would take all the 3D objects that needed to be transparent and render them as completely solid, opaque objects using VDP1.
  2. The Brute-Force Copy: Instead of sending this frame to the TV, the system used the Saturn's System Control Unit (SCU) DMA (Direct Memory Access) to rapidly copy that rendered frame buffer into VDP2's VRAM.
  3. The Blend: They configured one of VDP2's background planes to act as a raw Bitmap layer. The copied VDP1 frame was mapped to this bitmap. VDP2 then layered this bitmap over the rest of the game world, applying its flawless hardware colour calculations to make the entire layer smoothly transparent.

The Cost: Bandwidth Starvation​

While the visual result was mathematically perfect and looked incredible, it was brutally inefficient.

Moving an entire screen's worth of pixel data across the Saturn's internal memory bus 30 to 60 times a second consumed massive amounts of memory bandwidth. The Saturn's dual CPUs (and other components) had to pause and wait while the bus was choked by this massive data transfer.

Because it essentially crippled the system's overall speed, the trick could only be used in highly optimised games by developers who deeply understood the Saturn's architecture. It remains a legendary example of software engineering brute-forcing a hardware limitation.
 
Last edited:
Back
Top