Since the Saturn is the first '3D console' reviewed for this series, let us first go over the fundamental design changes that made way for the new generation of 3D graphics.
Revised methodologies
Firstly, the GPU now relies on a frame buffer: graphics are no longer required to be rendered on the fly. Instead, the GPU reserves a portion of Video RAM (VRAM) to draw a bitmap containing all the computed geometry requested by the CPU. A video encoder then picks up that region and outputs it through the video output signal. Be that as it may, the Saturn does mix the two models... I will explain more later.
Consequently, having this reserved 'working space' allows the GPU to continue manipulating the bitmap even after finishing rendering the scene, enabling the CPU to offload additional exhaustive tasks (such as lighting and anti-aliasing) to the GPU. Here is where the concept of graphics pipeline starts to gain significance.
Secondly, more VRAM is required: Using a frame buffer increases memory requirements (which is no longer a major issue). The amount of RAM required for a frame buffer is proportional to the screen dimensions and the number of colours used (a.k.a. colour depth). As an example, 600 KB of VRAM can contain a frame buffer of 640x480 pixels at 32k colours (16 bits per pixel).
Additionally, programmers are free to organise their VRAM usage: not every bit must be allocated for the frame buffer. So, why not also use it to cache textures, render other frame buffers concurrently, and add colour lookup tables to speed things up?
Finally, the CPU incorporates vector operations: a GPU with 3D capabilities would be incomplete without a CPU capable of feeding the required geometry. For this reason, next-generation CPUs feature some form of specialised instructions that accelerate vector calculations; these are known as Single Instruction Multiple Data (SIMD) extensions. Nonetheless, their design across the industry will be far from standardised.
In the case of the Saturn, vector operations are accelerated by the Saturn Control Unit, not the SH-2 CPUs.
Sega's offering
This console includes two proprietary GPUs: the VDP1 and VDP2. Each serves a different purpose while operating concurrently. Some might argue that the new GPUs are an evolution of the classic VDP, while others may claim it's a complete redesign... I think it's a bit of both.
With that in mind, let's take a look at the two chips.
VDP1
Architecture of the VDP1.
The Video Display Processor 1 (VDP1) is a chip that draws sprites with geometric transformations . The results are written to a frame buffer, which is subsequently streamed to the VDP2 for display.
This chip is programmed by issuing drawing commands. So, programmers are provided with 512 KB of dedicated RAM to store these commands, along with the necessary materials (textures/tiles, colour lookup tables, etc.) to process them.
Consequently, the VDP1 is designed to use quadrilaterals as primitives, meaning it can only compose models using only four-vertex polygons (sprites). The chip applies Forward Texture Mapping to connect texture points onto the quadrilateral, in that direction. It doesn't come with any filtering or interpolation techniques, so the rendering is subject to aliasing.
The VDP1 also provides this selection of effects:
- Two shading algorithms (Flat and Gouraud) for lighting.
- Anti-aliasing: In this case, it duplicates pixels to cover gaps during texture mapping.
- Clipping to discard polygons outside the camera's viewport.
- Transparency to blend two non-opaque bitmaps.
Two 256 KB frame buffer chips are available to concurrently draw new scenes of the game without breaking the current one being displayed. When the secondary buffer is finished being drawn, the VDP1 switches to broadcasting that one instead, and the cycle repeats. This technique is called page flipping.
VDP2
Architecture of the VDP2.
The Video Display Processor 2 (VDP2) specialises in rendering large planes (up to 4096×4096 pixels) with transformations (rotation, scaling and translation) applied .
More importantly, the VDP2 renders on the fly (without a frame buffer), much like earlier tile-based engines. It supports up to 16.7 million colours (24-bit).
This chip is also responsible for displaying the VDP1's output buffer, which can itself be transformed and mixed with the VDP2's layers. The VDP2's 'frame' consists of up to four 2D planes and one 3D plane, or just two 3D planes.
This chip relies on tile-maps to compose planes and applies perspective correction for 3D texture mapping. This is a more sophisticated approach that accounts for the depth value when computing rotations.
Effects available include:
- Multi-texturing for mapping more than one texture onto a single polygon.
- Shadowing: after the VDP2 receives the sprites generated by the VDP1, it can reduce their brightness and blend them with half-transparency.
- Nonetheless, the VDP2 only receives a sprite stream from the VDP1 (in pace with the CRT beam) so this function tends to be tricky to encode and operate.
This chip also houses 4 KB of Colour RAM (CRAM) which is used to translate the VDP1's custom colour values (indexed colours) into 24-bit RGB colours.
Finally, even though the VDP2 is limited to two 3D planes, nothing prevents the CPU from using its VRAM as a software-based frame buffer to render additional 2D or 3D graphics.
If this section got your attention, I recommend checking out the sources at the end, the VDPs have a lot more interesting quirks that lie beyond the scope of this article.
Defining the problem
As you can see, the architecture of the graphics subsystem is quite complex, and its interpretation often varies depending on the needs:
As a powerful 2D console
The capabilities of the Saturn for drawing 2D scenes were vast compared to those of the Mega Drive or SNES, although they were not the console's main selling point.
For a quick demonstration, I will use Mega Man X4 (1997) as an example.
Sprites
The VDP1's Sprite plane.
In this case, the VDP1 is tasked with plotting traditional sprites without any 3D distortion applied.
The CPU sets up the VDP1 by writing to its registers and populating its VRAM with commands and tiles. The process can also be accelerated using the DMA controller.
Backgrounds
2D plane 1.
2D plane 2.
2D plane 3.
The VDP2 is then instructed to draw background planes. These, together with the sprite layer, are automatically composited to form a fully coloured scene.
The commanding part is fundamentally similar to that of the VDP1: programmers have access to registers and VRAM to configure the chip accordingly.
Certain VDP2 functions can be exploited to create more realistic scenery, such as scaling effects to simulate a heat haze, as seen in the '2D plane 2'.
Result
Mixed planes (Tada!).
Not much mystery here, the VDP2 handles the last step of passing the processed signal to the video encoder.
The VDP2 operates in sync with the CRT beam, meaning that its ongoing computations correspond to the pixels due to appear on the upcoming scan line.
As a challenging 3D console
Here's where the Saturn both shone and struggled at the same time. While this console had eight processors to take advantage of, it ultimately came down to:
- Whether programmers would be able to master most of the console's features during a small time frame (remember the console's commercial lifespan would effectively end once its successor was released, or even announced).
- Whether their game could ship within a reasonable date.
For this reason, game quality varied dramatically from title to title, with each studio coming up with unique approaches.
3D modelling
3D models of characters without textures or background. Notice the primitives used to build the models.
Virtua Fighter Remix (1995).
So far, previous examples used individual regular quadrilaterals to form sprites and/or background layers. But what if we group multiple irregular primitives and arrange them to form a more complex figure? This is how 3D models come to fruition.
To put it in simple terms, classic 2D consoles like the Super Nintendo arrange their graphics (backgrounds and sprites) in quasi-rectangular areas. In some cases, such as with Mode 7, programmers can supply a rotation matrix to apply transformations to some of these areas. The Saturn, by contrast, allows developers to define four-point quadrilaterals with arbitrary angles between their edges - Sega calls them distorted sprites. Then, the VDPs' texture-mapping capabilities paint the quadrilateral's area with a texture, which is scaled to conform to the polygon's shape.
In terms of operations required in a 3D game, the CPUs and SCU are tasked with formulating a 3D world and projecting it onto a 2D space. Then, both VDPs are commanded to render it, apply effects, and finally broadcast it to the television.
Pixel processing
Rendered scene with 3D models and backgrounds.
Virtua Fighter Remix (1995).
Either VDP can draw the newly projected 3D space and stamp textures and effects. However, which chip is 'in charge' varies from game to game.
Some developers prioritised the VDP1 for rendering nearby polygons, leaving the VDP2 to handle distant scenery. Others devised clever workarounds that allowed the VDP2 to draw closer polygons (thereby offloading the volume of geometry passed to the VDP1). The core challenge lies in designing an efficient engine capable of displaying impressive graphics while maintaining an acceptable frame rate.
The new designs
These are some examples of characters that were redesigned specifically for this console. I initially built an interactive model viewer for the website edition, and later adapted the visualisations for the physical formats.
Interactive model available in the modern edition
Sonic in Sonic R (1997).
185 quadrilaterals.
Interactive model available in the modern edition
Tails in Sonic R (1997).
254 quadrilaterals.
While the Saturn is only able to draw quadrangles, the Wireframe view exhibits two triangles in place of a single quadrangle. This occurs because the modern format used to encode this model (glTF, an open standard for contemporary 3D modelling), allowing modern devices to still render it, doesn't support quadrangles at the time of this writing. This behaviour is not apparent in the Surface view.
In a way, this highlights how modern graphics technology can struggle to faithfully emulate their ~30-year-old predecessors!
An introduction to the visibility problem
When 3D polygons are projected onto a 2D space, it is crucial to determine which polygons are visible from the camera's perspective and which are hidden behind . Otherwise, models are not drawn correctly, effects like transparency appear broken, and hardware resources are wasted.
This process is widely known as Visible Surface Determination or 'VSD', and it's a fundamental challenge in the field of computer graphics. Numerous publications describe algorithms that tackle this issue at different stages of the graphics pipeline - some offering highly accurate results, while others sacrifice precision in favour of better performance.
Now, unlike academic or professional-grade equipment, consumer hardware is severely constrained, meaning the choice of algorithm is often restricted to only a few options... or none whatsoever.
Project Z-Treme , a 2019 Homebrew engine. It ditched Z-sort in favour of a Binary Space Partitioning (BSP) approach, fixing many glitches.
The Sega Saturn's approach is what I consider a semi-solved case. The VDP1 doesn't implement any VSD functionality: you either feed the geometry in the correct order or you get a mess. However, Sega provided a graphics library known as 'SGL' that implements a solution called Z-sort or Painter's algorithm . This performs polygon sorting in software.
Essentially, SGL allocates a buffer to sort polygons by their distance from the camera (arranging them from furthest to nearest). Then, it issues the corresponding display commands to the VDP1 in that order.
One of the limitations of Z-sort in 3D environments is that its distance value (Z-order) is only approximated, meaning graphic glitches may still appear. For this, programmers may skip SGL in favour of implementing their own algorithms.
In later articles, you will see alternative approaches to visible surface determination. Some still rely on software, while others benefit from hardware acceleration.
The transparency issue
As part of its own set of colour math, the Sega Saturn is capable of rendering half-transparent graphics - that is, blending overlapping layers of colours to give the illusion we can see through them (a.k.a. translucency). However, there are significant caveats to this functionality :
- Only the VDP2 can blend pixels with half-transparency, while the VDP1 only outputs a rendered buffer, with no distinction between overlapping sprites. As a result, overlapping half-transparent sprites occlude the ones beneath.
- The VDP1's forward texture-mapping process corrupts half-transparency when applied to distorted sprites (i.e. polygons).
- Half-transparent pixels require six times longer to draw.
As a workaround, 2D games can activate the 'mesh' property on a texture. With meshed textures, the VDP1 sets the odd X/Y texture coordinates as 'fully transparent' (i.e. empty), allowing layers beneath to appear through. Curiously enough, when the console is connected to the television via the composite video signal (a standard at the time, aside from RF) the mesh pattern appears blurred. This accidental but effective consequence provided a way to simulate half-transparency .
Nevertheless, the opaque portions of a mesh would still occlude other sprites. Moreover, this didn't resolve the issue for 3D games. In the end, some titles had no option but to ditch half-transparency altogether... yet some studios found ingenious fixes, take a look at these two cases.
Video - Sega's Daytona (1993).
Video - Traveller's Tales' Sonic R (1997).
In both examples, the game commands the VDP1 to draw foreground objects and background scenery. In turn, the VDP2 renders the landscape imagery far away, and overlays the HUD statistics in front of the 3D models. Consequently, the VDP1's 3D models (rendered as distorted sprites) are unable to employ half-transparency; this prevents them from naturally blending with the VDP2's layers.
Nevertheless, the two games exhibit different behaviour. During gameplay, the background of Daytona pops out of nowhere (as half-transparency is disabled). In contrast, Sonic R achieves not only half-transparency but also a fading effect. Traveller's Tales devised a workaround by adjusting the 'mix ratio' registers of the VDP2 (used for defining the texture's alpha) and manually switching the lighting levels as the character gets closer .