My So-Called Life with Director

September 13, 1999
by Alan Levine

Despite the rumors, Clair Danes will not play my part in this column.

The editors at DOUG have been breathing down my back for a new randomAlan() column. They say my columns are widely read, which mystifies me, since many of the other columns I see at DOUG are at levels of Lingo I've never touched.

This version began with some reflection from the May UCON99 and then fizzled from there. Despite what many think, running a web site about Director does not mean I am an expert. My Lingo skills likely peaked at Director 5. If I was that good I would write a book or a bunch of messages on Direct-L. Or write code from my yacht (Editor's Note: We can vouch for this. We never write code while we're on the DOUG yacht.).

So where is this column going? Not to sure from where I sit now. Have no fear, there may be code. So let's start the smorgasbord. I dub the theme here as "puny bits of lingo with interspersed opinionated gack".

Bust My Clock

Two randoms ago I provided code for creating an on screen clock, that recorded how long someone had spent inside your progam time, using a parent script that launched an object into the actorList. The actorList is a pretty obscure feature now in Director, as many of its functions can be more clearly written into frame behaviors. Speak with reverence for the actorList, for if you can code with it, others will think you can code anything.

My clock thingy was of Director 5 vintage, and with fiddling in Director 7, I found an annoying side effect of my clock-- it seemed to cause Director to ignore any puppettransition commands. Why care? On many projects I use a dissolve transition on the Mac, which looks like crap on a PC. So I often use a platform dependent transition:

on mouseUp
  sceneTransfer
  go to frame "blah"
end
on sceneTransfer
  if the machineType = 256 then
    -- transitions for windows  Do it as boxy dissolves
    puppetTransition 26, 4, 8, TRUE
  else  
    -- dissolve transitions for Mac are smooth!
    puppetTransition 51, 4, 8, TRUE
  end if
  
end

Okay, so something funky was going on in my clock object to chew up transitions. I never was able to isolate the cause (and did report it to the mothership), so the next best thing when you are in a code corner is to write it a different way. It was a snap to write a sprite behavior to do this.

global gStartTime
on exitframe me
  put sessionLength() into field "clock" 
end exitframe
on sessionLength me
  -- determine the length of time user has 
  -- been in the program
  -- and return formatted output
  
  seconds = (the ticks - gStartTime) / 60
  hours = seconds / 3600
  minutes = (seconds mod 3660) / 60
  seconds = (seconds mod 3660) mod 60
  return "[" & pad(hours) & ":" & ¬
    pad(minutes)  & ":" & pad(seconds) & "]"
  
end sessionLength
on pad x
  -- insert "0" chars for single digit values of x
  if x < 10 then
    return "0" & x
  else
    return x
  end if
  
end pad

A sample movie is available for download in Mac or PC format

Now you will notice that my example code has some pieces hardwired into it. It relies on a start up handler that places the value of the ticks into the global gStartTime. Lingo purists may spit on you if you use globals. So what? I also have the behavior explicitly writing to a specific cast member a field named "clock". If I was writing super general behaviors for the world to use, I had have it grab the member name when the behavior is dropped into a sprite and refer to it as a property, do a bunch of error checking (just in case I dropped it on a bitmap), and boom! I would have one of those 300 line behaviors like the ones in the Lingo Library palette.

But I hate having those huge generic behaviors! Have you ever turned on the tracelog in the message window? All of that generality in a re-usable Behavior has a huge overhead, so often I will write leaner Behaviors which just may not be as generic as others would write.

My moral is that coding is a style, and you've got to find your own style.

The Remote Rollercoaster

It is hard not to have an opinion about the Shockwave Remote, which made a quick appearance late in the Director 7.02 cycle. Direct-L and Shocker-L pounded Macromedia with loud complaints about its features, its forced default nature, and for many folks, the seemingly juvenile tie of Director-authoring to "toons & games". The implementation busted several major Mac environment attributes.

If this wave of complaints were hurled at Redmond over the latest Office product, what would you guess the response would be? Fortunately, Macromedia is located far enough south to have publicly recognized the shortcomings and to promise major fixes in September. I'd bet on a reasonable response, less their feet are held to e-flames again. This was re-inforced by the Direct-L session at UCON, where newly anointed Director engineer / cat herder Doug Wyrick seemingly listened to developer concerns.

But was there a lesson learned? Will marketing drive development decisions? What is the impact on Director developers? Have significant numbers said "howdy" to other tools? Have corporate coffers slammed the door shut on Director/Shockwave as a platform? Probably not. There really is not a whole lot of serious competition to Director, with the cross platform compatibility and net savvy features. But there will be, and as frustrating as Director can be, it can make many of us tempted should something better swim by.

The other thing brought to light is that many developers are already juggling several different tools, as multimedia development is now calling for not only the things that Director can do, but also web content development, web graphics, database connectivity... and the kind of things which are in demands from Flash. Wouldn't it be odd if Director's major competition came from within the tent? (cue the Twightlight zone audio, fade to black).

True/False as 1/0

One old tried and true technique that I believe I sponged off of John Dowdell, is using the true/false return of a function or handler as their values of 1/0. For example, this old D5 code on a button handler, you could manipulate different attributes depending on the value of the rollover:

on buttonAnimate delta
  -- animate a button to offset by value of delta pixels
  -- as long as the mouse is over the sprite.
  -- Assumes the button down cast member is adjacent to it's
  -- up state cast member
  
  put the clickOn into currSprite
  put the memberNum of sprite currSprite into origSprite
  put the loc of sprite currsprite into origLoc
  
  repeat while the stilldown
    set the loc of sprite currSprite = origiLoc + ¬
      point(delta,delta) * rollover(currSprite)
    set the castNumber of sprite currSprite = origSprite + ¬
      rollover(currSprite)
    updateStage
  end repeat
  
end

which could be called from many scripts like:

on mouseDown
  buttonAnimate(4)
end

While these days you have more event handlers to do button animation (and you should avoid the kind of repeat loops done above), it is valuable still to manipulate, test, and use values of expression that evaluate to true/false. For example, a handler written above for platform dependent transitions, could be compacted:

on sceneTransfer
    puppetTransition 26 + 15 * (the platform  256), 4, 8, TRUE
end

So if we are on a Mac platform (parenthetical = true or 1), we get a transition of 51, otherwise, the expression evaluates to 0 and we get the transition we want for windows, or transition 26 (bonus extra credit points to the Lingo heads that know what these are by heart... I have to look them up).

This example may be trivial, but it can make for leaner code. There are a lot of other things you can do be using the relative positions of cast members and factoring by some function's return call.

Doing 5 to 7 (or Life)

I spent some time this summer converting a rather complex CD-ROM project from Director 5 to version 7. This was not just because it was a thing to do, but because we wanted to do something we could not do before; tack on a post application user survey that could be sent to us via the net (using D7 postnetText).

I'm going to save the Lingo details for next month's column-- my point here is to say that the trip from 5 to 7 was very smooth, although we are talking about a cross-platform CD-ROM of several connected movie files, QuickTime video, and even a bleeding edge defying MIAW.

First of all, it sure runs faster as a D7 projector. Next, it initially ran despite some archaic code structures (I think it even created objects using a birth command) and a whole lot of un-neccessary puppetspriting.

And then once you start attacking pre-7 code with a dot syntax axe, it becomes fun to see how much code you can collapse. The most confusing aspect was determining how to deal with text cast members, which in D7 I saw I needed to embed the fonts and re-apply the imported fonts to the text or to change all of the text member properties to save as bitmap rendered. I opted for the former, which worked out well as I was able to select a cleaner and more concise set of fonts. (I had an annoying time rooting some small speck of text that had a font of "Bookman" applied to it. It still eludes me).

I'm sold on D7-- sure it does some funky things and I still seem to have D5 or D6 reflexes. But at the same time, I am updating another CD-ROM project that will stay in D5 since the changes are minor, and there is no compelling reason or need to take it to D7.

The Blinker Behavior

Here is another puny trick I came up with in the grand old days of minimizing files for shockwave. The goal was to have some futuristic device with a bank of multicolored lights that would blink in a random order. To do some lean coding, the lights were just made as part of the background graphic and the blinking was accomplished by moving a quickdraw shape to random positions over the bank of lights:

A sample movie is available for download in Mac or PC format

It is pretty simple. There is a background graphic that consists of a series of equal sized and equally spaced "lights" or in this case squares, on a solid color background.

Create a quickdraw shape (Tools palette) that is the same size as the squares, and place it so it completelt covers the left most "light". Find it's left side coordinate (I select it in the D7 score and record the value listed for "X"). Position it over the second light, note this value, and then determine the offset from its position over the first light. This is the spacing needed between lights.

The Lingo here is pretty far from the science of rockets, but see if you can sort it out. Again, I am a minimalist (or lazy) on writing behaviors:

property mySpriteRef, myleft, myOffset, mySteps
-- Behavior for quickdraw shape member that is used to
-- randomly placed over evenly spaced areas on the stage
-- to simulate a blinking light.
on beginSprite me
  mySpriteRef = sprite(me.spriteNum)
end beginSprite
on exitFrame me
  mySpriteRef.locH = myLeft + myOffset * random(mySteps)
end exitFrame
on getPropertyDescriptionList
  set p_list = [ #myLeft: [ #comment: "left point:", ¬
    #format:#integer,  #default: 0], #myOffset: [ #comment: ¬
    "spacing:", #format:#integer,  #default: 10], #mySteps: ¬
    [ #comment: "number of lights:", #format:#integer,  #default: 4] ]
  return p_list  
end

This is the same technology that powered the consoles of the USS Enterprise ;-)

Roll the Credits

For some reason, the writers block has been huge over the summer (if you have ever stood in Phoenix, mid-day in June you might understand the environment), but I am hoping to keep more columns coming. I'm open to topic suggestions, and am looking at some future ideas on design principles, end-arounds for printinf from shjockwave, lingo to perl and back, and maybe a followup on Hello Browser! It's me, Shockwave of "Hello Shockwave, it is me, Browser".

Until then, keep on coding.

Alan Levine is an Instructional Technologist at the Maricopa Center for Learning & Instruction at the Maricopa Community Colleges. Among other random things, he tries to maintain the DirectorWeb, does side work as dommy media, and not often enough, mountainbikes in the desert.