The Game Kit is new in DR8. Its main feature—currently, its only feature—is the BWindowScreen class. Through the use of a BWindowScreen object, your application can take over the entire screen; no dock, no Browser windows, just the images that you want to display spread across the entire canvas. In addition, BWindowScreen knows about multiple workspaces, so you can set up a different BWindowScreen object in each workspace.

Other features of the BWindowScreen class include:

• More and faster control of the graphics card

• The ability to set different (possibly nonstandard) resolutions (sorry, no VGA yet)

• The use of multiple buffers or hardware scrolling

• Fast, asynchronous access to the color map

• Fast access to the graphics card's accelerated functions (they're copied into your application's memory space)

Best of all, everything is completely transparent to the BeOS, so the machine is still completely alive (unlike the deadly lock_screen() function that BWindowScreen replaces).

Note that most of the Game Kit's advanced features use the new API for graphic add-ons (described below). Not all of these features will be available for every card; a list of cards that work with the Game Kit will be published with DR8.

In a future release (we'll try for DR9), BWindowScreen will be extended to support standard VGA mode (the application will be responsible for setting specific modes using the standard VGA registers). The class will then be useful for much more than just displaying game animation. Other future release features include:

• Incorporation of the joystick into the Game Kit (note that you can find a new BJoyStick class in the DR8 Device Kit)

• Direct communication between BWindowScreen objects and the 3D Kit or OpenGL®

• Advanced feature support for a wider range of graphics cards

In DR7, we introduced a very simple and limited API for graphics drivers, in which drivers are loaded as add-ons. For DR8 we've slightly extended the graphics driver API, mostly to provide support for the Game Kit. Drivers that are using the DR7 version of the add-on API are still supported in DR8.

The graphics card add-on scheme isn't perfect yet. There are still a couple of important features missing:

• A minimal, specific set of accelerated 3D calls

• A general API for accessing a card's extended features

• The resolution/depth/refresh-rate settings need to be cleaned up

The changes that we've planned for DR9 are much more significant than those presented in DR8. For example, we'll probably rework the API for clarity and stability; because of this, existing graphics add-ons won't be compatible in DR9. We will, of course, provide new drivers for all the graphics cards that are on the official support list, so the incompatibility shouldn't be too painful for most developers. If you're developing a graphics driver and are worried about these change, please get in touch with us by e-mail, at graphics-card@be.com.

3D is an amazingly hard problem. We can easily identify the reasons:

• Three-dimensional descriptions are much more complex than descriptions in two dimensions

• Many programmers aren't at all comfortable with the mathematical tools that are used to handle 3D geometry

• Thinking in 3D isn't easy. The mapping of a three- dimensional object to a two-dimensional screen isn't always intuitive

For these reasons, 3D is mostly used for creating games, synthesizing pictures or frames of animation, and in expensive CAD programs. The needs of each of these three application domains is significantly different:

• Games don't need a general solution—their problems are very specific and controlled, but they have to be cheap, fast, and fun.

• Picture synthesis needs to be arbitrarily complex, which means the tools are complicated and numerous. Because of the complexity of the tools, picture synthesis is slow and can't be done in real time.

• CAD programs are, in a way, the worst of both worlds. Like picture synthesis, they have to allow descriptions of complex objects (and relationships between objects). But a CAD program must also provide a reasonable level of (near) real-time interaction.

To provide a solution to the problem, most of the available 3D libraries (including OpenGL®, Renderman, and QuickDraw 3D) are huge and complex. Consequently, the users of these products need to have a nontrivial level of 3D knowledge.

The two main goals of the BeOS have always been—will always be -- efficiency and simplicity. But is it possible to present a 3D solution that's both general and simple?

Frankly, no.

So if we can't have general simplicity, we'll choose "specific" simplicity: The 3D Kit, our "from scratch" 3D API, is simple and efficient, but it won't satisfy the furthest-out of the 3D innovators and synthesizers. Of course, we don't want to abandon the experts; that's why we've chosen to license OpenGL®.

So for professionals, our solution is OpenGL®; if you're just starting in the 3D world, or if you're doing "light-weight" 3D modeling and rendering, try the 3D Kit. In a future release, after we have OpenGL® up and running, we'll work on providing some level of interaction between the two, so that you'll be able to take advantage of the simplicity and efficiency of the 3D Kit's API and still have access to the completeness and generality of OpenGL®.

The main goal of the 3D Kit is to provide a 3D API that's simple; we want all programmers—particularly those that have never used 3D before -- to be able to incorporate 3D elements into their applications. That gives us three main problems to solve:

• Defining and designing three-dimensional objects (or "models"). This is an extremely wide problem. Currently, if you want to design something other than an elementary geometric figure you have to use an expensive and complicated CAD program.

• Breathing life into a 3D setting. After you've designed your objects, you have to place them in a three-dimensional world. Your objects have to be able to pass behind each other, bump into each other, bounce off walls, and so on. And it has to look "natural" (if not necessarily realistic).

• Allowing the user to interact with your creation. The tools that the user uses to interact with a 2D environment—the mouse and the keyboard, primarily—need to be remapped to allow manipulations in three dimensions. Teaching the user how to do this is difficult.

Solving these problems asks for much more that just a 3D rendering engine. Sticking with the BeOS philosophy of simplicity and efficiency, we've chosen to provide "medium- end" native rendering that the programmer can efficiently enliven and that the user can easily manipulate, rather than a high-end engine that's difficult and sluggish.

The 3D Kit is written in C++ and is highly modular and expandable. The basic elements of a 3D scene are separated into two categories, represented by separate C++ classes:

• The B3dBarrier class represents the static parts of the world, such as walls, the ground, or more generally, any unmoving "stage" inside of which the action takes place.

• The B3dBody class represents the dynamic, movable objects—the actors on the stage.

The three main properties of a B3dBody are its geometrical description (encapsulated in the B3dModel class), its appearance (the B3dLook class), and the way its parts are connected to each other and to other objects (the B3dLink class). Other properties can be added to a B3dBody, but these three will be optimized.

The B3dBarrier and the B3dBody objects are the only "real" objects in a 3D scene (or B3dWorld). But you need more than that to create a world. For example, you need the mathematical description of a light source that will illuminate the scene (B3dLight), and a description of the angle and distance from which you view the scene (B3dCamera). You can also use the 3D Kit to create "fake" objects (the B3dFakeBody), which are visible and which the user can manipulate, but which aren't really there. For example, you can use a B3dFakeBody to float a label near some "real" B3dBody object.

All of the "things" that you create (bodies, cameras, lights, and so on —objects that derive from the B3dThing class) are placed in a "world" (B3dWorld). Most worlds can be described as one of three types of environments:

• The first type of environment is a "closed world" (B3dClosedWorld); this is a closed space such as a room.

• Then there is a world that has a ground but no walls or "ceiling": The great outdoors, for example. We call this a "ground world" (B3dGroundWorld).

• Finally, there is the world without limits of any kind. Outer space. This is the "etheric world" (B3dEthericWorld).

There are many advantages to a strict definition of a world—the object constructors are simpler and more efficient, the rendering engine can make some cycle-saving assumptions. The main disadvantage of the architecture is that you have to choose a world and stick with it. But what if the world in your imagination is more complex than can be described in a single B3dWorld object. For example, what world do you choose if you want to place a little house (a closed world) on a prairie (a ground world)?

Fortunately, while a world can't change after it's been created, you can create more than one of them. Because the world isn't the biggest thing in the ... world. The universe is.

The B3dUniverse can contain any number of B3dWorlds. Not only can you have more than one world in your universe, you can define the interfaces (or "doors", instances of B3dDoor) between the worlds. The door concept is one of the most interesting parts of the 3D Kit; by connecting worlds through doors rather than building one huge world, you can "distort" the dimensions of the universe.

For example, imagine a door standing in the middle of a meadow. You open the door and enter into a large room that connects to other rooms. You walk back out into the meadow, close the door, and walk around to the other side. All you see is the back of the door. You open the door from this side and walk out onto a beach. The door acts like a science-fiction teleporter that can move objects instantly from one B3dWorld to another.

The 3D Kit is brand new in DR8, and so development hasn't advanced far. Very few of the advanced features are implemented (no B3dDoors yet, for example), and there will certainly be plenty of bugs. To help get you started, we'll publish the source to a simple 3D demo application.

So please take the DR8 3D Kit for what it is: Enjoy it if you can, but don't expect the world (OK, you'll get the world, but don't expect the universe). We hope you understand better now why we're not just porting one or two standard 3D APIs.

For more information on the 3D Kit, see the abovementioned white paper on our web site. The paper looks at the 3D Kit's classes and rendering engines in greater detail than allowed by this article.

Welcome to the 3D world!