DOUG: What is your background
& what brought you to Macromedia?
DJ: My background. Hmm, back in the late 1970's, when I was
in junior high, I discovered the TRS-80 (affectionately known as the "Trash" 80).
I was an electronics hobbyist, and I used to buy all sorts of parts at the local
Radio Shack store. One day this ugly, grey keyboard with a boxy screen attached
appeared out of nowhere, and I was immediately intrigued. It was running some
sort of shoot-em-up game. I was always an experimenter, and never afraid to try
things just to see what would happen. So I hit the "Break" key a few times, and
it said something like:
Break in 80
Ready
>_
I was sure I had really broken the thing and that I'd be in hot water! Anyway,
that was the beginning of my interest in computers, at age 13 in the Radio Shack
store at the Concord Park-N-Shop mall. After that, I stopped by the Shack every
day after school to play with the thing, and after awhile I was writing demo programs
that the store manager used for showing off the computer's abilities in the store
window. This earned me free electronic parts, which was pretty cool for a kid
with no money. "Here, you want some 7-segment displays? Just take em. You can
have those resistors, too."
I loved writing programs on the thing, so I started getting home from school
later and later each day, until I got in trouble with my Mom. This was also the
beginning of my reclusive life as a teenage hacker.
My electronics hobby got me interested in electronic music systhesis, speaker
building and audio in general, which is where I later started my career. I was
also fascinated by computers and wanted badly to build one. So I built a robot
that was controlled by a Z-80. It was programmable (in hexadecimal!) and had SONAR
that used sound waves to measure the distance to objects in the room so it wouldn't
run into things. Everything was hacked together from different schematics I had
pulled out of hobbyist books and magazines. I didn't really understand how all
the circuits worked, but I was fascinated by all if it! All this playing with
electronics prepared me with enough engineering experience to convince me to do
an engineering degree in college. So that's what I did. I went away to UC Santa
Barbara to study electrical engineering.
At UCSB I emphasized in analog audio curcuitry (rather than the digital curcuitry
of computers). I especially loved feedback control systems, and I was also into
the deep, pounding bass of subwoofer speakers. I really wanted to build a subwoofer
that could use a sensor to detect and correct its own distortion. This got me
my first job after I graduated at M&K Sound in Los Angeles, where I worked on
designing and building home theater subwoofers.
After about a year and a half of that, I got rather bored with speakers. A
long time friend of mine, Troy Lyndon, had a video game startup doing video games
for DOS. That was the end of electrical engineering for me! I longed once again
to be cranking out code on a computer, and audio was just too low tech for me.
So I left M&K to do video games at my friend's startup.
Since I studied electronics in college I didn't really have any formal computer
science training. I was relying on experience from my TRS-80 hacker days, and
learned everything about doing DOS video games from scratch. To this day, I am
self-taught in computers. I never took a single LISP or Compiler class!
My friend's company ended up going bust, and I ended up working directly for
MicroIllusions doing a Jonny Quest game for DOS. Then MicroIllusions went bust,
right as I was finished up the game! I didn't get paid and lost a lot of money,
and was out of a job to boot. So I left Los Angeles to come up to the Bay Area
to work with Sean Barger who was trying to start up Equilibrium, a small company
he ran out of his house boat.
Those were the early days of Equilibrium, and I was employee number one. This
was before the debut of Debabelizer (Equilibrium's current big product), and I
was working on simple Nintendo Game Boy games. I did that for about half a year
until I started getting restless and wanted to work for a bigger company doing
bigger things. Then, a recruiter called me out of the blue and asked me to interview
for this company called Macromind.
"Macromind... What do they do?," I asked the recruiter.
"They do multimedia. It's computer graphics and animation. They have a product
called Director".
"Director. Hmm, never heard of it."
"They're a startup. They have about 45 employees and are growing very quickly."
"45 employees? That sounds like a big company to me! I'll check it out."
So that's what I did. I interviewed at Macromedia and fell in love with the
company immediately. There were so many hip people and fascinating characters
here. I was interviewed by a blonde Englishman with a neon green T-shirt and an
earring (that was Joe Dunn). And everybody I met was so smart! I knew this was
a place I could grow and learn, so I accepted their offer and came here to work.
About 9 months after I started, Macromind was renamed to Macromedia after the
merger with Authorware. The company grew like crazy after that.
DOUG: How long have you been with Macromedia
& in what roles?
DJ: I've been at Macromedia since February of 1991, so that
makes it just a bit over seven years.
I started off working with Greg Yachuk on the "Windows Player." We were told
something like, "Here's this Windows Player code. It's almost finished. I know
all the engineers that were working on it just quit, but you can be sure the code
really is about 90% done. All you have to do is fix a few bugs and then you can
move on to something else."
In hindsight, that was pretty funny. I've worked on players ever since! The
1.0 version of Windows Player was so buggy that it was barely useable. The early
versions of Windows Player were a disaster. Virtually no customers were happy
with it. And everyone thought it was just because Windows Sucks.
Well, actually, that was in the days of Windows 3.0 with "Multimedia Extensions"
which, well, pretty much did suck. But I believed that multimedia could be made
to work well on Windows. Windows was slow, but I knew it could do Director. Nobody
believed me, and I was driven to prove this.
Eventually, the company wanted to give up on Windows Player because it just
wasn't working out. But somebody had signed a deal to do a SGI version for the
new Indigo computer, so I was put on a project porting it to the Silicon Graphics
workstation.
SGI brought this whiz kid, Mike Gold over to Macromedia. That guy cranked!
In just a few weeks, he wrote this portability layer that let all the windows
code of Windows Player run directly on SGI, with no code changes. It just translated
all the Windows calls to SGI calls. We never even had to touch the Windows Player.
That left me with with basically nothing to do for the SGI player deliverable.
So with all this time on my hands, I just fixed Windows Player bugs. Tons of them!
Director's product manager at the time was a cool guy named Jeff Parker. He
also believed in my mission to prove that Windows could do high quality multimedia.
So on the side, he ran a skunkworks beta program to feed me bugs to fix. Sasha
Magee was the tech support specialist for Windows Player (that was a hard job!),
and he gave me many good bugs. We had also hired a contract QA guy named Clay
Ashby, a really laid back character from Hawaii. In his spare time, he did a title
for the Hawaii Tourist Board that was a guide to Oahu attractions done in Director.
He used my builds of Windows Player to port it to Windows, and was another invaluable
source of real world bugs to fix.
Between the four of us, we found most of the really bad bugs and whipped this
skunkworks version of Windows Player into shape. The result was supposed to be
just an SGI deliverable, but soon it became apparent to Macromedia management
that the Windows version was running well enough to re-release. Just before Windows
Player was about to be killed off, it was decided to release the newest version,
Windows Player 1.2 with all the bug fixes.
After that, Windows Player was actually kind of successful because now it
was possible to make shippable titles with it. Of course, it still had a few serious
limitations, but with enough patience, it really was usable. So Macromedia decided
to invest in Windows multimedia. I was asked to do DPW 3.0, the final version
of the Windows Player. This version was very successful and made Macromedia a
lot of money. Many titles shipped on Windows using it. Windows was also taking
off as a platform, and it became clear that it was time to do a Windows Version
of Director.
Unfortunately for me, it was decided to create Director for Windows by porting
the Mac Director codebase to Windows rather than building an authoring environment
on top of the DPW player codebase. So it looked like the end of DPW for me.
Then Norm Meyrowitz was hired at Macromedia as a Technology Czar to help come
up with strategies for making the most out of the many diverse technologies at
Macromedia. Seeing the value of the DPW technology, Norm (together with Tom Buttermore
and Travis Huch) put together a deal to license the player to 3DO. This gave us
the money needed to pay for porting the DPW code to the 3DO game machine.
Porting it directly to 3DO would have been really hard, since the code was
Windows code and 3DO and Windows have almost nothing in common. So we decided
to port the Windows Player to a "generic platform" that we could later implement
for any platform we wanted. Young Harvill and I designed this "generic platform"
API, which was later called the "IML" or "Idealized Machine Layer:" We called
the player the "Portable Player". The IML is still used to this day.
The result of the 3DO player was a player that was ported to run using the
IML, and a Windows implementation of the IML and a 3DO implementation of the IML.
The strategy looked pretty good to Macromedia management. All you had to do was
port the IML and you'd get Director playback on that platform! It was an easy
sell. So Macromedia did player deals like crazy. Soon we were doing an IML for
Windows, 3DO, SGI (another port!), OS9, OS2, and a couple more obscure game boxes
not widely heard of.
The results were pretty good, and soon Director movies were popping up all
over the place. So Norm let us do a Mac version of the IML (which Dave Good had
started as a skunkworks project anyway). That was the beginning of Chopper, and
later, Roswell, the IML-based shockwave plugin players.
So for my whole seven years here, I've worked on nothing but Director playback
outside of the main Director codebase. That's why it's funny to remember back
in March of 1991 when I was told that the Windows Player was "90% done." I'm still
working on it to this day!
DOUG: As an old-timer, how has your
experience been watching the evolution of Director and Shockwave? Observations?
DJ: It's interesting you say "watching". Working on a separate
codebase for playback, I really did "watch" Director's growth and changes. Early
on, it was hard for me to have much influence on Director, since I wasn't working
on the main, shipping codebase. There were changes that went into Director that
I had a hard time accepting because they meant really difficult work in the portable
player. I felt that if I could have had some say in how the feature was architected,
it could have been easier for both teams in the long run. But the portable player
had always been a skunkworks project, and its needs were not taken very seriously
by the Director team. And with good reason -- the 'A' team, as they were called,
had to ship a revenue producing product (Director) and the portable player team's
needs had secondary priority.
So we played a couple of years of catch up. While the player team was still
getting the previous version of Director files to play on the portable player,
the Director team was already well into writing the next version. So we were getting
Director features "handed over the wall" to us, and were not really working on
doing any innovations of our own for Director. We were just reimplementing everyone
else's features. That was kind of unsatisfying.
The development of Shockwave was one of the most exciting times ever at Macromedia.
We really felt like we were changing the world! Making Director work with the
web was the coolest transformation Director had ever seen, and we were at the
heart of it. Even though I was kind of on the outside working on the player, the
energy here was so high here you couldn't believe it.
Playing catch-up-to-Director in the player code wasn't generally the most
fun thing, but adding the web features to the portable player was a blast. It
was the coolest thing to be developing a player that could be ported to any web
browser on any platform! And this marked a key transition for the portable player
technology. Because of its lightweight architecture, it was the first time a Windows
or Mac browser could play Director movies without the lengthy plugin load times
of the shipping Director plugins. With that, the portable player had come of age
and it was clear that Director itself needed to be using this new playback technology.
DOUG: Tell us what you're responsible
for & what you do day-to-day?
DJ: Hmm, that's a hard question because I don't have a simple
role. I am the architect of the portable player, which means that I am responsible
for the technical designs of playback-related features. I ensure that work done
on the player is done as effectively as possible and that code quality is kept
high. I also help to design features so that they can be done as easily as possible
while still giving us the biggest "bang for the buck." I try to ensure that playback
features are designed as robustly as possible without costing too much time to
implement.
Day to day, I try to code as much as possible, as that is where my passion
lies: in coding. However, I am often involved in design and policy meetings of
various sorts. I probably spend a bit more time in meetings than most engineers
at Macromedia. But I'm not a manager. Nobody reports directly to me.
DOUG: We've heard the word "codebase".
Can you tell us what that really means in relation to Director and Shockwave?
What will a new codebase mean for Director's future?
DJ: Right now, Director 6 and the projector skeleton are
built from the old codebase. The browser plugins are built from another (the portable
player). The two codebases are almost entirely different code, though they behave
pretty much the same.
With Director 7, we'll be using the new player codebase everywhere: in Director
itself, for the projector skeleton, and for all browser plugins and controls.
I believe this will give our users the best possible performance on all platforms.
DOUG: Can we expect that a new codebase
will lead to more consistent performance and functionality across platforms, runmode
(authoring, projector, shockwave) and the various browsers?
DJ: Yes, definitely! The new codebase has the advantage that
it does not use "ifdef's" to carve different builds (potentially with different
bugs!) out of one big hunk of amorphous code. Instead, every kind of player (whether
it's a projector, or a plugin or Director itself) will use the exact same DLLs
or code libraries.
I believe this will make it easier for Macromedia to find and fix bugs, because
the same bugs should show up everywhere, rather than lurking in just one of the
builds. It should help prevent one of the things I think our users hate the most:
"My movie plays fine in Director, but hangs when I run itas a projector" or "It's
slow when I run it as a projector, but fast when I view it using the plugin under
Netscape 4.01."
DOUG: What will the new codebase mean
to your engineers with regard to fixing legacy problems and creating new features?
DJ: Well, for one, a whole slew of old bugs will be instantly
wiped out, because the whole legacy player in Director is being replaced with
a completely new player. The bugs are in code that is just going to go away, period.
And now that we are no longer running two teams (on working on the main Director
release and the other "imitating" features in the portable player), it means we
have the whole team focused on once codebase. I believe that with such a focused
team, we should be able to concentrate more energy on quality.
I have always believed that Director is a high quality product. But with more
engineers concentrating on a single, better architected codebase, I believe we
can achieve even higher quality for Director 7. Not having to develop a player
on the side should also mean we'll have more manpower (and womanpower) available
to write new features. It's now one big team cranking on Director 7 instead of
two small teams.
DOUG: Tell us what it's like to see
Director used for all the various applications. What's it like to see what people
have done with the product?
DJ: It's totally incredible. About every year, I see something
done with Director that I never even imagined. "Oh, they're using film loops like
that?" When I see titles that push Director in ways that we, the engineers, never
expected, it's really inspiring. Sometimes I'm so taken by what I see in titles
and on web sites that I optimize Director a bit so that that kind of title will
run especially well. Other times, interesting uses of a Director feature that
wasn't intended to be used that way inspires a new feature that will really excel
for that kind of use.
I really do have to say that I think it's the content that I see done in Director
that is the "icing on the cake" of my career here at Macromedia. I always joke
about how I couldn't imaging working for a company that does tax software. Instead
of saying, "Hooray, all those numbers in that column added up correctly!" I get
to say, "Check it out, that's Rodney's Funscreen playing on a 3DO!" and "Look,
it's From Alice to Ocean on a PC!"
DOUG: We understand you worked with
Zav on quite a few projects while he was at Macromedia. Are you still suffering
flashbacks?
DJ: Yeah, especially when I come up across one of his hardcore
test files... one of the ones that pushes Director so hard it's amazing the code
doesn't just roll over on the spot and smoke the machine. His files always had
a lot of character, with cool, innovative UI design and graphics that you can
only describe as Zavesque. When I'm running one of these files to stress test
something, that's when I have Zav flashbacks.
Oh, and also every time I eat smoked salmon.
DOUG: We won't ask!
|
