At 23:44 +0200 06/04/2002, Michael von Aichberger wrote:
>If you have lots of media (as enumerated in your last posting) and give the
>user means to bring them together and make kind of a presentation, there
>must be something in the structure of your program that takes the role of
>the timeline in Director (which I presume you don't use as such, do you?)
That's correct, on both counts. What I use is a file/folder
architecture that I made using #text members and a monster, massive
list/DB manager behavior. There are file icons, and each file
represents a link to a "slide" document. The slide documents are
actually custom-generated two-frame Director movies that reside in a
library directory on disk.
The list displays vertically and top-to-bottom is the order of
playback, with folders being "expanded" for playback as well when
they've been added to a presentation.
The slides themselves are what contain the media elements, and
because they are generated in the edit module they're capable of
tracking their own resources and keeping up with their display modes.
So the slide files are containers for media that are meant to display
onscreen in more or less a single pass, while the file/folder system
is the playlist used to determine in what order these slides appear
onscreen.
The slides themselves have been made in the editor module to interact
with the user when needed, so items can be made to do things with
clicks, etc., including making other things appear or disappear,
opening external programs, launching a browser, etc. The slide
editing uses a similar metaphor to the player, with files and
folders, etc.
The editor has a two-level mode of containment for media; there's a
master "library" that holds all common-pool resources, so if you have
a big background bitmap you want to appear in 50 slides you can put
it into the library and any slide that uses it uses a link to it.
Thus you use 1.2 Mb of storage rather than 60 Mb.
Additionally slides themselves can contian specific items that are
used only in that slide, so when you delete them later on (if you
want to) the actual space on disk is freed up. (Director, of course,
does not compact files when saveMovie or save castLib is called on
its own; you have to save as manually.)
End users create a playlist (using yet another external cast file)
that also contains slug members for anything in any slide that's been
marked as user-editable. Thus users can change the wording of text in
something, for instance, without being able to change the font, or
the color or size. The sprites get their members swapped; the
"master" slide file in the library remains completely unaffected.
That was necessary because the purpose of the library includes its
ability to be updated from time to time. Users can download updates,
or get them on a CD, to ensure everyone is dealing from the same
deck, as it were. So storing user changes in the library itself (on
the builder side) was really out of the question.
>What is the timebase in your program? Is each piece of media an object of
>its own and does that object contain the code to trigger itself?
Depends. With a QuickTime file, for instance, the movie can be set to
be "active" or "inactive" (visible or nonvisible), with the option of
having its state toggled n secods after the slide loads, or with the
option instead to have its state toggled when the user points to or
clicks something else in the slide.
If the movie is set to have its controller bar present, it does not
begin automatically playing when it's made active; else as soon as it
is activated it begins playing. A click on the video sprite will
cause it to toggle its play state.
These things are all ahndled by custom-attached behaviors. The user
doesn't see this; it's all selectable by popup menus or, in the case
of video, some of it's simply attached automatically because it's
necessary.
>Does each
>object know by itself when and where to appear on the stage or is that
>defined somewhere else, more globally for all objects?
It's per object, with custom-generated and -attached behaviors.
setScriptList was a real blessing here. I can set params when I
attach the behaviors. No testing, no globals that need to interact,
nothing -- each element is responsible only for knowing its own
state, and each slide is responsible only for containing its
elements, and the builder is rsponsible only for determining the
order in whic the slides appear, are printed, etc.
Note that version 1 of this was made without a pure OOP model and
quickly became unwieldy and quite shaky.
--
Warren Ockrassa | http://www.nightwares.com/
Director help | Free files | Sample chapters | Freelance | Consulting
Author | Director 8.5 Shockwave Studio: A Beginner's Guide
Published by Osborne/McGraw-Hill
http://shop.osborne.com/cgi-bin/osborne/0072195622.html
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list, email
[EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for
learning and helping with programming Lingo. Thanks!]
