This shows you the differences between two versions of the page.
documentation:development:opera:pf25:ppgfldr:ggsfldr:gpgfldr:1gpgb [2023/01/10 21:48] – created - external edit 127.0.0.1 | documentation:development:opera:pf25:ppgfldr:ggsfldr:gpgfldr:1gpgb [Unknown date] (current) – external edit (Unknown date) 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Introduction to the 3DO Graphics Systems ====== | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | The 3DO hardware has three basic graphics systems that you can program: | ||
+ | |||
+ | * The //display generator//: | ||
+ | * The //cel engine//: //// projects color bitmap images into the frame buffer. It moves, scales, and merges the images at your option. | ||
+ | * The //SPORT bus//: //// Very quickly copies large blocks of data within VRAM. | ||
+ | |||
+ | Because the cel engine and SPORT bus are designed to write to pixels in the frame buffer, much of what they do makes no sense until you understand how the display generator turns frame buffer pixels into an NTSC display. | ||
+ | |||
+ | ===== The Display Generator ===== | ||
+ | |||
+ | If you look at the display generator as a black box with input and output (as shown in Figure 1), it's a simple processor. A bitmap image stored in a frame buffer goes in and an NTSC signal comes out that puts the image on a television screen. If you look a little closer at the input and output, though, you'll notice some strange discrepancies. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Figure 1:** //A simple view of the display generator.// | ||
+ | |||
+ | The input image (in a normal 3DO graphics display) is stored in a frame buffer that measures 320 pixels wide by 240 pixels high. Each pixel is 16 bits deep, with 15 bits to specifying color. That 15-bit color value can specify a total of 32,768 possible colors. | ||
+ | |||
+ | The display generator reads the frame buffer 30 times a second and puts out an NTSC signal of 30 frames per second. Each output frame has a resolution of 640 pixels wide and 480 pixels high-four times the resolution of the frame buffer. Each pixel in the output signal contains a 24-bit color value, a palette that offers over 16 million possible colors-512 times the available color values in the frame buffer. | ||
+ | |||
+ | Besides increasing the resolution and color depth of a frame buffer image, the display generator can also lay the frame buffer image over a second image such as a digital image from a source like a frame grabber. The background image shows through the frame buffer image wherever the frame buffer image contains a pixel designated as a background pixel. | ||
+ | |||
+ | To understand how the display generator increases resolution and color depth, and then adds a background image showing through background pixels, let's first look at how the display generator handles color. | ||
+ | |||
+ | ==== Color ==== | ||
+ | |||
+ | To increase color depth, the display generator contains sets of color lookup tables (CLUTs). A CLUT set uses the 15-bit color value stored in each frame pixel as a reference to a 24-bit color value stored in the CLUT set's registers. If you're familiar with traditional color lookup schemes, you'll find a major difference in the way 3DO's CLUT sets handle colors. | ||
+ | |||
+ | In a traditional color lookup scheme, a single CLUT provides enough registers for each possible pixel value. For example, an 8-bit deep frame buffer traditionally requires a CLUT of 256 registers, one for each possible 8-bit color value. Each register stores a 24-bit value that is put out each time a pixel color value accesses the register. | ||
+ | |||
+ | If 3DO graphics hardware used the traditional scheme, it would need a CLUT with 32,768 color registers, each holding a separate 24-bit color value-quite an array. To reduce the number of color registers, 3DO hardware reads each 15-bit color value as three color components: a 5-bit red value, a 5-bit green value, and a 5-bit blue value. It then provides a set of three CLUTs: one CLUT for red, one CLUT for green, and one CLUT for blue. Each CLUT contains 32 standard registers; each register contains an 8-bit red, green, or blue value. | ||
+ | |||
+ | When the display generator processes a pixel as shown in Figure 2, it reads the 5-bit red value, finds the corresponding register in the red CLUT, and puts out an 8-bit value in its place. It simultaneously does the same for the 5-bit green and 5-bit blue values, and merges the three 8-bit output values into a single 24-bit RGB (red, green, blue) color value. That's how the 15-bit color image in the frame buffer becomes the 24-bit color image that comes out of the display generator. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Figure 2:** //Color look-up table (CLUT) set.// | ||
+ | |||
+ | To show a second image in the background of a frame buffer image, 3DO hardware uses a special type of pixel with an RGB value of 000 which is declared a // | ||
+ | |||
+ | ==== Resolution ==== | ||
+ | |||
+ | The 320-by-240 pixel resolution provided by the frame buffer is designed to match the response characteristics of the NTSC signal-specifically, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Figure 3:** //Pixel weighting.// | ||
+ | |||
+ | Although each pixel can have only one cornerweight, | ||
+ | |||
+ | Before the display generator can use cornerweight information, | ||
+ | |||
+ | When interpolation is turned on, every pixel coming into the interpolator has a cornerweight. The cornerweight position can be a constant so that each pixel is weighted in the same corner, or the cornerweight position can be specified by each pixel so the position changes from pixel to pixel. To fully specify a cornerweight position, a pixel needs two bits-a challenge if 15 of its 16 bits are already used for a color value. To get these two bits, the pixel uses its unused bit for one, and then steals the low-order blue bit for the other. You'll find more details about a pixel' | ||
+ | |||
+ | When interpolation is turned off, the cornerweight position isn't considered. The pixels aren't interpolated and are more sharply defined-an effect known affectionately as " | ||
+ | |||
+ | ==== Controlling the Display Generator ==== | ||
+ | |||
+ | The display generator takes its orders from the VDLP (video display list processor), a graphics folio component. The VDLP turns pixel weighting on and off, sets CLUT register contents, controls background pixel handling, and does much more. It does so by reading a VDL (video display list) that contains display control commands. Each command is tied to a single display line, so the command executes just before that display line is rendered. This allows the VDLP to perform gymnastics such as completely changing the color palette contained in the CLUT set from line to line of the display. (You' | ||
+ | |||
+ | ===== The Cel Engine ===== | ||
+ | |||
+ | The cel engine isn't as straightforward as the display generator and to comprehend it takes some time. The easiest route to understanding the cel engine is to think of the it as a digital slide projector as shown in Figure 4. The slide it projects is a cel-a bitmapped image stored in RAM. The screen on which it projects the cel is the frame buffer. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Figure 4:** //A cel engine as a digital slide projector.// | ||
+ | |||
+ | A cel can be a large, complex image or it can be very simple. For example, a cel can use 15-bit color values for as many as 32,768 colors, or it can use 1-bit color values for as few as two colors. It can be larger than the frame buffer or it can be as small as a single pixel. Its bitmap can be compressed or uncompressed, | ||
+ | |||
+ | When the cel engine projects a cel into the frame buffer, it has many powerful options. Among them, it can scale the cel, expanding or shrinking it, or it can stretch the cel into an irregularly shaped quadrilateral with a 3-D feel. It can place the cel in different locations in the frame buffer, and with a regular succession of locations, smoothly move the cel across the frame buffer. The cel engine can change the look of the pixels within the cel, increasing or decreasing their color intensity for interactive lighting effects and merge them with the existing image in the frame buffer for translucent effects such as colored glass. The cel engine can also choose not to project the pixels at all, but merely alter the frame buffer pixels where the cel falls to create shadows and similar effects. | ||
+ | |||
+ | The cel engine brings considerable power to cel projection: it can render nine million pixels nonstop every second. That's 300,000 pixels every frame (which occur 30 times a second), which is four times the number of pixels in each frame. The cel engine can also project many cels at once; the maximum number is determined by the size and complexity of the cels and the minimum speed you want from the cel engine. | ||
+ | |||
+ | ==== Types of Cels ==== | ||
+ | |||
+ | A cel image can be used for many different purposes. It can be a small simple moving object, such as a distant airplane in a flight game; it can be a large, complex image such as a full-size digitized speaking face; or it may be anything between. Each use has its own optimal cel data type. Some uses require full color accuracy with 15-bit color values; others require only simple 2-bit color values. Some use large and stable bitmaps; others change their bitmaps constantly for animation and need simple, small bitmaps to keep up the animation speed. Still others require special shading data for each cel pixel. | ||
+ | |||
+ | 3DO hardware works with the following two cel data types which allow reduced pixel data size and increased information capacity per pixel: | ||
+ | |||
+ | * **Coded cel data types**, use color indirection and other schemes which allow more data to be included in each cel pixel. Coded cels can use 1, 2, 4, 6, 8, or 16 bits per pixel. Each coded pixel can include color and cornerweight information and may also include shading information. Because of color indirection, | ||
+ | * **Uncoded**, | ||
+ | |||
+ | You can use a coded or uncoded cel depending on what data you want to include for each pixel and on how many bits you want to dedicate to each pixel. You don't need to consider processing speed: the cel engine processes coded and uncoded cels equally quickly-it devotes only a single clock cycle per pixel. In fact, coded cels can sometimes have a shorter overall processing time than uncoded cels because they need fewer bus cycles to fetch the source data to the cel engine. | ||
+ | |||
+ | Both coded and uncoded cel source data can be compressed to further reduce the size of the data. The compression options include: | ||
+ | |||
+ | * **Packed**, which reduces runs of identical pixels to a description of a few bytes, compressing the size of the source data considerably. | ||
+ | * **Unpacked**, | ||
+ | |||
+ | Once the cel engine receives cel source data, it can process packed and unpacked cels at an equal pace, so at first it seems there' | ||
+ | |||
+ | **Note:** Under some circumstances, | ||
+ | |||
+ | ==== Processing Cels ==== | ||
+ | |||
+ | If you look at the cel engine in more detail, you see a two-stage black box as shown in Figure 5. The first stage accepts, unpacks, and decodes cel source data. It then sends the results to the second stage, which processes that data and projects it into the frame buffer. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Figure 5:** //Unpacking and decoding source data.// | ||
+ | |||
+ | The second stage' | ||
+ | |||
+ | * **Scaling the source color**, where the incoming pixel color values are increased or decreased to brighten or darken the pixels. | ||
+ | * **Merging incoming color data with data from a second source**, where the incoming pixel color values are added to or subtracted from pixel color values from another source (such as underlying pixels in the frame buffer), and optionally divided by 2 to average the color. | ||
+ | |||
+ | These effects are highly controllable and can vary considerably depending on how the cel engine processor is set and on what sources come into the processor. For example, the incoming pixels usually come from the cel source data (after unpacking and decoding), but they can also come from the frame buffer directly beneath the cel's projection position. This second option modifies the frame buffer image in the shape of the cel's pixel layout, creating a shadow, spotlight, or a rippling effect. Another option allows the underlying frame buffer pixels to be used as a secondary source for merging with cel pixels so the cel appears translucent over the frame buffer image. This creates an effect such as looking through a tinted car window or through a stained glass window. | ||
+ | |||
+ | The combinations of inputs and processing options create a mind-boggling set of alternatives and, of course, make the cel engine an even more challenging study. You can read all about the details in " | ||
+ | |||
+ | ==== Controlling the Cel Engine ==== | ||
+ | |||
+ | To create a cel that runs through the cel engine, you need three components: | ||
+ | |||
+ | * The source data, **** which contains data for each cel pixel. | ||
+ | * The cel control block (CCB), which contains information that controls the cel projection: the cel's projection location in the frame buffer, the size and shape of the projection quadrilateral, | ||
+ | * The preamble, which identifies the type of data in the source data: packed or unpacked, coded or uncoded, the number of bits per pixel, and more. The preamble is usually at the beginning of the source data, but can be included in the CCB if it points to different source data locations that contain the same type of data. | ||
+ | |||
+ | The preamble tells the cel engine how to process the cel's source data-whether to unpack the data or not, how to decode the data, and more. The CCB controls much of the rest of the cel engine' | ||
+ | |||
+ | ===== The SPORT Bus ===== | ||
+ | |||
+ | The analogy of the cel engine as a projector that projects onto/into the frame buffer fails in one respect: a real projector can move from place to place without affecting the background on which it's projecting. The cel engine projector writes directly into the frame buffer and leaves behind a series of images as it moves its projection across the buffer. To restore the frame buffer background as a cel projection moves across it, 3DO hardware offers the SPORT bus. | ||
+ | |||
+ | SPORT is an acronym for Serial PORT and is an added data bus for RAM chips in VRAM. The SPORT bus allows quick reads and writes of one or more pages of VRAM into one or more other pages of VRAM-which, if those pages contain a bitmapped image, can quickly copy an image from one section of VRAM into another. | ||
+ | |||
+ | ==== Frame Background Restoration ==== | ||
+ | |||
+ | 3DO hardware uses the SPORT bus to quickly restore a background image in the frame buffer at the beginning of each frame, before the cel engine projects cels over the background. To do so, the background image is stored outside the frame buffer as a bitmap in VRAM. The SPORT bus copies the VRAM image directly into the frame buffer very quickly, allowing time for the cel engine to project cels into the background before the frame is sent off to the display processor. When one frame finishes, the SPORT bus again copies the background image into the frame buffer for the beginning of the next frame. | ||
+ | |||
+ | By constantly restoring the background in the frame buffer at the beginning of each frame, the SPORT bus effectively turns the cel engine into a true projector that leaves no traces behind as it moves a cel across the frame buffer in a series of frames. | ||
+ | |||
+ | Now that you've taken the grand tour of 3DO graphics, you can concentrate on the specifics of display generator operation in " | ||