Be Newsletter

Table of Contents

• BE ENGINEERING INSIGHTS: The DR8 Graphics World By Pierre Raynaud-Richard
• DEVELOPER TALK: David Jeske
• Strange Turns on the Way to the Port, By Jean-Louis Gassée
• BeDevTalk Summary

---

BE ENGINEERING INSIGHTS: The DR8 Graphics World

By Pierre Raynaud-Richard
In the upcoming release of the BeOS(TM), Developer Release 8 (DR8), we introduce two new kits and assorted new and improved API to help satisfy the needs of developers who work and play in the graphics world. The new kits are:

• The Game Kit, our first pass at delivering specialized API that fits the needs of digital game designers

• The 3D Kit, an "in-box" solution for designing, rendering, and interacting with three-dimensional figures and settings

This article gives an overview of the design philosophies and features of these two kits and also looks, briefly, at the state of the graphics card API. If you want to read more (much more) about the 3D Kit, visit the Be world-wide web site, where you'll find a new 3D Kit white paper (http://www.be.com/developers/3DWhitePaper.html).

But first, you may have read that Be has recently licensed OpenGL®, the popular 3D programming interface. The implementation of OpenGL® that we'll initially support is based on the latest library and toolkit from Silicon Graphics. Unfortunately, the implementation won't be ready until after DR8. In the future, we'll optimize our OpenGL® implementation for the BeBox: We'll drop into assembly language for critical sections, support accelerated 3D graphic cards, and provide parallel 3D processing.

The Game Kit

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

Graphics Driver API

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.

The 3D Problem

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 3D Kit Solution

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.

3D Kit Overview

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 in DR8

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!

---

BE DEVELOPER TALK: David Jeske

E-mail: jeske@igcom.net
URL: http://www.igcom.net/~jeske/

To pay my way through college -- and for fun -- I've mostly done software work. While at school (the University of Illinois at Champagne-Urbana) I started to focus on hardware, both for a challenge and a change. Currently, I do ASIC system-level simulation and design at S3 Inc. I'm planning to go through some of the different chip and system-level hardware design stuff and then make a decision about where to go next (stay in it, go back to software, go to management, who knows).

Four years ago I started DCFG Software. Just two of us wrote, sold, and supported multiline teleconferencing software called Gtalk. We didn't sell tons of copies, nor did we make tons of money. However, both of those factors were more limited by our commitment to staying and finishing school than anything else. But when I have some spare time and a project, I'll put it back together. When I get a project that looks like it'll go somewhere big, I'll run with it.

In my spare time I work on several different free projects on the internet. Recently that includes working on the VSTa microkernel operating system (http://www.igcom.net/~jeske/VSTa/) and doing occasional updates for a trackerized music file player (s3mod) that a friend of mine and I wrote for UNIX platforms.

The BeBOX gets me going for a few reasons:

• Symmetric Multiprocessing. I want to have an SMP machine on my desk. Simple as that.
• Newly Written OS. Because of compatibility issues, an aging OS will run into limitations when trying to advance for the future. I'm willing to accept throwing out all the old stuff to gain the benefit of starting from something new.
• The People. The folks at Be seem not only very excited and behind what they themselves are doing, but they're also very in touch with their developers (fans). It reminds me of everything I loved about the direct lines of communication, feedback, and rapid product improvement I experienced with my own startup.

---

Strange Turns on the Way to the Port

By Jean-Louis Gassée

This week we're announcing and demonstrating the availability of the BeOS on Power Computing and PowerMac hardware. We like the retrospectively obvious feel of the move, always a good sign. But I must admit it wasn't always that clear. As usual, others thought of it before us: "I like the multiprocessor idea, but I have this PowerMac, why can't I run your OS on it, in monoprocessor mode?"

The idea was in the air. It would be nice to suggest we listened thoughtfully, built consensus around the project, updated our mission statement, revised the business plan, allocated resources, and carefully scheduled the project. In fact, an external trigger precipitated the whole process.

The last Friday before Apple's May '96 developers' conference, around 3 pm, a voice-mail message told us we couldn't show the BeBox in the exhibits section. This was four months after we'd received and accepted an invitation to buy exhibit space. It turned out be a misunderstanding, quickly and courteously cleared up after the weekend. But in the meantime, a few minutes after we received the message, the PowerMac port was conceived. We were not Macintosh developers, said the message. Let's quickly port the BeOS to a PowerMac, suggested Bob Herold, one of our founding engineers. We had to have a name for the project. Our VP of Engineering, Erich Ringewald, came up with the winner: OS Doubler.

After the conference, our friends at Power Computing offered to lend us hardware and technical support. Later, Apple executives and hardware engineers provided very useful technical data. After two and a half months of work, the port works nicely on Power Computing and PowerMac systems. From the very beginning of the company, Bob Herold has been in charge of the lowest layer of the system, where software interacts with the minutest details of the hardware. He led the 1994 port from the AT&T Hobbit processor to the PowerPC. This time again, working with Dominic Giampaolo, Pierre Raynaud-Richard, Brad Taylor, Marc Ferguson, and other members of the Be software team, Bob led the project to a successful and timely completion. Good team, good work, you'll say -- but what does it mean?

First, for Be developers, the space for their applications is no longer contained by Be hardware. It would be imprudent to advance lofty projections at this stage, but MacWorld will give us an early indication of acceptance in the Mac community.

For users, it is a low-risk opportunity to get acquainted with our OS. You lose multiprocessing and Be's richer and less-expensive PC clone organ bank I/O, but you can always buy a BeBox later. Or, if you want to run the BeOS on a portable computer, you don't have to hire a personal trainer while you wait for the portable BeBox.

For the informal PowerPC alliance, the benefits are less easy to assess. The broader availability of a fresh, high- performance MP OS might assist with the protracted birth of a really unified hardware platform, the equivalent of the PC/AT in the Intel world. As we've often said, once such a reference platform really firms up, we'll be on it in no time, and we'll be happy to collaborate on the definition of MP extensions. Some Power Computing systems have a slot for a second processor; we'll see how we can make good use of it in the meantime.

For us (here we enter a delicate area), this port gives us a good benchmark for the performance of our system software. The hardware variable is removed. As a result, it becomes easier to see the performance and programming advantages of the BeOS.

We still have much to do and much to prove. We have to verify the quality of the port before we start charging for it. The BeOS itself needs more work and more evangelizing among developers. And we'll have to deal with questions such as: Are we getting out of the hardware business? The answer to that one is easy: No. We do provide competitive MP and I/O-rich solutions at the low end of the price range and, for lack of system software, no one seems to be interested in building four-processor 604 digital media screamers. We are. Other questions don't have easy answers yet. Such as integrating or encapsulating the Mac OS. Nonetheless, this is a good, pleasant step in expanding our horizons and we're grateful for the little push we received last February.

---

BeDevTalk Summary

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads. To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.

• ---- WEEK 4 ----------
  Subject: Speaking of PostScript...

  More (but not much) on MIME's hierarchical file types. How about MIME for e-mail messages but not for files on disk? The proposed reason: To avoid the MIME overhead. It was countered that there is no MIME overhead (or need not be, anyway).

• ---- WEEK 4 ----------
  Subject: First Experiences

  The proposed CPU "snooze" mode is (once again) frowned upon.

• ---- WEEK 3 ----------
  Subject: Root Directories
  A/K/A: Root Dir Proposal

  An answer to last week's question ("Is RDB prone to viruses?"): No more than any other boot sequence that pulls data in from all over. This expanded into a more general discussion of security; if the BeBox is primarily a "multimedia tool," should the security be as tight as for, say, a general workstation. The "tool" assertion rubbed some folks the wrong way: The BeBox is more than a real-time audio/video streamer.

  Also, automounting: Can/should the BeOS autodetect a new CD (for example)? Does CDPlayer (which has some form of autodetection) poll?

  THE BE LINE: CDPlayer polls SCSI CD-ROM drives to detect a new disk. In DR8, the Browser will do the same. In both cases, the polling frequency is quite low.

• ---- NEW ----------
  Subject: More Font Info
  A/K/A: Unicode

  The question "How do you discover whether a font is a bitmap or an outline?" turned into a larger discussion of the Be character set. Should it be ISO-Latin-1? Unicode? A list of attributes for an ideal font system was offered.

• ---- NEW ----------
  Subject: Printing and Stuff...
  A/K/A: Imaging Model
  A/K/A: The Math of Graphics

  What should the imaging model be? PostScript is on the tips of tens of tongues -- but there's a lot of hesitancy about actually spitting out the name. In theory, most folks would like to have the flexibility and power of a PostScript imaging back-end, but what would the cost be, both in speed and dollars (as in licensing from Adobe)?

  Soon after the thread was renamed "Imaging model," someone breathed "rotation" and we were off to 3D matrix land, thus betraying the new name. It was urgently hoped that the 3D Kit would use 4D matrices in which to compose 3D transformations.

  We also got an overview of the "Continuum Hypothesis," an unprovable (and so highly devtalk-appropriate) mathematical theory.

  THE BE LINE: Pierre Reynaud-Richard (author of the 3D Kit) dashed the 4D transformation matrix hopes -- the Kit uses 3D matrices. Although the 4D matrix is a convenient notation, 3D composition is less expensive, particularly on a single FPU machine. (However, if you add dedicated 3D/FPU/array processing hardware, the game changes.)

• ---- NEW ----------
  Subject: OpenDoc Anyone?

  Should Be adopt OpenDoc (and SOM)? Folks responded with an emphatic and nearly uncontested "Yes." There was some rumbling about the size and (slow) speed of OpenDoc systems (CyberDog in particular); also, it was opined that a good OpenDoc port would take at least a year. Would CORBA be faster (both porting and running)?

• ---- NEW ----------
  Subject: File Formats and File Typing...

  The MIME, 4-byte file type, document/application assignation debate comes back to life.

• ---- NEW ----------
  Subject: Multi-User Implementation of BeOS
  A/K/A: Multi-User BeOS and Security.

  Discussions on the proposed multiple-user BeOS; specifically, how should network access be handled? Is inetd (or something like it) possible in an environment where sockets aren't inherited? The subject of network security was raised and branched into cryptography, ITAR, and whether it's better to be a criminal in the US or in France.

• ---- NEW ----------
  Subject: Multiheaded BeOS and Down with the Network Computer

  A call for mulitple monitors (and keyboards and mice) per single BeBox. This led to a more general discussion of how the hardware would need to change to support such a thing. FireWire was requested.