AltME groups: search

I'm currently writing a Rogue like game with Rebol. I used a box 
to display the game map and set the focus on it so that it receives 
keyboard input but when I do that there is a weird white stripe being 
drawn on top of the box in the center. Any idea why that is and how 
I can make it go away? http://img.skitch.com/20100425-ju42itgetsasupi6yerc1ph4db.png

otherwise an alternative is to provide a sensor face, size 0x0, sitting 
in the corner. focus that and the caret won't appear. then control 
the main game area using the sensor face.

Ah well I'm sure it's going to be fixed in R3. R3 will make everything 
better. And coffee. Or so I've heard :)

if you look at that error, there is an extra char in there. it's 
possible that you can find it in the source code and delete it.

The stray char looks fairly familiar. You're probably have problems 
with cp1252- and utf8-encodings?

Ok, let me delete the space and reinsert ...

Great, thats it. And, i think it is not your fault, maybe more my 
lack of understanding how lit-words are used in rebol.  Thanks a 
lot!

It is odd. But i just don't know how to test, if it is called properly. 
For all other panels and panes it seems to work ok. I just had some 
difficulties with backdrop, which doesn't seem to resize to the full 
width.

the thing is that it should work identically from the event func 
and when used from a button

@ Gregg,


MIN and MAX on pairs right now is extremely usefull to intersect 
and or add up regions.

Just found an interesting behavior. I had a layout that mimics the 
request-password. It is launched via view/new and do-events  If I 
did an unview after the user entered in the password ( apass: field 
hide [unview] , it would close it but later on other requestors or 
view elements would disappear. The app was still running though. 
If I closed the request via a button click it works fine. I just 
wanted it to respond to a CR instead of having the user have to reach 
for the mouse. At this point though, let em reach for the mouse. 
:-)

Paul, post your method. There wasn't any common dialog for folder 
selection in Windows for a long time, and REBOL still doesn't provide 
direct access to it.

It wasn't a common dialog though, and required callbacks (at least 
the Shell API I knew of). I don't remember it in 16-bit Windows, 
but the duff on the floor of my brain is thick.

and it was running with what... less than 1 Mb ?

Partly due to the wonders of small screen resolutions and bitdepths 
(which made tiled windows a bad idea). Nowadays I have screen images 
that take more memory than Win 1.0.3 altogether :)

GET gives you the value of a word.  


the detail being that the word may or not be bound.  when it isn't 
bound explicitely, it will search for it in the global context (explicitely 
if you give it a lit-word).


which is why its always a good idea to use GUI code within a context, 
so you can be sure any un-explicit binding is local to that context. 
 note that you must explicitely create them within the context (at 
the root level of the context) for that binding to occur.


(note to Lad & Brian..I know I'm over-simplifying the whole concept, 
but that is how basically it works for "mere mortal"  ;-)

ex: 
here .... danger!   [a b c] use isn't bound within the context.

context [
	layout [a: field b: field c: field]

	fields: [a b c]
	foreach field fields [
		set-face get field to-string now
	]
]





while this will be (and protect your global context from being clobbered 
by the field names), plus you are sure that GET will try to use the 
field names locally.

context [
	a: b: c: none

	layout [a: field b: field c: field]

	fields: [a b c]
	foreach field fields [
		set-face get field to-string now
	]
]



if you really wanted to be funky, you could put words in the [a b 
c] block which are bound to other contexts using 'IN.

append fields [] IN other-context 'd


then when the loop runs, the field specified by d in that OTHER context 
will also be set.

using the above tricks you can make system-wide intialisation functions:


here is a cool previous login detection system which fills up your 
whole gui based on stored data in a database.

	

; supply contexts, view controls set into them and the data to set 
into.
setup-all-gui: func [
	spec 
	/local ctx control controls data i
][
	foreach [ctx controls data] spec [
		repeat i length? controls [
			control: get in ctx controls/:i
			set-face control data/:i
		]
	]		
]
	
; reload previous session
either all [

 main-data: get-sql-last-main-data  ; returns [ "project" "module"]

 login-data: get-sql-last-login    ; returns ["user" "encrypted" "server.com"]
][
	setup-all-gui reduce [
		main-gui [proj-fld mod-fld] main-data  
		login-gui [login-fld passwd-fld server-fld] login-data
	]
][

 print "This is the first time you use application, user-setup will 
 now be called."
	setup-user
]

that managed within the do-event of wake-events.


the fact that  detect is called, means do event was called.  whenever 
a detect returns false, it consumes the event and subfaces do not 
get their events (even time IIRC).

and after changing the rate of a face you need to issue immedialty 
a SHOW on the face

seems that engage has no effect. so you are not supposed to be able 
to use engage and detect at the same time in the same face?

I return the event, yet nothing happens. Oh, well, I've studied RebGUI 
code and it does the same thing as I do.

yes, it's not easy, however everything is working as expected, except 
for time events and the use of engage.

its possible the window cannot have time events, no matter its rate. 
 try using a master face in which you put everything, using its feel 
instead.


the window is managed differently than other faces by view... it 
has its own events like resize and stuff, so I wouldn't be surprised 
that its time handling is different.

yes - iirc window does handle time differently and you should always 
use a master face

yep.  rebol adds some move events when other events are generated. 
 you get them on mouse, window activation, and some others I don't 
remember.


its VERY annoying, though.  I think "do event" consumes some of them, 
but some go through and end-up within feel/engage anyways.

I've been battling these "stray" events for years.  :-(

With the above code on Linux I see this:

move 77x78 ; Final move of mouse to a stop, then I wait a short time...
down 77x78 ; <- I click.
up 77x78 ; <- I release, and I wait...
move 77x79 ; I begin moving mouse again.

but in both cases it shouldn't be a problem IMO. Those events just 
goes thru your handler without any real action and doesn't look like 
a performance hit at all.

I think I figured it out... I have created a pane of faces manually 
where one is focused. Then I decide to remove that pane and build 
a new one, and then focus a new face in that new pane. But my focus 
calls unfocus first and wants to perform a focal-face on a face that 
doesn't belong anywhere => crash.

Endo, I see the error in View 2.7.6.4.2 as well.
>> connection: 1
then I type "connect" and press tab --> "connected?"

And Rebol does that - try it with "con" and hit tab twice.  The bug 
is omitting user-defined words..

possibly related to binding order on app startup... the words 'connect 
and 'Content are already defined in system/words when you boot up 
REBOL, but they are unset!

the auto-completion doesn't bring up values which are unset!


but its strange that defining them doesn't tell the auto-completion 
to use their "current" value, especially since we are operating in 
the global context.

It's not the fact that it's a user-defined word. It must be something 
else. It looks to me like it's because the word 'Connection (with 
capital 'C') already exists in system/words on startup. Defining 
'connection in the global context doesn't change the capitalisation 
on the existing symbol. So I think the completion function is case-sensitive 
Try in the console:
>> Abacus: 1
>> abalone: 2
>> aba
and press Tab Tab.

you can add an event function to the window and trigger it on event/type 
= 'resize and then move the window according to its current size 
versus system/view/screen-size (or some such)

so I have to filter the correct event (resize) and object (the window/face) 
to calculate the new pos on the desktop.

try probing face/text and see if it matches the window name

one thing though.  I've discovered that at low-level (view port wake 
event) resizing generates one event per mouse move.   


it sends all of them AFTER you finished resizing (pretty dumb) so 
you may end up with up to a 100 resizing events which are all, basically 
useless except for the last one.


I do not know if they are filtered out within the do-events (and 
thus within the event-func) but you should print out something to 
see if this is the case.

I just checked and the resize event is only triggered once within 
the event-func.

I just checked and it as I remembered it, the event func only receives 
the top-level events for the window.

and if I have more than one windows open?
how can I select the right resize to the right window?

there are MANY ways to do this, and depending on the surrounding 
code you have this may or may not be optimal, but this should give 
you an idea of what is going on.

rebol [
	title: "resizing example"
]


insert-event-func 	[
    switch event/type [
        resize      	[
			if in event/face 'on-resize [
				event/face/on-resize
			]
		]
		down 		[
			; always a window title, even if clicking on a button.
			probe event/face/text
		]  
    ]
    event
]


view/new/options layout [button "nope"] 'resize

win: layout [
	button "ok"
]

win: make win [
	on-resize: func [
		/local subface
	][
		; window size is already set at this point.
		subface: pane/1
		subface/offset: (size / 2) - (subface/size / 2)
		show self
	]
	offset/x: 200
]

view/new/options win 'resize


do-events

I have a weird question, decode-url function uses parse-url function. 
But there is no parse-url at all?? even if I copy & paste decode-url 
function and create another function it gives error "** Script Error: 
parse-url has no value". any idea?

And for this case you can look in net-utils/URL-parser.

It's probably a stupid idea, but I remember that gobs were intended 
to be used in the thousands on the screen for games and the like.

One char per gob: that is simple, but maybe you can increase rendering 
speed by creating one gob per section of text which has a consistent 
font-size and style etc.

Normally I would open up the rebol editor, and paste code into it, 
save it to a disk file and then run it.  And wondering why I always 
need rebol [ ] in the header ...

and yes, it works!  I save the file after modification, close the 
editor, and then control-v to paste my code directly into the console 
... no more intermediate files saved!

btw, I'm working on getting this kind of collision detection code 
working under REBOL  :-) 


in fact, I also want to support rotated shapes, which makes it quite 
a bit more complex to handle generically, but I've done enough research 
on the subject to have a good feel on how to get it to work.


I'm hashing out all the maths to do it, and will integrate this into 
my little game engine.

I'd also really like to get some easy to use Veronoy region code 
implemented for use in REBOL, they can be quite usefull to simplify 
very advanced search algorythms and graphics apps.

I think I just found an interesting way to optimise AGG on R2  :-D 


I'm doing Animation tests with some complex vector & projection math 
(rotating/translating/projecting shapes using floating point math 
exclusively).


using AGG and a non-standard manual management of the window, I'm 
acheiving 0% CPU at 30fps FULL SCREEN (1440x900)

Sounds like a great achievement Max, keep up the great work and post 
some samples or animations or something so we can see your work.

when the collision stuff is finished, later this evening, I'll prebol 
a little script for you guys to test and have fun with.  :-D

the refresh is manually limited to 50 fps, which occurs when dragging, 
and uses less than 1% cpu on my 5 year old machine.

the system I am using now, is doing double buffering.  the AGG is 
rendered on the raster, and the call to show, tells view to update 
the window's bitmap so it reflects the changes to the raster.

cool thing is that if we don't blank the bg manually, we actually 
get a persistent buffer, and can do things like winamp visualizers 
easily.

but that means using face effects (and hence going thru view and 
back) which will kill the speed pretty quickly  :-(

image processing requires a lot of CPU juice.


 we have to render the AGG, use the bitmap in a face, apply an effect 
 on it, and then re-create a new bitmap out of it.  we aren't just 
 drawing/effecting over and over the same image memory area but creating 
 a new image at every refresh.


it would be nice if there was a complement to the 'draw function 
called 'effect.  maybe its in R3, or maybe it should be.

updated the animated vector projection tests script:

-uses the chrono library for more precise time management.

-now has option to prevent clearing the image at each refresh (feedback), 
press enter

-you can also manually increase and decrease max frame-rate on mouse 
drag using arrows.


http://www.pointillistic.com/open-REBOL/moa/files/ptest-preboled.r

on my system, I can easily go up to a 100fps before feeling lag.

Not sure if I am doing something wrong, but I simply get a black 
screen when trying the latest update.  I was able to view the initial 
demo.  Tried view 2.7.6.3.1 and 2.7.7.3.1.

I would like to use and re-use vid "panel" gui elements. Something 
like: view layout [style gint panel [text "label:" field 100 "0"] 
 x: gint (x) y: gint (y)]

Preferably, this would be done at view definition time as shown above.

set-face

 seems to show a way to handle it, but it's clumsier than I would 
 like and doesn't handle the text labels.

Hi JoshF, do you want a style (eg. your 'gint') that is simply replaced 
by two other styles (eg. a TEXT and a FIELD) as if you had simply 
specified them individually yourself, or do you want a panel each 
time (which contains the other faces) ?

Hi! Thanks for the replies!


Sunanda, I am using stylize (as shown in the example below). Anton, 
I don't mind having a panel because I need to keep the data grouped 
to access it generically after the user has set values. Here is a 
better example showing what I'm trying to do. Essentially, I want 
to create an "aggregate" widget using a styled panel, then initialize 
its elements the same way as is done for the built-in VID styles:

    REBOL [Title: "Node Property Sheet" Author: oofoe] 
    ; This example will not actually work as intended.
    
    s: stylize [
    	title: vtext red 256
    	label: text 64
    	gpath: panel [

      across  label "Path:"  field 150 "Unspecified"  button "..." 30]
    	gint: panel [across  label "Integer:"  field 50 "0"]
    	gnumber: panel [across  label "Number:"  field 75 "0.0"]
    ]
    
    view layout/size [
    	styles s
    	
    	title "Project Settings"

     gpath "main" %. ; <-- I want to just specify the label text and value.
    	gint "width" 1024
    	gint "height" 768
    	gnumber "fps" 23.97
    ] 384x256


The nice thing about this (from my perspective) is that I can iterate 
through the property panel fields, find any recongized styles and 
pickup their values (that have been set by the user) using a hacked 
version of get-face. 


Am I making sense? I just feel that there should be a way to set 
relevant panel values when you're using the style. Thanks!

It definitely makes sense, and I wanted to do this many times myself, 
but I just never got around to doing it.

It seems like the "do-facets" section in the "layout" source is the 
key (or close to the key) for doing this. There *is* a generic system 
for handling this, but it's not documented (!) and the layout source 
is far too clever for me to easily figure it out... ; - )

Possibly a style should define a function that is used by layout 
to set it's values. If so, I can do that with "with" and the problem 
is solved...

stylize/master [
	gint: panel [across label 200 field] with [
		multi: make multi [
			text: func [face blk][ ; <- strings
				if pick blk 1 [
					print ["Text:" mold blk/1]

     ; Do nothing (prevents the default PANEL/MULTI/TEXT from setting 
     the panel's face text).
					;  print mold get in svv/vid-styles/PANEL/multi 'text
				]
			]
			size: func [face blk][ ; <- pairs and integers
				if pick blk 1 [
					if integer? pick blk 1 [
						print ["Integer:" blk/1]
						; Do nothing.

      ; I was going to set the integer field's text to this number directly, 
      but the panel's

      ; subfaces haven't been created (in its PANE) at the time the MULTI 
      functions are processed.

      ; So then I thought I'd use FACE/DATA to store this value and then 
      set the field's text

      ; later in INIT, but thought better of it, since I found it's easier 
      to parse FACETS,

      ; and I don't feel comfortable using the panel's DATA facet to store 
      a value of only
						; one of its subfaces.
						;face/data: blk/1
					]
				]
			]
		]
		append init [
			;?? texts
			;?? facets
			context [
				lbl: pane/1
				fld: pane/2
				foreach val facets [
					case [
						string? val [lbl/text: val]
						integer? val [fld/text: form val]
					]
				]
			]
		]
	]
]
view window: layout [
	gint "Elephants to invite" 481
	gint "Peanuts / elephant" 5000
	btn "Calc"
]

Thank for the example, Anton! Mind: Blown. I know Kung-f... I mean, 
how VID initialization works!


Here's my cleaned up (and working!) test program. It should be a 
little more generic than your example, since it will set values until 
it runs out of facets or pane items. Label styles are treated specially 
though, as you can see. Maybe now I can fix their set-face method...

    REBOL [Title: "Node Property Sheet" Author: oofoe] 
    ; Special thanks to Anton on altme/Rebol/View! 
    
    s: stylize [
    	title: vtext red 256
    	label: text 64
    	agg: panel with [
    		multi: make multi [
    			text: func [face blk][]
    			size: func [face blk][]
    			decimal: func [face blk][]
    		]
    		append init [
    			context [
    				p: pane  f: facets
    				while [all [not tail? p  not tail? f]] [
    					either 'label = p/1/style [
    						p/1/text: f/1
    					] [
    						set-face p/1 f/1
    					]
    					p: next p  f: next f
    				]
    			]
    		]
    	]
    	gpath: agg [

      across  label "Path:"  field 150 "Unspecified"  button "..." 30]
    	gint: agg [across  label "Integer:"  field 50 "0"]
    	gnumber: agg [across  label "Number:"  field 75 "0.0"]
    ]
    
    view layout [
    	styles s
    	
    	title "Project Settings"
    	gpath "main" %. 
    	w: gint "width" 1024
    	h: gint "height" 768
    	gnumber "fps" 23.97
    ]

This is so cool! I am excited!

the SAT (Separating Axis Theorem) algorithm is even optimised so 
it only manages the edges facing each other.

the result will be several times faster since we end up only comparing 
(at a maximum) half the edges of each polygon ( for two boxes this 
ends up being 2^2+2^2 (8) as opposed to 4^2+4^2 (32)comparisons. 
 for a triangle and a box, it could even end up being as little as 
1^2+2^2 (5)  instead of 3^2+4^2 (25).


the advantage of the SAT algorithm is that its reasonably fast and 
is an early opt-out loop, so the moment we find a single comparison 
which is negative, we can positively ignore all the rest.   this 
means that it scales pretty well, when polygons aren't close to each 
other or when they are small.

next step is implementation of the gross-level polygon proximity 
test (a fast algorythm ignoring polygons which are too far away). 
 


this allows many polygons to live in the same scene without requiring 
collision tests for them.


I'll probably use a double linked-list for X and Y sorting of polygons. 
 this allows us to start at our position directly and spread the 
search on each side of the list (in both directions).

one thing which is nice in the current system is that I'm not using 
pairs, but blocks of two float values, so a part from the actual 
AGG coordinates, everything is floating point and quite precise.

sometimes doubling the number of elements makes the refresh 10 times 
slower, sometimes, there is no noticeable difference. I'm still trying 
to find the best way to render things.  my guess is the GC is constantly 
interfering since the draw blocks have to be rebuilt over and over. 
 which is still my main issue wrt using draw in R2 and even R3.


if i forego of rendering, there seems to be no noticeable effect 
of processing the collisions, so I hope, its not just "a trick of 
the light" and that my current wip (handling collisions between many 
polys) is going to work well.

Using R3 with stuff compiled and sidestepping draw in order to use 
AGG directly would probably allow several hundred frames per second 
for this simple test.

do you have any idea why your demo limits itself to 32 fps? It does 
this on my system and Sunanda's so it makes me think that it's an 
internally imposed limit.

it might be possible to use a callback and allocate our own OS timer 
via library calls, but I think it not worth the hassle.  going past 
32 fps didn't produce noticeably smoother animation, and it allows 
much more time for (slow) math and AGG rendering in REBOL.

Max - interesting achievements. Do you really think, that the draw 
dialect interpretation is the culprit and performance killer? IIRC 
Cyphre said, that time to interpret the draw block dialect is really 
negligible ...

right now, one thing is sure, the fact that I have to go thru rendering 
"passes" for each part of the rendering slows down the rendering 
a lot.


the actual number of strokes doesn't affect the rendering as much.


trying to compile all the dynamic graphics into a big block is also 
affecting performance.  but each individual group of elements is 
rendering at under 1% cpu.  rendering three passes jumps the cpu 
to 20%!!!


reducing/composing the passes together is almost as slow as seperate 
passes, sometimes even more.  i am rendering at least 32 fps.  If 
I have to rebuild a 50kb draw block at each render, the interpreter 
is "spinning air" redoing things over and over, allocating intermediate 
blocks for not much real reason, because in this case... the shapes 
actually change even comming into/out of existence dynamically.  
I can't just use static binding, the actual drawing is changing.

from a normal REBOLer's perspective I don't see any different way. 
 Don't get me wrong, draw and gobs are usefull and cool.
plus, in R3 there is some optimisations by using GOBs afaik.


but for fast Gaming, I'd completely forget about gobs, and draw and 
just allow access to the AGG  C functions as commands in REBOL.
 rasterized and displayed in a window's bitmap directly.

I've looked (briefly) in the A104 R3 host C code and it doesn't seem 
like it by what I understood of the extensions I found.  cyphre might 
illuminate me if I just missed it.

for some reason, the text command was exported, and when I tried 
to use it, it just crashed R3.


the whole system requires you to tell it where to draw stuff. all 
the C code  expects either a gob! or a low level AGG graphics object.

the issue is mostly that they need to know where to draw themselves. 
 which is not something I've seen refered to anywhere outside of 
the higher level draw commands and AGG calls.

MAJOR milestone for Game kit.


test app updated and includes multiple shape collisions and propagation. 
 quite fun  :-)

also: press g to view spatial sorting grid, its a bit mesmerizing 
to see


do http://www.pointillistic.com/open-REBOL/moa/files/ctest-preboled.r

I also want to try adding rotational collision response... i.e. push 
a polygon, and it twists as well as moves.

the user graphics are statically bound pre-compiled AGG blocks and 
render much faster, since I use AGG matrix ops directly for all of 
the rendering.

I can see a way nicer (well, if performance won't be an issue) alternative 
to Processing being built on top of something like this. With dialecting 
and extensions to interface to external hardware, it could be a killer 
app for the interactive/performance art community.

http://www.processing.org/

Hi!


Is there a good way to draw an image with an alpha channel? In the 
example below, I would expect a green outlined circle with a transparent 
background so I could composite it over the red box in the layout 
(for instance). However, I get solid (and very un-transparent) black.


    x: draw 512x512 [pen green line-width 3 fill-pen blue circle 256x256 
    200]
    view layout/tight [box 512x512 red  at 0x0 image x]

Any ideas? Thanks very much!

so there are a few options.


I'd build a transparent image to start and graph stuff over it using 
draw.

ex:

x: make image! 512x512
x/alpha: 255
draw x [fill-pen red circle  256x256 200]

does anyone have documentation for the R2 SHAPE subdialect within 
draw?


the rebol.com does doesn't have ANY information on them... and i'm 
totally at loss in trying to figure it out... its just creating random 
shapes for me right now.

I don't know of a single best way. One of the key elements, though, 
is determining what constitues "activity". If you have a central 
command dispatch loop of some kind, and every command that indicates 
activity goes through that makes it easier. Then you probably have 
some kind of default state that is used when the app starts up, and 
you revert to that. Of course, if you have useful state that you 
throw away the user won't be happy.

You could have the remote client app monitor its own View events, 
and when there are some within 5 minutes, send a "I'm still here" 
message to the server. If the server doesn't receive any of those 
for an hour, then logout that client.

thanks .. so I can use insert-event-func to monitor global events 
and just pass them on.  If I don't get any user events I can lock 
the screen until the user types in a password

In general, using chroma keying is it possible to vary the level 
of transparency?


I've been playing with cyphre's "Transparency window under View" 
script  and I do not seem to be able to change transparency levels 
when using chroma keys.


I know this script is using window's user32.dll and it's not using 
draw to do the effect.

usually, you pick a center point, and decide on a range.  you can 
filter out the transparency with additional parameters like luma, 
saturation and things like that.  

basically adding or removing from each previous step, until you get 
the alpha channel mask you want.

I wanted to create a near transparent window onto another windows 
app so I could draw/sketch over it like they do on tv during a football 
game.


playing with Cyphre's script the transparency works on the whole 
window including title bars and borders.
 

Perhaps I could use a chrome key to get full transparency on the 
area I want to see throught to and lay over that a draw based semi-transparent 
object to draw on....I'll do some experimenting.


Else I will need to make the whole project Rebol and not use this 
"cheat"

Anyone play around with particle/plasma generators on rebol...I think 
I remember a script that had like a plasma effect.


I want to try and mimick fire and smoke....does not have to be super 
realistic....

all is left, is to add/remove new pairs to your list, basically, 
the last iteration knocks off old particles from the list and inserts 
new ones at your fire origin.

for the particles, either pregenerate (and simply offset) small faces 
with an transparent image or build an AGG block at each refresh.

the plasma effect you saw used repetitive blur to an image, with 
new particles added and some offset added to the previous image.

the problem with this is that you cannot change the color and the 
fact that the whole image gets faded.

it could work if R2's effect system also managed the alpha channel 
but it doesn't AFAIK.

for more control, you can also store two sets of pairs for your particles... 
one being the position and the second being current velocity... this 
has the advantage of guaranteeing particle movement direction.  in 
your loop, all you do is add a bit of variation to the velocity and 
then add the velocity to the position.

Very cool, Maxim...thanks. 

is this done as an interactive process?

Not sure what you are asking but stage 1 would be to allow these 
fire "objects" to be placed on top of an image via drag and drop 
and allow for some editing such as sizing. (Later versions would 
allow adjusting those other variables you mentioned above). 


Stage 2 would allow for some transitions from one set of settings 
to another so for example the fire can become more intense over time 
or when clicked on or a button is pressed. 


I just had a week of training on a flash based system...its cute 
and does teh job for what we are going to use these "simulations" 
for but I thought it was a little too complicated for your average 
fireman to use if he wanted to create his own sims for drill purposes.


The flash extensions used all those variables you mentioned above 
to allow for a great degree of controll of the effects.

by interactive I mean will this be rendered or running live?


with a rendered system you can crank up the particle count and just 
pregenerate the whole data set as a series of images.  then when 
you need to see it, just cycle the image of a face.


usually, people use a few particles for preview... then generate 
"flipbooks" which are just rendered images and include thousands 
of particles with their alpha channel density reduced to practically 
nothing (like 2% visibility)  this generates very pretty effects, 
but at a cost of rendering time.