From: dstampe@psych.toronto.edu (Dave Stampe)
Subject: Re: SCI: Object behavior in VR
Originator: hlab@milton.u.washington.edu
Organization: Department of Psychology, University of Toronto
Date: Sun, 4 Oct 1992 14:03:09 GMT



marc%eris.Berkeley.EDU@ucbvax.Berkeley.EDU (Marc DeGroot) writes:

>I've been following with interest some of the discussion about how to
>describe the behavior of virtual objects.  Lance Norskog's thoughtful
>postings have been wonderful, yet I have a bone to pick with the
>choice of Scheme as the description language.
>
>My own choice for an interpreted language would be Forth, which has
>all the advantages of LISP-like languages, plus a few more:

I'm not sure either Scheme or Forth are a good idea.  The problem can
be summarized: is it efficient and is it required?

For efficiency, any action taken by a program will have to call on
routines that are part of the world-structure support, even one as
simple as create(), destroy(), move(), etc.  This assures portability
and high efficiency.  It is trivial to create a set of "standard"
actions for, say, animation that would be run on a "real-time" basis.
Letting the world programmer have access to the interrupt-driven paths
of the program directly could result in a "hung" program very quickly.
I'd prefer to try to build an interface to all the scheduling stuff,
with data structure definitions for the interface.  Real time
multitasking is OK, but if you do something 1000 times per second (i.e
testing if an object has collided) then it's best left to the
programmers who code the system so efficiency can be guaranteed.

Code could be largely pre-compiled.  It would consist of setting up
data structures, building links, and filling in fields.  After the
setup/compile stage, very little action need be taken by a user
program.  In exceptional circumstances, an event could be sent to a
user routine, which would do some simple action as a result (change
action lists or modify fields in a data structure, for example), but
NOT anything that will be executed on a regular basis.  Things like
updating position for a movimg object are better done by an internal
scheduler.

Now the question is, why use Forth?  I don't really see any advantages
myself, except those that rely on the simplicity of the interperter.
But Forth can be very inefficient, with more instructions executed to
perform a task.  So why not use a C varient?  Arguments about
compiling speed are not really valid.  I can completely recompile
REND386 in 3 minutes, and the usual modify-compile-test cycle is about
20 seconds.  In the case of a C varient based on data structures for
animation, you'd just add some pseudo-calls that change fields in
structures or build command lists (by these I mean a pseudo-state
machine interperter used for motion control and testing).  This has
the advantage of being immediately understood by the vast majority of
programmers.

--------------------------------------------------------------------------
| My life is Hardware,                    |         Dave Stampe          | 
| my destiny is Software,                 | dstampe@psych.toronto.edu    |
| my CPU is Wetware...                    | dstampe@sunee.uwaterloo.ca   | 
| Am I a techno-psychologist, or just an engineer dabbling in psychology?|
---------------------------------------------------------------------------
Newsgroups: sci.virtual-worlds