thad@cup.portal.com (Thad P Floryan) (11/25/88)
Re: Blaine Gardner's comments about the ``Walker'' demo ... You should try it on a 68020- or 68030-equipped Amiga: 1) the Walker becomes a Runner 2) the audio is multiplied into the ultra-sonic range, attracting bats and vampires from miles around! :-) 3) the video is (attempted to be) displayed at 240 frames/second; not nice on an NTSC system at 60 frames/second: video tearing, "snow", etc. Other DIRECTOR-created demos operate fine on a 68020 system, so it's not clear where the problem lies, BUT such (obvious) software timing loops controvert the spirit of the BKDC rules and also controvert the Amiga Programming Guidelines first issued at the May 1985 Developers' Conference (re: the compatibility of programs with different CPUs, etc.) Another serious problem with nearly every DIRECTOR-created animation I've seen is the misuse of file search paths. 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. 2) its "script" file is encoded (somehow) so that one cannot even have the option of patching it to "fix" the problem. That problem (with Probe_Sequence) also exists with Walker. So guess WHICH demos are NOT shown on dealers' systems? Demos SHOULD be able to be moved to whereever one wants for convenience in showing them off! Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
keithd@gryphon.COM (Keith Doyle) (11/28/88)
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
daves@hpcilzb.HP.COM (Dave Scroggins) (11/29/88)
Thad, >Another serious problem with nearly every DIRECTOR-created animation I've >seen is the misuse of file search paths. > >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. > >2) its "script" file is encoded (somehow) so that one cannot even have the > option of patching it to "fix" the problem. This sounds like an "operator malfunction" (or programmer malfunction in this case>) rather than a Director problem. Of course I haven't done much with my Director. Too much gets in the way!! :-( (such as kids, wife, home repairs, WORK!! ;-) ) By the way -- I haven't seen that many DIRECTOR demos. Could you maybe point me in the right direction to get some Please??? Thanks, Dave S.
blgardne@esunix.UUCP (Blaine Gardner) (11/29/88)
First off, a disclaimer: my site got NO news over the Thanksgiving weekend, and it looks like it all went to the bit bucket, so I may be rehashing something that's already been covered. From article <9029@gryphon.COM>, by keithd@gryphon.COM (Keith Doyle): > 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. Understandable, but would it be much trouble for you to generate a new script for Probe Sequence so it could be run from a hard drive? I at least would appreciate it. (This viewpoint brought to you by someone who was up until 1am this morning trying to fill an 80 meg hard drive with neat demos for the University of Utah computer fair. It looks like it should be a fun show, we've got a set of Klipsch speakers aimed right at the NeXT table! :-) > 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). I hope I didn't start any flames with my first posting, but I was trying to figure out why Walker was crashing. I still have no idea why (maybe it was already discussed), but I found out how to stop it. If I have IconX execute a script that makes the 3 assigns, and runs the demo, nasty things happen, including writes to the hard drive that corrupted one or more of the data files. On the other hand, if I have the following IconX script, everything is fine. newcli from walker.exec Walker.exec is the same script that IconX was executing directly before. From memory, the script is: Assign wdemo1: "" assign wdemo2: "" ;or whatever the volume names are assign ????: ??? ;can't remember what the sound assign was projector walker.film (I should note that both disks were copied into the same subdir on my hard drive, and both assigns are to the same directory.) I got the idea for the "newcli from walker.exec" IconX script from a local dealer who noted that executing a script from the CLI worked fine. Anyway, I've got it working now, and I hacked out an icon (from the "loading demo" screen) if anyone wants it. Two questions: 1) Was this problem cause by IconX, The Director, or the phase of the moon? 2) Sometimes when the Walker demo is exited (by clicking a mouse button) the sound channels are not given back to the system. Any fix for this? Thanks, Blaine. -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 Here: utah-cs!esunix!blgardne {ucbvax,allegra,decvax}!decwrl!esunix!blgardne There: uunet!iconsys!caeco!pedro!worsel!blaine (under construction) "Nobody will ever need more than 64K." "Nobody needs multitasking on a PC."
thad@cup.portal.com (Thad P Floryan) (12/02/88)
Thanks, Keith, for the detailed description of The Director's evolution! For the record, the FIRST demo *I* usually show off is Probe_Sequence along with my narration (I've gotten pretty good at it by now! :-) My comment re: demos shown at dealers was not an idle one. At busy dealerships, people aren't going to wait minutes to boot up a demo from a floppy(ies), they NEED to be able to quickly initiate whatever it is they want to show, implying use of a HD. Though Director-based animations I've seen multi-task well (e.g. the system is as it was when the demo is ended), the need to boot from floppies for certain demos tends to belie the multi-tasking aspect of the Amiga. Sigh. Maybe some BADGE people could assist the beta-testing of your product(s). Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
thad@cup.portal.com (Thad P Floryan) (12/02/88)
Re: Dave Scroggins' quest for Director demos ... A large quantity of such demos are wending their way amongst the Amiga-related BBS systems and are also available at many dealerships for a nominal fee (typically $3 to $4 which covers the cost of the disk, the labor to make the copy, and any "packaging"). People gotta be "cwazy" uploading/downloading 500Kbyte files at 1200 baud! :-) Me, too: I just uucp'd the ENTIRE GNU software at 2400 baud from osu-cis. :-) But, seriously, if you have a copy of Chet Solace's ``The FINAL List'' (a guide to ALL Amiga BBS systems worldwide), look up the numbers for BBS-JC, FAUG-BBS, and BBS-HT on which some of the demos can be found. The local Amiga dealer, HT Electronics in Sunnyvale, CA, also appears to have EVERYTHING in the way of demos, software, etc. and they do ship to out-of-state customers on a demand basis; mail order is NOT their forte; they can be reached at 408/737-0900. Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]