[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.
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.
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.
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.
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:
voidLockGL
(); voidUnlockGL
(); voidSwapBuffers
();
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 BGLView
s 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!
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!
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.
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.
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!
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.
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 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, listed by their subject lines as they appear, verbatim, in the mail.
To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.
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?).
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..."
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).
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).
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):
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.
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).
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:
wu-ftpd from Washington University (wuarchive.wustl.edu)
Apache HTTP server (www.apache.org)
TrollTech, the Qt framework people (www.troll.no/freebies/ftpd.html)