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