Be Advanced Topics; The Official Documentation for the BeOS

Be Advanced Topics; The Official Documentation for the BeOS

by The Be Development Team

What chance is there for a new desktop operating system to succeed in these days of Microsoft dominance? How about when that operating system is positioned as an alternative to the Macintosh, itself an endangered platform? Actually, the chances are pretty good! Just as Linux quickly established itself as the OS of choice for the independent UNIX developer community


What chance is there for a new desktop operating system to succeed in these days of Microsoft dominance? How about when that operating system is positioned as an alternative to the Macintosh, itself an endangered platform? Actually, the chances are pretty good! Just as Linux quickly established itself as the OS of choice for the independent UNIX developer community, the BeOS, available for both PowerPCs and Intel systems, provides exciting new features for independent multimedia developers. Anyone who has seen the BeOS in action experiences immediate techno-lust. Here is an operating system that speaks multimedia, threading, and multiprocessing as one who was raised speaking them from birth rather than as languages painfully acquired through second-rate schooling. This is the ideal platform for high-end graphics and multimedia, featuring Silicon Graphics performance and more on commodity desktop hardware.Be Advanced Topics picks up where the Be Developer's Guide leaves off. It's the official programmer's reference manual to advanced topics for this revolutionary new operating system. Much as Inside Macintosh galvanized the Mac developer community nearly 15 years ago with its under-the-hood access to the new art of GUI programming,Be Advanced Topics provides developers with access to the internals of the first really new operating system in many years. Describing the less commonly used kits in the operating system — the kits that don't pertain to every application — Be Advanced Topics shows you when and how to use them. Anyone who wants to design specialized applications for the BeOS will find this book invaluable.Topics covered include:

  • The Media Kit: Real-time processing of audio and video data
  • The Midi Kit: MIDI data generation and processing, including Headspace® General MIDI synthesizer
  • The Game Kit: Lets your game take over the machine
  • The OpenGL Kit: An implementation of the OpenGL® 3D graphics interface
  • The Network Kit: An interface to the network and mail
Also included in Be Advanced Topics is a third-party CD-ROM containing tools, applications, and other freeware designed specifically for the BeOS.

Product Details

O'Reilly Media, Incorporated
Publication date:
Product dimensions:
7.08(w) x 9.21(h) x 0.89(d)

Related Subjects

Read an Excerpt

Chapter 7: The Game Kit

GetClippingRegion( )

status_t GetClippingRegion (BRegion *region, BPoint *origin NULL) const

Sets the specified region to match the current clipping region of the direct window. If origin is specified, each point in the region is offset by the origin, resulting in a BRegion that's localized to your application's vision of where in space the origin is (relative to the origin of the screen's frame buffer).

Although the direct_buffer_info structure contains the clipping region of a direct window, it's not in standard BRegion form. This function is provided so you can obtain a standard BRegion if you need one.


The Get:ClippingRegion( ) function can only be called from the DirectConnected( ) function; calling it from outside DirectConnected( ) will return invalid results.

If you need to cache the clipping region of your window and need a BRegion for clipping purposes, you could use the following code inside your DirectConnected( ) function:

BRegion rgn;

This serves a double purpose: it obtains the clipping region in BRegion form, and it returns a copy of the region that you can maintain locally. However, it may be more efficient to copy the clipping region by hand, since the clipping rectangle list used by BDirectWindow uses integer numbers, while BRegion uses floating-point.

Return values:
IsFullScreen( ), SetFullScreen( )

bool IsFullScreen (void) const
status_t SetFullScreen(bool enable)

IsFullScreen( ) returns true if the direct window is in ftill-screen exclusive mode, or false if it's in window mode.

The value returned by IsFullScreen( ) is indeterminate if a call to SetFullScreen( ) is in progress-if this is the case, you shouldn't rely on the resulting value. instead, it would be safer to maintain a state setting of your own and use that value.

SetFullScreen( ) enables full-screen exclusive mode if the enable flag is true. To switch to window mode, pass false. The SupportsWindowMode( ) function can be used to determine whether or not the video card is capable of supporting window mode. See "Window Mode vs. Full Screen Mode" for a detailed explanation of the differences between these modes.

When your window is in full screen mode, it will always have the focus, and no other window can come in front of it.

SetFullScreen( ) can return any of the following result codes.

Return values:
SetFullScreen( ) see IsFullScreen( )

SupportsWindowMode( )
Returns true if the specified screen supports w*'dow mode; if you require the ability to directly access the frame buffer of a window (rather than occupying the whole screen), you should call this function to be sure that the graphics hardware in the computer running your application supports it. Because this is a static function, you don't have to construct a BDirectWindow object to call it:

if (BDirectWindow::SupportsWindowMode( )) {
In particular, window mode requires a graphics card with DMA support and a hardware cursor; older video cards may not be capable of supporting window mode.

If window mode isn't supported, but you still select window mode, DirectConnected( ) will never be called (so you'll never be authorized for direct frame buffer access).

Even if window mode isn't supported, you can still use BDirectWindow objects for full-screen direct access to the frame buffer, but it's recommended that you avoid direct video DMA or the use of parallel drawing threads that use both direct frame buffer access and BView calls (because it's likely that such a graphics card won't handle the parallel access and freeze the PCI bus - and that would be bad).


Derived from: public BWindow

Declared in: e/game/windowScreen.h


A BWindowScreen object provides exclusive access to the entire screen, bypassing the Application Server's window system. The object has direct access to the graphics card driver: I can set up the graphics environment A the graphics card, call driverimplemented drawing functions, and directly manipulate the frame buffer.

Screen Access

Like all windows, a BWindowScreen is hidden (off-screen) when it's constructed. By calling Show( ) to put it on-screen and make it the active window, an application takes over the whole screen. While the BWindowScreen is active, the Application Server's graphics operations are suspended. Nothing except what the application draws will be visible to the user - no other windows and no desktop. When the BWindowScreen gives up active status, the Application Server automatically refreshes the screen with its old contents.

Although the BWindowScreen object provides a connection to the screen, you shouldn't draw from the BWindowScreen's thread. Use the thread only to regulate the access of other threads to the frame buffer....

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >