|
Be Newsletter
Issue 16, March 27, 1996
Table of Contents
BE ENGINEERING INSIGHTS:
A Recipe for Smooth Animation
By Robert Polic
There are two ways to do animation on the BeBox: Animate
directly to the screen or animate to an off-screen bitmap
and render the results to the screen.
The "direct-to-screen" approach may seem easier at first,
and may even be acceptable for rastered images, but for
vectored images or images made up of multiple rastered
images, it usually results in flickery animation.
The "off-screen" approach is easy to implement and results
in very smooth animation, since the user only sees new
frames when they're completed -- not the steps required to
draw each new frame. Of course there's no free lunch: The
off-screen approach does involve writing about 10 more lines
of code and there's a memory requirement for each off-screen
bitmap.
The purpose of this article is to show how easy it is to use
the off-screen approach, using example code for creating a
slider that's made up of two parts: A background and a knob.
The example draws the background from scratch each time,
since it's a simple object. The knob is a canned graphic
that we've created elsewhere (see Steve Horowitz's excellent
article in last week's newsletter,
"Be Engineering Insights:
craw, shex, and script: Excuse Me?").
(Of course we could draw the slider directly to the screen,
but every time the knob moved, the user would see the
background redraw over the knob and then see the knob drawn
onto the new background -- not very pretty.)
The first step is to create the on-screen view that we'll
render into in the window that we've already created:
BRect r.Set(SLIDER_L,
SLIDER_T,
SLIDER_L + SLIDER_WIDTH,
SLIDER_T + SLIDER_HEIGHT);
TSliderView slider_view = new TSliderView(r, "slider");
AddChild(slider_view);
Since we're using a canned graphic for the knob, we
might as well create a bitmap for it in the constructor for
TSliderView:
BRect r.Set(0, 0, KNOB_WIDTH, KNOB_HEIGHT);
unsigned char* knob = new BBitmap(r, B_COLOR_8_BIT);
knob->SetBits(slider_bits,
knob->BitsLength(),
0,
B_COLOR_8_BIT);
(If the original graphic is a 24-bit bitmap, replace
B_COLOR_8_BIT with B_RGB_32_BIT.)
The next step is to create the off-screen bitmap that has
the same dimensions as our on-screen view, and an off-screen
view that we'll draw into:
r = Bounds();
unsigned char* offscreen = new BBitmap(r,
B_COLOR_8_BIT,
TRUE);
BView offview = new Bview(r,
"off",
B_FOLLOW_ALL,
B_WILL_DRAW);
offscreen->AddChild(offview);
Note: When you're creating a bitmap that you intend to
attach a view to, the left and top values for the bounds
must be 0.0.
That's it for creating an off-screen drawing environment.
Now we need to draw into it. First we lock the view's parent
to prevent anyone else from accessing it:
offscreen->Lock();
Next, start drawing:
r = offview->Bounds(); // get view's bounds
offview->SetHighColor(R, G, B); // set view's high
color
// same as on screen
offview->FillRect(r); // fill bitmap with color
// draw the slider background...
offview->SetHighColor(0, 0, 0); // set pen to black
offview->StrokeLine(BPoint(x, y), BPoint(x1, y1));
.
.
.
// copy the knob
r.Set(knob_x,
knob_y,
knob_x + KNOB_WIDTH,
knob_y + KNOB_HEIGHT);
offview->DrawBitmap(knob, knob->Bounds(), r);
The last step is to render the result to the screen and
unlock the view's parent:
offview->Sync(); // make sure rendering is done
DrawBitmap(offscreen, BPoint(0, 0));
offscreen->Unlock();
That's all there is to it. Of course, don't forget to
delete the bitmaps that were created in the SliderView's
destructor. Look for the full source example of this slider
on our FTP site: ftp.be.com/pub/Samples/Slider.tar.Z (the
file is also available in .zip and .sea.hqx formats).
BE DEVELOPER PROFILE: Stairways Software Pty. Ltd.
Last week, Peter N. Lewis of Stairways Software Pty. Ltd.
voyaged all the way to the U.S. from Perth, Australia, just
to visit us at Be. Well, OK, so he also came to spend some
time with our friends at Metrowerks in Texas, but we're
pretty sure hitting up Jean-Louis for another BeBox was his
real mission.
Peter N. Lewis may be a familiar name to many of you. A
well-respected, long-time Macintosh developer, he's a
thriving shareware and freeware developer with a long list
of Internet applications to his credit. Among them:
Anarchie, an FTP and Archie client, which you can use to
browse FTP sites and upload and download files, and
NetPresenz (previously called FTPd), which you can use to
turn your system into an FTP, WWW, or Gopher server.
As a communications developer running up against the
proverbial performance walls of traditional PC
architectures, Lewis believes "The BeBox has a lot of
potential for the future. It's a simple, clean system --
something lots of developers would like to get back to. With
its multiprocessor design, it's also Internet-capable and
fast!"
The modern Be OS(TM) is also a big draw with its preemptive
multitasking and memory protection. "I write mostly
Macintosh communication programs, and not having preemptive
multitasking is a real problem." In addition, one of the
most attractive aspects from a technology adoption viewpoint
is that "the framework is built right into the box, so you
don't have to wait for the framework to catch up in order to
take advantage of new capabilities."
As a shareware developer, Lewis admits that the BeBox isn't
a financially viable platform for him yet. Typically, he
finds that only 2 to 20 percent of shareware users take the
time to send in shareware fees (he thinks "about the price
of a paperback book" -- or $10 -- is reasonable). This means
a platform needs a large installed base before a shareware
developer like him begins to see black on the bottom line.
Even so, he believes in the BeBox's potential so much that
he's already written a web server for it. And he's feeling
"a little guilty" that he can't be doing more for the BeBox
right now, as he embarks on a few-months break from his work
in Australia.
"I hope the BeBox picks up enough users so that I can start
to develop seriously for it. It's certainly a lot easier to
program for than the Macintosh, despite using C++," he says.
"And if we get some good languages on the BeBox, then it
will be even more pleasant. I wonder how hard it would be to
build a Java interpreter straight into the OS?"
Why would he recommend other developers consider the BeBox?
"Because it gives you an opportunity to get in on the ground
floor. Because it's much easier than developing for other
machines. Because there's no competition. And because it's
fun!"
"As a Macintosh developer, I've heard all the reasons why I
should develop for the PC, but I'm still writing for the
Macintosh."
And now, the BeBox.
For more information on Stairways Software Pty. Ltd.'s
Internet solutions, visit their web site at:
http://www.share.com/share/peterlewis/.
Forward Motion
By Jean-Louis Gassée
"All right," they say, "your OS offers some advantages,
we'll concede that. But just you wait, the moment The Big
Guys wake up and realize you have some interesting
advantage, they'll unleash their immense technical and
marketing resources. In no time, they'll catch up with you,
meet or beat all your differentiating features. Add their
marketing might and you'll be reduced to a footnote." Thank
you, may we go quietly now?
Fortunately for all of us having one kind of stake or
another in Be's future, it's not quite like that. On the
contrary, even if it appears a little counter intuitive,
we're more likely to increase our technical lead than to see
our noble and worthy elders catch up with us. This, of
course, makes all sorts of assumptions about us staying
focused, vigilant, hungry, and mindful of our station in
life. We have a lot to prove. With this cautious frame of
mind, let's turn to life inside the sausage factories, to
building system software. Call it entropy, call it politics,
but any piece of software inevitably reflects the age, the
mores, the size of the organization that built it. Your
coefficients may vary, but the formula stays the same. And
it will apply to us, eventually. For The Big Guys, large
incremental projects need more and more time between major
releases.
Even the best-run company in the business, Microsoft, needed
about five years between Windows 3.0 and Windows 4.0 (as
your hard disk knows it -- Windows 95 for us humans). Apple
will need a similar amount of time to move from System 7 to
System 8 (a/k/a Copland). For the previous iteration, the
time interval was 2 to 3 years. The same phenomenon applied
to major releases of mini and mainframe operating system
software. After an exuberant youth, software settles down
and the interval between major releases increases. Put
another way, the more mature PC operating systems are
entering a phase of diminishing returns, while we're still
on the early, ascending part of the curve.
Invoking "Skunk Works" might sound both pretentious and
overused. Still, Ben Rich's and Leo Janos' book (now in
paperback at $14.95, unfortunately defaced by a Tom Clancy
quote...) is a wonderful read -- a rich source of
inspiration and analogies. They offer good models when
contemplating what a small, focused organization of
engineering demigods can accomplish: The U-2, the SR-71, the
Stealth fighter no less. They also offer sad models, such as
when the immune system built by the founding father, Kelly
Johnson, and carefully maintained by his successor, Ben
Rich, was finally overwhelmed by the corporate and Pentagon
lymphocytes. Warehouses filled with government paperwork for
a single project.
Lesser mortals such as ourselves can still enjoy the
advantages of a small organization, happily focused on a
product in the early part of its life cycle -- at a time
when we can make bigger and faster strides than our elders.
Our developer software release 1.1d7, shipping next month,
will be a test of this statement.
Still, what about Windows catching up with the Macintosh?
Doesn't this destroy our thesis? Au contraire, Microsoft was
the smaller company in those days, while Apple was the big
rich target. Admittedly, Microsoft enjoyed an unfair
advantage: Stable management, the same leader for 20 years.
This continuity is reflected in the product strategy:
Continuous improvements from QDOS to Windows 95. Apple, on
the other hand, had discontinuous leadership. This wasn't
always bad. Jumping from the Apple II to the Macintosh,
while unpopular with some, started what has become a $12
billion company. But today, Apple is in the uncomfortable
position of playing the continuity game against the best
player in the field.
Meanwhile, having sinned and learned in another life, we're
committed to making the best of our discontinuity, of our
lack of organizational and architectural past and
baggage.
|
