NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/amiga/programm/18318

Internet Message Format | 1993-01-07 | 3.8 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!stanley.nde.swri.edu!kent
From: [e-mail] (Kent D. Polk)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: IPC and shared memory
Date: 8 Jan 1993 00:19:22 GMT
Organization: Southwest Research Institute, San Antonio, Texas
Lines: 66
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: stanley.nde.swri.edu

In article <[e-mail]> [e-mail] (David Navas) writes:
>In article <[e-mail]> [e-mail] (Gregory R Block) writes:
>
>>importantly, one could write "AI slaves" as seen in muds, robots if
>>you will, or perhaps highly intelligent monsters.  It all depends on
>>how you're designing the game, but it does sound as if you could
>>benefit from having a master process with either subprocesses (perhaps
>>your bbs could call an AREXX script which launched a slave or
>>something) or as separate slaves (the more complex but more powerful
>>solution).

I don't see a heck of a lot of difference between this and the signal
processing modules we have running and under development using Dave's shadow
stuff.

In our case, a module master process which (as Dave described earlier)
manages pretty much everything that the modules have in common.  Such
activities are transparent to the modules unless the module needs to do
something special with an attribute.  I.e. each module's simply defines a few
attribute and method structures and then calls the DoShadow function.  Signal
processing 'events' are managed via assigned processes. These processes run
the designated module instances' functions in its own process space while the
UI stuff, etc. is run in the module process space (I think :^)

So, multiple instance issues (as in multiple instances of a game monster
process), UI issues, configuration file loading and saving and lots more
aren't even hinted at in the module source except for the attribute
declarations.  Virtually all of the nasty and difficult ipc and
process-handling issues that I struggled with before SHADOW pretty much
disappeared. What was left was that I could concentrate on writing the real
module software.

As far as I am concerned, this is THE easiest way to handle these types of
issues (and others I won't go into here). And I know next to nothing about
object-oriented programming much less SHADOWV! (did I get everything correct
Dave?)

-----------------------------------------------------
Now, how well does this work? Well last week I had the following configuration:

1) a generic stereo parallel port sampler running on 80 us. interrupts which
   fed into a
2) waveform Delay module which fed into a
3) 4 channel Audio Play module which fed into an
4) Oscilloscope display module which fed into an
5) Event FileSave module.

Yes, I was sampling stereo at 12.5 kHz, delaying the second channel by about
500 samples, playing back the results in audio and plotting the waveforms AND
writing the results to my Quantum 52MB drive throught the FFS filesystem (the
one that came with my A3000) in realtime. (I can go up to about 17kHz if I
turn off the waveform plotting and still write to disk in realtime.)

I sampled the first 8 or so minutes of "Beauty and the Beast" this way (about
a 12MB stereo sample). Didn't miss a detectable beat in the whole sample and
quality was very impressive for an 8 bit sampler.  Once I had the file, many
more realtime effects were possible as the system didn't have to be servicing
that sampler interrupt every 80 us.

Go for SHADOW V. It's fun!

(Now how about that kickback Dave?)

Kent Polk: Southwest Research Institute (will disavow any knowledge of me)
Internet : [e-mail]
(DoF #)  : Eternal bliss can be obtained anywhere, I just forgot what it is.