|
Be Newsletter
Issue 56, January 15, 1997
Table of Contents
BE ENGINEERING INSIGHTS: OpenGL® Rides a Bike
By George Hoffman
[As a fan of William Adams' smooth, subtle segues into each
week's News From the Front, I tried to come up with a
similarly suave lead-in to this article about OpenGL®. I
think I've gotten fairly close...]
My kid threw up the other day. Speaking of which...
Be's licensing of OpenGL® from SGI will bear first fruit in
DR9, with the inclusion of a software implementation of the
GL API and several support libraries, including the GLU,
GLUT, and AUX packages. In this article, I'll give a quick
introduction to GL, outline GL's integration with the Be
environment, and expose some limitations of the
implementation.
The GL API was designed by SGI as a standard software
interface to high-end geometry and rendering graphics
hardware. Read that sentence again, and shout out the words
"high-end" and "hardware." Now think about these
implications:
- Since it talks to hardware, the GL API is pretty low-level
C.
- All drawing is done in "immediate mode" -- GL has no
concept of a "frame."
- GL isn't a lingua franca for ALL 3D applications, or for
ALL hardware. There are many situations in which GL is less
efficient than a "lighter" solution (such as Be's 3D Kit).
Let's look a these points in a bit more detail.
THE GL "CONTEXT"
Unlike the 3D Kit or QuickDraw3D, GL has no concept of an
object or world model. Instead, GL defines "contexts." Each
context holds the state for a camera position, lighting,
drawing material, viewport dimensions, and matrix
transformations. Actual drawing is done by a set of eight
line- and polygon-drawing primitives. To transform (scale,
move, rotate, and so on) a drawing, you apply your
transformation to the context's "transformation matrix,"
before invoking the drawing primitives.
IMMEDIATE MODE DRAWING
All drawing operations are rendered immediately; GL doesn't
slice time into frames. You can, however, simulate frames by
double buffering: You draw into an offscreen buffer and then
make a platform-dependent call to GL's "glue" layer to
display the buffer. (In the BeOS, the glue call is part of a
C++ class.) It's easy to imagine a framework built around GL
that would hide these details (GLU provides some
capabilities along these lines), but the OpenGL® API itself
makes no attempt to do this.
GL IS THE ANSWER TO HIGH-END PROBLEMS
Because GL was designed as a universal interface to high-end
graphics hardware, it's not ideal for all 3D applications,
or even for all graphics hardware. Again, the key words here
are "hardware" and "high-end." On low-end hardware (or
without special graphics hardware), even a very efficient
implementation of GL will perform poorly when compared to a
lightweight package like QuickDraw3D or the 3D Kit.
For example, many of GL's drawing primitives know how to
take advantage of vertices that are held in common by
adjacent triangles and polygons, but the adjacency must be
"serial:" GL can't reduce an entire array (or "mesh") of
polygons to its unique vertices, it can only optimize
"strips" of polygons within the mesh. This isn't a big deal
when you're talking to hardware that boasts planet-eating
geometry pipelines that can gobble transformations faster
than they can be pushed down the bus, but it's hideously
inefficient for any implementation in which the geometry is
done in software, which includes almost all of the low-end
to mid-range market.
There are other factors that impact the performance of a
software implementation:
- Because GL provides such a large feature set, it's time-
consuming to optimize for all cases, and difficult to
optimize for particular cases without adding a lot of
special-case bloat to the libraries.
- Because GL uses an immediate-mode rendering model, some of
the more obvious multiprocessing optimizations are
impossible.
So OpenGL® isn't for everyone. If you're thinking about
writing games or lightweight 3D controls with OpenGL®, don't.
These are exactly the types of applications the 3D Kit is
designed to facilitate. On the other hand, you can do things
in GL with a couple dozen lines of code that are impossible
with something as structured as the 3D Kit. And OpenGL® is
unquestionably the most widely implemented standard for
real-time 3D. There are obviously cases when this much
flexibility and compatibility are crucial, and these should
be the cases where OpenGL® is used.
OK, ENOUGH BACKGROUND...
Let's meet the BGLView and BGLScreen classes. These two
classes encapsulate the interfaces for creating and managing
a GL context in a window and on the Game Kit's full screen
(BGLView inherits from BView and BGLScreen from
BWindowScreen). GL options -- depth buffer, alpha buffer,
double buffering, and so on -- are specified in the class
constructors. Aside from overloading several methods of
their ancestors, each class adds the same three methods to
its base class, and the usage is the same:
void LockGL();
void UnlockGL();
void SwapBuffers();
LockGL() and UnlockGL() must be wrapped around any calls
into the GL C API. LockGL() ensures that the context
associated with that class is the current GL context and
obtains the global GL drawing lock. UnlockGL() releases that
lock. In BGLScreen, these methods also ensure that the Game
Kit's connection to the screen is maintained throughout the
lock. The global GL lock is required because although a
software implementation may not mind having two contexts
rendering at once, a hardware implementation will not allow
this, and these calls allow the locking to be done at
whatever granularity the programmer desires.
SwapBuffers() simply swaps the front and back buffers of a
double-buffered window, revealing the frame most recently
drawn. This should be called after each frame of animation
has completed rendering.
The software implementation presented with DR9 is little
more than a placeholder; it's not highly optimized and
doesn't support many of the newer GL extensions. To power a
real GL program, a more optimized and hardware-accelerated
implementation can be dropped in (a ripe third-party
opportunity, hint, hint). However, this implementation
should be enough to allow developers to start developing and
porting GL programs. We've tried to optimize our
implementation for the common case, concentrating on Z-
buffered and non-Z-buffered goraud-shaded polygons with
minimal alpha blending or other special-effect optimization.
There are some limitations to the implementation's
capabilities:
- Most notably, single-buffered BGLViews are currently not
supported. Technically, this feature isn't supported because
the API is implemented in a shared library rather than in an
Application Server add-on (you need the latter to draw
directly to the screen). Furthermore, single-buffered
drawing in a window isn't seen as something that many people
will want to do -- if you disagree, please let us know.
- Another limitation is that only 32-bit rendering is
supported. Output to 8-bit screens is supported by using the
Application Server's built-in conversion and (forthcoming)
dithering facilities.
Of course, we'll continue to refine the Be GL
implementation. Personally, I'm heading back to school to
cram more cotton into my wee noggin (I've been an intern at
Be these last seven months), but I'll be in touch.
I hope this has helped you decide whether OpenGL® is right
for your Be 3D project. Now go forth and matrix multiply,
and happy coding!
BE DEVELOPER TALK: Keep Dreamin'
By Marc Verstaen, Lorienne Inc. [Now BeatWare, Inc.]
E-mail: verstaen@best.com
I was surprised by the overwhelming response to the BeOS at
last week's Macworld Expo in San Francisco. But the reaction
was, really, business as usual: Last January (1996), I was
astonished by the crowd trying to get a peek at the BeBoxes;
at the August Macworld in Boston, I was amazed by the number
of visitors staring at the BeOS running on a Power Computing
box. This time, I expected the reaction to be less
explosive. After all, Apple was set to describe its most
important OS transformation in over a decade, and, anyway,
isn't Macworld dedicated to Apple computers and software?
But I was wrong, the size of the crowd at the Be booth was
even more impressive than at Boston! The enthusiasm was
still there, and the demos were faster and better than ever!
This Macworld was also the last opportunity for us at
Lorienne [Now BeatWare] to show our software before releasing it. The
Reggae Suite will ship with DR9: It includes a word
processor, a draw program, and a paint program. We continue
to work on a spreadsheet -- it should be ready soon. I would
like to take this opportunity to thank those of you who were
at Macworld for your support and warm reaction: Your regard
is, for us, the best award.
As Alex said in a previous newsletter, one of the most
powerful agents for software development is adrenaline.
Indeed. But I would add dreams: We all need to dream to
dynamize our software.
I began to dream almost ten years ago. I was living in
Paris, and Sun Microsystems invited me (and about three
hundred other developers) to a presentation of their new
system, OpenLook. Compared with what we have sitting on our
desks today, OpenLook was less than impressive, but it did
offer a tool to interactively create applications, a kind of
file browser, some graphic stuff, and the power of a UNIX
workstation. Nothing funny at all. But what was unusual was
that the presentation was made by the engineers who
developed this stuff. For the first time, I had the
opportunity to discuss the software I was using with those
who were creating it! Ten of us spent half of the night with
them recreating the world.
Last Saturday, those of us who had the opportunity to be in
San Francisco spent the day discussing the features of the
BeOS with the Be team. You could think that for me it was
simply another day of demos and discussion, but it wasn't:
The dream isn't over, and I'm as excited now as I was last
year and ten years ago.
Thank you all at Be, for spending this time with us. See you
next time!
News from the Front
By William Adams
So the new year begins with a bang! We just traversed the
Macworld gauntlet, and boy was that fun. We were in quite a
few places showing the BeOS to the best of our abilities. If
you visited the show at all, and went by the Power Computing
distortion field, you received quite a good dose of the BeOS
and Power's commandos.
Our booth was always packed. We were running a continuous
stream of demos on two large screens at the front of our
booth. It was so packed that the audience spilled over to
the Orange Micro booth, which they were none too happy about.
They even erected an eight-foot-high curtain to keep people
out of their booth, and show management threatened to cut
off our power.
There were a number of third-party applications in our booth
demonstrating quite nicely, much to the appreciation of the
attending crowds. And we were helped in no small measure by
the reality of FredLab's VirtualMac product. I've seen any
number of times where a new platform is confronted with the
"There's no software" mantra. I think we had this licked,
with the exception of "Where's Photoshop?"
The developer's conference the Saturday after the show was
well attended, and we learned a few things about how we will
do things differently in the future. For all developers who
sent in applications to be demonstrated, we're deeply
grateful. You have helped to solidify our place as a new,
exciting, and worthwhile development platform. We'll try to
continue to do right by you in the future.
NEW FACES
There are new faces in DTS. Almost from the day I joined Be
a few months ago, I've been conducting a steady stream of
interviews to create a Developer Support staff that will
continue to offer excellence in service and keep people
coding happily. The fruits of this labor are three new
Technical Evangelists/Support Engineers.
Lauren Boyd -- A Mac programmer with much experience, a big
dog, and a fish tank on her desk.
Geoff Woodcock -- A refugee from Xylinx who wants to do
support right. He claims that noone can beat his orange,
pear, apple, or grapefruit trees. We'll see.
Hiroshi Lockheimer -- Of screen saver and styled text fame.
Hiroshi lived in Japan all his life, speaks Japanese, and
will be doing Japanese evangelizing. Of course this means
styled text must become a part of the system along with the
screen saver.
Our first task is to get a grip on all the different forms
of communications that our developers use to get questions
into us and have them answered. We'll encourage you to use
standard forms on our Web page, but we'll also go trawling in comp.sys.be. Our goal
is to build a knowledge base that will make technical
support easier, and possibly enjoyable. We'll announce more
of these plans in the near future as they unfold.
SPUTTERING TO A START
We have a big year ahead of us, and a lot of work. This is
the phase when a lot of startups choke on their preliminary
successes and never quite recover. Our goals are to leave
the choking to others and to excel through attention to our
developers' and end users' needs. To this extent, if you
have any suggestions for how we can make your interaction
with our organization easier, please send them to me at
wadams@be.com.
This year we'll have more and more interesting things
happening in order to spur development of those tractor
apps. I've even devised a nice offensive little trophy to
give our internal developers for their efforts as well. So
this year is going to be a lot of fun and probably lucrative
for many developers. Stay tuned, and keep coding!
BE MARKETING MUTTERINGS: Deja Vu All Over Again
By Alex Osadzinski
The human mind is complex, intriguing, and often surprising.
Most intriguing of all is how memory works: How a sound, a
smell, or a combination of sensory inputs can trigger a
chain of memories is not well understood. This past week,
I've been remembering events from over 25 years ago and have
been analyzing the triggers.
By now, you've probably read and heard a lot about Macworld
in San Francisco, so I won't dwell too long on the details.
My main impression of the show was how fast the days flew
by. From the moment the show opened each day to the closing
announcement, it seemed like everyone on the Be team was
running on adrenaline (or caffeine, or both) and that time
was suffering some strange relativistic compression. Our
booth was packed throughout most of the show and it was
great to meet and talk with so many Be enthusiasts. This is
also the _only_ company I've ever worked at where product
demonstrators had to be almost dragged away from their demo
stations at the ends of their shifts instead of escaping
from the booth as quickly as possible. We were all getting a
tremendous rush from the reactions of people to the BeOS
demos. Those of you who attended the show and saw the big
screen demo at the Power Computing booth will have seen Mark
Gonzales of Be and Mike Rosenfelt of Power Computing
continuing their hourly demos even long after both had
almost completely lost their voices; they were both working
very (too) hard, but I think they were also having the times
of their lives.
But, exciting and enjoyable as the show was, our Developer
Conference, held on Saturday at a San Francisco hotel, was
the pivotal event of the week for me. Standing at the back
of the room watching demos of BeOS applications, I was
remembering events that profoundly affected me in 1971.
In 1971, I was in England at the UK equivalent of high
school. Our school had an arrangement with a London-based
timesharing company to have free off-peak access: Two 110-
baud dial-up lines driving 10cps teletypes connected to a
Xerox Sigma 5 computer. The environment was simple,
character-based timesharing and the ability to develop and
run BASIC, FORTRAN, and assembler programs. With 1,100
students at the school and few on-line hours, access was
limited to 6th form (equivalent to the first year of US
college) math and science students. As I was a mere 2nd form
puke, computer access was a far distant possibility. But,
after a demo at an open day, I was hooked. I took the big
red London bus to Xerox Intergalactic HQ in the far reaches
of the city, begged a set of manuals, devoured them on the
long ride home, and wrote my first program (a pitiful
effort, to be sure, but a start). After pleading with my
math teacher to have the opportunity to run it, I was
finally admitted to the holy inner sanctum where the
teletypes were kept, allowed to watch the incantations
required to establish a 110-baud connection, noted how
laughably easy the password was to guess (which much later
led to nefarious activities we won't go into here), and
then, gasp, laid hands on keyboard to type in my miserable
little program. Amazingly, it worked and prime numbers (yes,
you guessed it) started to churn out of the machine.
At that moment, I had a rare flash of insight (they happen
about once a decade) and realized that _here_ was something
wonderful, powerful, exciting and, most of all, _fun_.
On January 11, 1997, I had the same feeling, and it reminded
me very powerfully of that first computing experience 26
years earlier. OK, I'm biased, but this past Saturday, with
over 400 Be developers in one room, showing off some
tremendous applications, I felt strongly that we were on the
right track. Sure, we have a long way to go. We have to
continue to improve the product, to populate hardware
platforms, and do everything we can to help developers ship
real-life applications. But based on what I saw and heard on
Saturday, I haven't been this excited in many, many years.
In my next column, I'll go into some detail about our sales,
marketing, and support plans for 1997.
An Interesting Week
By Jean-Louis Gassée
Macworld is never boring, but this one was even more
interesting than usual. Apple's announcement of its
acquisition of NeXT and of the return of one of its
founders, Steve Jobs, provided a great deal of exciting news
and created a context for whatever we had to say.
For us, this was the opportunity to state our case with
facts. We were fortunate to have a slightly larger booth
(20' by 20') than last year. Still, it was packed all day
long. Demonstrations ranged from the serious to the cheeky.
The prize for cheekiness, surprisingly, goes to one of my
fellow countrymen, Marc Verstaen. Marc's company, Lorienne [Now BeatWare],
developed several products for the BeOS. Among them, a word
processor, Reggae, and AppSketcher, an application-building
toolkit with ties to CodeWarrior, Metrowerks' native
development environment for the BeOS.
Strangely enough, Marc thought of using AppSketcher to
reproduce the patented Steve Jobs Interface Builder demo:
Building a window with a slider and a dialog displaying the
numeric value controlled by the slider. Marc used to be a
NeXT developer, he couldn't help himself. The connoisseurs
in the crowd chuckled. For a broader audience, we showed how
the BeOS could project the real-time input of two video
cameras on two faces of a rotating cube while the other four
displayed QuickTime movies -- and still have power left for
other activities.
Thus making two points. First, with fresh, modern,
lightweight system software one can realize more fully the
potential of the PowerPC architecture. Second, this is the
system for creative multimedia applications. The
enthusiastic reactions in the audience lead us to believe
both points came across quite clearly.
Speaking of the potential contained in the PowerPC
architecture, one company did the most to promote it: Power
Computing. They had the most animated booth, with a huge
video wall for demonstrations and much martial paraphernalia
to promote the idea they were fighting, and winning. This
included a convoy of Hummers circling the Moscone trade show
building, shouting slogans from roof-mounted bullhorns, and
posters reminiscent of the more subversive days of the Red
Army.
Spectacular and effective at a time when the gloom of
financial losses and uncertain strategic pronouncements
could otherwise lower the mood in the Mac community. In
keeping with our partnership with Power Computing, we
demonstrated the BeOS on their podium. FredLabs' VirtualMac
got great reviews from a crowd agitated by Mike Rosenfelt,
Power Computing's marketing wizard, who never failed to
point out that if you can run Word 6, you can run anything.
On second thought, I was perhaps wrong when I gave the prize
for cheek to Marc Verstaen.
After such a week we can't help but feel excited and
humbled. Excited by the possibilities ahead of us, a fast
growing digital media market and a system well received in
it. Humbled by the work and the risks ahead of us,
delivering the next revisions of our OS, developing
partnerships with PowerPC hardware builders, facilitating
the development of exciting applications, and generally
keeping ourselves focused and organized.
More about that in the coming weeks, starting with our
developers conference at the end of last week.
BeDevTalk Summary
BeDevTalk is an unmoderated discussion group that's a forum
for the exchange of technical information, suggestions,
questions, mythology, and suspicions. In this column, we
summarize some of the active threads, listed by their
subject lines as they appear, verbatim, in the group.
To subscribe to BeDevTalk, visit the mailing list page on
our Web site: http://www.be.com/aboutbe/mailinglists.html.
- -----WEEK 2---------------------------
Subject: Remote Displays
AKA: games
The original topic (remote, networked monitors) was usurped
by action game talk.
A listener wrote in to propose a port of Avara -- but how
should the multiresource "mission" file format (used by the
game) be emulated in Beland?
"Use the BResourceFile," said the caterpillar. But there may
be a compatibility problem when trying to preserve existing
mission files, which problem could be solved by a StuffIt-
like program (any takers?).
- -----NEW---------------------------
Subject: Programming Language Integration
AKA: Metrowerks to do Objective-C
Will Be support more programming languages in the future?
How will different languages gain access to common resources
(servers and drivers, specifically)? It was pointed out (for
what it's worth) that a discussion of languages "always
seems to turn to the language bindings and then on to (the
lack of) SOM, CORBA etc, doing-it-the-right-way..."
- -----NEW---------------------------
Subject: Apple emulation on BeBox exists!
AKA: virtual mac?
AKA: Emulation
This thread, started before FredLabs' VirtualMac was shown
at Macworld, speculated on the nature of the announced Mac
emulator, the legality of the emulation (is V-Mac a "hostile
port"?), the expected performance of the emulator (with a
reference to the Amiga Mac emulator that ran faster than the
original), and the possibility of creating an "app munger"
that could convert a PEF-based Mac app into a BeOS app
(according to Jon Watte, it's certainly possible -- but not
trivial).
- -----NEW---------------------------
Subject: Universal Font Selector
Proposed: A font selector application that lets you drag-n-
drop a selected font (with size/shear/etc.) into a target
app. Perhaps, as counter-proposed, a Be-blessed Font Panel
would be better -- some folks think an entire, separate
application is too heavy for font selection. Marc Verstaen
wrote in to announce a Lorienne [Now BeatWare] FontPanel (available soon).
- -----NEW---------------------------
Subject: Why no file commands for ioctl()
All of the BSD file commands for ioctl() are missing. As a
number of correspondants pointed out, that's because Be is
sort of POSIX, not sort of BSD. Among other differences, Be
sockets don't map to file descriptors, so many of the BSD fd
ioctl commands, indeed, can't work (and aren't implemented).
So (asks the original listener):
Q. How do you detect if the remote end of a socket is gone?
A. Look for ECONNRESET as the errno of a -1 returning
send().
- -----NEW---------------------------
Subject: random shape windows
Currently you can't create nonrectangular windows -- will
such a feature ever be provided? What will you (the
developer) have to do to define a window?
Not a lot of controversy here yet, but we can hear the
hubbub of "preferences" in the background.
THE BE LINE: We will provide some amount of window
*customization* (settable window tab sizes, colors,
orientation, more window def types, and so forth) soon.
Recognition of utter definitions will be provided in the
year 2003 according to Benoit Schillings. But he was looking
at the Belgian calendar at the time, so we're not sure what
he meant.
- -----NEW---------------------------
Subject: C++ question
The CS101 question of the week: Is it possible to inline
virtual functions?
Various opinions about the utility/sensibility/aesthetics of
this combination (that is, inline AND virtual), but the
bottom line is: Sure, a function can be declared inline
virtual. However, in order to take advantage of the inline
suggestion, the compiler will probably have to do some flow
analysis to see if the class(es) of the calling object(s)
can be determined. If the class is indeterminate (that is,
it might be one of a number of subclasses that have separate
vfunc implementations), then you have to visit the vtable
(and, thus, the inline suggestion is for naught).
- -----NEW---------------------------
Subject: Converting many files to type TEXT
Q. How do you change the file type of a group of files?
A lot of folks wrote in to recommend ChangeType (look in
http://www.be.com/beware/Utilities.html) and ChooseType
(http://www.be.com/beware/Add-Ons.html). For command line
fans, get the settype program from
http://www.wolfram.com/~cwikla/be/.
Jon Watte also suggested these methods when using the BeIDE:
- Drop your source files on the BeIDE icon (not in the
project view).
- Change the "Target" preferences panel to not require TEXT
type for .c, .cpp, .h files and just go by extension.
- -----NEW---------------------------
Subject: ftpd
What's the best ftp server code to port? As always, the rfc
is a good starting point: RFC959
(ds.internic.net/rfc/rfc959.txt)
959 is the ftp spec; also look at 854 (telnet), 793 (TCP),
and 1579 (firewall).
For server examples and code, there were some suggestions
and objections, among which:
|
