3D Game Programming with a Virtual Computer
This chapter is from the book
This chapter is from the book
This chapter is from the book
In This Chapter
Introduction to the Virtual Computer Interface
Building the Virtual Computer Interface
The T3DLIB Game Console
The T3DLIB1 Library
The T3DLIB2 DirectX Input System
The T3DLIB3 Sound and Music Library
The DirectMusic API Rapper
Building the Final T3D Game Console
Sample T3LIB Applications
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 Systems-level diagram of the virtual computer.
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?