A Brief History of 3D Game Graphics

The Games

In the beginning, there was 320 x 240, then 640 x 480 . . .

image from book
Figure 12.1: Screenshot of early 3D games.

image from book
Figures 12.2: Screenshot of early 3D games.

And it was good!

The game companies began to create games when no real-time 3D hardware was available for PCs other than expensive computer-aided design and virtual reality (VR) systems. Although these early games appeared to use 3D graphics, the characters were 2D images and the environments were not true 3D. Because there was no RT3D graphics hardware, the developers created custom software renderers that used techniques such as raycasting. The graphics were quite simple and low quality by today’s standard but still 3D-like and dazzling in their time.

The Hardware—Heavy Metal

In response to game players’ desire (and money) for improvements on existing and next-generation games, consumer-level graphics accelerator cards such as the Voodoo by 3dfx were produced. The Voodoo, as well as others, was a good start but depended a great deal on the CPU for frame rate. They used proprietary APIs to access the card’s full features, but it helped speed rendering up nonetheless. Unfortunately, at the time many 3D games and 3D cards were often incompatible, but it was still solid progress from the nonaccelerated hardware days.

After many years of 3D hardware production and competition, the 3D graphics video cards have become incredibly powerful components of a modern game system.

Even before PC games started using 3D graphics hardware, the U.S. military was using 3D graphics hardware for vehicle simulators. Evans and Sutherland were among the first to create RT3D for the military. Host computers were hooked up to separate boxes of graphics hardware called Image Generators (IGs). IGs were large machines costing millions of dollars, but they did the job at a time when nothing else could, and they are still used today for certain simulation applications.

The hardware used in RT3D started as federally sponsored university research. Ivan Sutherland, one of the founders of Evans and Sutherland, pursued a federally funded program of research in 3D graphics hardware at the University of Utah. Sutherland was also advisor to Jim Clark, who received his Ph.D. from the University of Utah and founded Silicon Graphics, Inc., in 1982. Joining the faculty at Stanford, Clark received support from the DARPA VLSI Program for his geometry engine project, with a goal to harness modern custom integrated-circuit technology to create cost-effective high-performance graphics systems. It was this geometry engine that formed the basis of Silicon Graphics’ technology.

Combining Graphics Hardware and Software with OpenGL

Silicon Graphics was the first company to merge IG-level graphics with computer workstations. To use that hardware they also created the very popular OpenGL RT3D rendering library. Although OpenGL was originally created for visualization on SGI’s high-end Unix workstations, as PCs became more powerful it eventually made its way onto consumer-grade systems. Once OpenGL was running well on PCs, game developers began using it for their 3D game engines.

Due to the enormous success of these games and the excellence of OpenGL-based graphics, OpenGL found a new life in the game industry. In addition, OpenGL was portable, that is, it worked (for the most part) across different graphics cards and hardware platforms, so it was ideal for developers who wanted cross-platform games.

OpenGL is now the foundation for many 3D game engines as well as a version of Java3D and JOGL, the Sun Game Technology Group Java OpenGL wrappers, which we will examine and use in later chapters.

OpenGL is the essential 3D library that lets you harness the power of hardware acceleration to thrust games into the realm of professional-quality rendering, texture mapping, and special effects. Almost all of the leading games (such as Quake III, Half-Life, MDK2, Baldur’s Gate, Decent 3, and Madden NFL 2001) require OpenGL for hardware acceleration.

Empowered and Bound by Hardware

With APIs such as OpenGL opening the door for game developers to control sophisticated graphics hardware, it wasn’t long before specialized graphics hardware became one of the major driving forces behind RT3D advancements. There are many things it can do, and even more it cannot. Often movie-frame renderers need far greater control and complexity than the specialized hardware can provide, and this is one of the many reasons movie rendering does not typically use 3D hardware for its rendering.

However, for 3D games, interactivity is a higher priority than absolute image quality. Therefore, the hardware is usually required to get the performance needed. Because the rendering is usually done entirely by this RT3D hardware, it is also limited by what the hardware can’t do. Those limitations are key issues to take into account when developing a full-blown 3D game engine.

The primary graphics primitives for 3D graphics hardware are triangles, lines, and pixels. There are many reasons why these are the only accelerated drawing primitives, including computing lighting, depth testing, and transformations. Some of these reasons will be examined later in this chapter; however, others are beyond the scope of this text. See the resources for more information.

The 3D hardware accelerates these specific primitives, so rendering performance can be measured by how fast these primitives can be processed and rendered.

Vendors use two major metrics to measure 3D hardware performance: the triangle process rate, or how many triangles the graphics card can process per second, and the pixel fill rate, or how many pixels the graphics card can draw on screen per second, usually measured in millions of pixels per second (megapixels/sec) Figure 12.3 shows renders of varying triangle and fill rate amounts.

image from book
Figure 12.3: The pixel fill rate and triangle process rate.

Although the final game performance is affected by many things, such as processing game objects, sound, and other game code, the hardware’s triangle process rate and pixel fill rate often have a direct effect on the game’s final frame rates.



Practical Java Game Programming
Practical Java Game Programming (Charles River Media Game Development)
ISBN: 1584503262
EAN: 2147483647
Year: 2003
Pages: 171

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net