In this chapter, we're basically going to build up a virtual computer
system based on a software interface. It will support a linear 8- or 16-bit
frame buffer (double buffered) and input devices, along with sound and music
capabilities. With this interface, we can focus the remainder of the book on 3D
math, graphics, and game programming. Here's what's in store:

The design of a virtual computer graphics interface

Building a Windows game console

The API listing of the enhanced T3DLIB library from Tricks of
the Windows Game Programming Gurus

Implementing the virtual computer with T3DLIB

The final game console

Using the T3DLIB game library

Introduction to the Virtual Computer Interface

The goal of this book is to teach 3D graphics and game programming. However,
my dilemma as an author is how to focus the book on just that, without talking
about all the low-level details of Win32 programming, DirectX, and so on. Even
though you should have some idea of Win32 programming and DirectX after reading
the last chapter, it's still a bummer. Alas, my solution is to create a
"virtual computer" based on the engine I developed in Tricks of the
Windows Game Programming Gurus that you will simply use as a black box, so
we can focus on the 3D graphics and game programming part. However, because of
the sheer size of the engine, we still have a lot to discuss.

NOTE

This is basically the approach that OpenGL takes. You use GL libraries and/or
add-ons that handle the low-level device-specific interfacing and housekeeping
of whatever system you're on, including opening windows and getting
input.

Ultimately, this really makes a lot of sense for a number of reasons. As long
as you can communicate with a double-buffered, linearly-addressable graphics
system that has support for input, sound, and music, who cares how it works? We
are interested in the 3D graphics programming, not the low-level setup. Because
99% of our work is going to be related to rasterization, texture mapping,
lighting, hidden surface removal, and so forth, this approach is feasible. So,
all we really need is a black screen, the capability to talk to the joystick,
keyboard, and mouse, and to maybe play some sound effects and
musicright?

Therefore, instead of trying to explain every single detail of Win32, the
DirectX foundation, and all that stuff (which I did in the first Tricks),
we are simply going to use the API I wrote for that book as a tool to create a
generic virtual computer on which we can run our 3D graphics experiments and
write our games. Sound like a planetoid?

Using this layer of indirection, most of the 3D code will be generic enough
that you could port it to Mac or Linux with very little work. All you would have
to do is emulate the low-level interfaces, such as the double-buffered graphics
system, sound, music, and input devices. The algorithms will stay the same for
all the 3D code.

The only drawback to using the engine from the first Tricks is that a
few of the data structures, and the design itself, were predicated on DirectX
itself. I wanted the thinnest layer to DirectX for performance reasons. Hence,
we could write another layer of software on top of my layer (which has some
DirectX-centric parts to it) and totally be machine-independent, but I
don't think it's worth the time. Bottom line is, if you want to port
the 3D stuff, and as long as you can create a double-buffered display,
everything will work. Sound, music, and input can be completely thrown away,
because my functions make nothing more than a call to the DirectX functions
anyway.

However, the thing to remember is that as long as you understand the API that
I give you, you really do not need to know anything about Win32 or
DirectX, because everything we do with 3D graphics simply consists of us, a
frame buffer, and C/C++ code.

The fun part about this book is that we are only going to focus on 3D
graphics and game programming. We are going to literally forget about all the
details of setting up DirectX, getting input, and making sounds, and simply call
API functions. We are going to accomplish this feat by creating a
virtual, or abstract, graphics computer specification, and then
implement it with the function API from the first Tricks. However, the
main point of the virtual computer is to help us focus on 3D and not the details
of the setup. With that in mind, here's the feature list you need to write
a 3D game on any computer in the world:

Be able to create a window or screen on the display with a desired bit
depth that is linearly addressable as a 2D matrix of pixels. Additionally, have
support for an offscreen page or double buffer, so that images can be rendered
offscreen and then copied or "flipped" to the primary display to
create smooth animation.

Be able to get input from the system input devices such as the keyboard,
mouse, and joystick. The input should be fairly raw and in a simple
format.

(Optional) Be able to load and play sounds and music in common
formats such as .WAV and .MID.

Figure 3.1 illustrates a systems-level
diagram of the virtual computer we want to design with software. I used to say,
"If I can plot a pixel and read the keyboard, I can write Doom."
It's true, all you need is the capability to access the frame buffer, and
then everything else is simple. Moreover, because this book is about software
3D programming and rasterization, none of our algorithms will use any form of
3D acceleration. We are going to draw the polygons, compute the lighting, and
everything else ourselves pixel-by-pixel in the frame buffer(s).

NOTE

You might be saying, why use software when hardware is available? The answer
is threefold: First, to be a great graphics programmer, you need to know how to
do it yourself; second, knowing how things work helps you better understand
acceleration; and last but not least, who will write the hardware code?