Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!elroy!gryphon!keithd
From: keithd@gryphon.COM (Keith Doyle)
Newsgroups: comp.sys.amiga
Subject: Re: Director Demos, etc.
Message-ID: <9029@gryphon.COM>
Date: 28 Nov 88 08:47:29 GMT
References: <11744@cup.portal.com>
Reply-To: keithd@gryphon.COM (Keith Doyle)
Organization: Trailing Edge Technology, Redondo Beach, CA
Lines: 193

In article <11744@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>Re: Blaine Gardner's comments about the ``Walker'' demo ...
>
>For example, consider Probe_Sequence:
>
>1) starts off fine, using "DDemo1:", but very quickly some of its components
> begin referencing ":" (root of the connected file system) thereby precluding
> the operation of this demo from other than the TOP of a filing system; not
> nice when one wishes to put demos in sub-directories on a HD.

When the Probe Sequence was done 2 or so years ago (by me) it had never been
made clear what the "correct" way of referencing needed files was.  It still
hasn't been made all that clear, and the undocumented characteristics of the 
Execute() command by programs run from icons muddies the water considerably.
Something you can only find out with experience.

So how have we since resolved such problems?  First we had to be made aware of 
them, which by the way didn't happen anywhere near immediately.  The original 
Probe Sequence was the first such demo I did, and it seemed to have all the 
desirable characteristics of ease-of-use runnability that were known *at 
the time*.  Put the disk in DF1: and click on the icon.  

We later found out when someone tried to move it to a subdirectory on a hard 
disk that we could have better specified the filenames as:
 
	"Diskname:pictures/filename"

instead of ":pictures/filename".  On a floppy based system (about all there 
was in the early days, remember?) the ":pictures/" method seemed to cover 
all the bases.  Unfortunately, we did not discover this particular problem 
until AFTER the Director was released, thus virtually all the manual examples 
show ":pictures/filename" (the method that seemed *at the time* to work best 
remember), and therefore many Director scripts still exhibit this 
characteristic.  We have added a blue hint page in later Director manuals 
that describes the "Diskname:" technique.  *If* they read that part of their 
manual, that is.  It's all up to the Director script writer to decide how
to specify his file names.

Unfortunately the "Diskname:" technique requires an Assign be done first
when moving a demo to a directory on a harddisk.  This doesn't quite
meet the stated requirements of the BADGE contest rules, which imply
you should be able to drag the demo to a hard disk *without* having to
add extra ASSIGN's to your startup-sequence, at least one area where
I'd say the rules are a little too strict.

We also found out that Probe had the irritating side-effect of leaving the
fonts: assigned to the DDemo1: disk after it was finished.  Fortunately
we did notice this before the Director was released, and the manual DOES
describe a convoluted sequence that allows you to move FONTS: to a
custom fonts directory and back again, (Director syntax):

	execute a,"assign tmp: fonts:"
	execute a,"assign fonts: mydisk:fonts"
	loadfont 1,12,"newfont.font"
	execute a,"assign fonts: tmp" 
  
Which by the way, must specify mydisk:fonts because the EXECUTE Director
command translates directly to a C Execute() call.  Programs run from
icons will cause the assign commands specified above to think they are
in the root of DF0: even if none of the programs or icons were ever
associated with DF0:, and even on a hard disk where everything has been
reassigned to somewhere on the hard disk and you don't even have a DF0: disk
in the drive.  e.g.:

	Execute("assign fonts: fonts",0L,0L);

Will unconditionally reference DF0:fonts any time the program is run from
an icon.  If this is not a bug, it is at least an undocumented anomaly,
that no one but a C programmer who has explicit similar experience with
the Execute command's characteristics would otherwise be aware of.

Which again, means if you drag the demo into a subdirectory on a hard disk
you'll have to do an assign mydisk: dh#:directory before you run it in order
for this technique to work.

Further, if you don't remember to do a:
	
	execute a,"assign tmp:"

You leave tmp: assigned, which presumably changes the memory useage 
slightly, violating another contest rule.  Does it usually occur to
first time programmers that an ASSIGN left undone uses some memory?
How many even know *how* to unassign?

We also have cases of:

	execute a,"copy mydisk:c/command ram:"
	execute a,"ram:command"

Used to minimize disk access.  This also won't work well moved to a hard
disk unless you do an outboard assign of mydisk:.  And OBTW, you'd better
also remember to do an execute a,"delete ram:command" before you're done.

>2) its "script" file is encoded (somehow) so that one cannot even have the
>   option of patching it to "fix" the problem.

This is not a bug, it's a feature.  Customers expressed the desire to be able
to protect imbedded copyright messages, etc. from tampering when producing
distributable demos.  While the encoding does not provide terribly secure
protection, (nothing can) it does at least mean all the strings are not 
easily NewZapable.  In-place equal-length patches of filenames is
not pretty anyway.

>That problem (with Probe_Sequence) also exists with Walker.  So guess WHICH
>demos are NOT shown on dealers' systems?

I give up, which?  I've seen or heard about both Probe and Walker running 
on hoardes of dealers' systems, with few complaints (Probe w/harddisk).

BTW, I've installed the vanilla Walker in a subdirectory on my hard disk
with no problems, though I do have to do 3 assigns first (it was a 2 disk
demo, and you have to tell it where the sound module is to be found).
This would seem to belie your implication that the ":pictures" problem also 
exists with Walker.  See!  You can't even tell what it is that's wrong with 
it.

>Demos SHOULD be able to be moved to whereever one wants for convenience in
>showing them off!

Sure, but the key word is *should*.  Now let's examine what is at least a
significant part of the Director's customer base:

	1. First time programmers
	2. First time Amiga users
	3. Computer novices
	4. People who don't have any volumes of the RKM
	5. combinations thereof

Do you really think these guys can figure out all the Assign tricks necessary
to make it work?  It took us using the Probe Sequence as a beta-test demo
and miscellaneous scattered feedback to figure out what can be done to
improve a demo's runnability.  So RGB was better, later demos better yet.
For some demos, to completely adhere to the BADGE rules no less than
10 execute a,"assign ..."'s are necessary.  10 that have to run whether
you need them or not I might add.  5 to set things up, and another 5 to
undo what the first 5 did when you're done.

To what degree is it our responsibility (as the producers of the Director)
to insure the user is correctly educated about the otherwise undocumented
CLI command and library call characteristics?  Do we even know the full
extent of the difficulties?  How much of this knowledge is really needed 
to make use of the Director?  For some, none, for others, plenty, depends 
on what you are trying to do.  Should we be confusing those who don't need 
to know with a bunch of "why should I have to do that" or "why do I need to 
know that" kind of stuff they hardly understand?

The Director gives you flexibility.  Flexibility to do it right, or to do
it wrong.  Unfortunately, the implementation details of "doing it right"
are poorly defined, if at all.    

And does the Director create "tool based" demos?  Or start-from-scratch 
demos?  Why?  (hint: see how your reasoning also applies to a C compiler,
and to something like VideoScape 3D.).  Something as simple as a 2 disk
DPSlide slide-show can run into most of these problems we're talking about
here.  They're not inherently Director problems, but level-of-capabilities-
we're-affording-the-unsophisticated-user type problems.

Now while we can suggest in the Director's documentation ways that you can
follow all the rules, (and in a future Director, automatically assign 
HERE: to the current directory (not multitaskable BTW, and you can't use
HERE#: unless you can also easily determine your CLI number and attach it
to the middle of a filename string.  Director II could use some funny symbol 
sequence "\$" or something to represent the correct HERE#: string, you still 
have to convince users when they should use it and why they have to because 
of a dos.library call that has an unexpected anomaly which you also have to 
explain.

Director II could also automatically do the appropriate ASSIGNs for font 
directories, but it is a kludgy way to go, and may present additional 
multi-task interactions.  FONTS: are global anyway, so this one's big 
multi-task trouble.  

What it boils down to, is that for Director II it seems we may have to
do specific LoadSegs, CreateProcs, and AddFonts because the higher level 
capabilities don't let you easily follow the "rules".  Excuse me for thinking 
that because Execute() and OpenDiskFont() was there that we could just go
ahead and use them.  I was used to multi-user systems where all that kind
of stuff *is* handled correctly by the OS.  Well, I'm not complaining,
I know it takes a long testing phase to iron out all the wrinkles, and
in fact, once they're all ironed out, the system's usually obsolete, time
to move on to the next generation.

If 1.4 presents new solutions we might rather use those.  
We may also then expect to see another beta-test phase where we find work 
arounds for any new capabilities that may crop up that violate common-sense
ease-of-runnability rules that aren't caught during the normal beta-testing.
Expect us to spring another Probe like beta demo on you that does weird 
things on just your system because we haven't had a chance to try just your 
combination of hardware/software.  If you donn't want to run it orinstall it 
on your hard disk, fine.  Perhaps all we really need are bigger disclaimers.

Keith Doyle
gryphon!keithd