That good news, about the performance. Now, how easy is it to access object's instances in your event system. For example(a pretty extreme case actually), I have an object. It collides with something, and I want to either destroy, or lower life on certain objects, but only in that area(say a bounding circle). How easy is it to access only those specific instances of said object that are within the circle, and for (example) weaker enemies, destroy them, and stronger enemies simply lower life?
you could do it with a distance expression, but you said circle, so for this example, I'll use an actual sprite circle:
let's say you put several life lowerable objects in a family called Hurtable
Victim----on collision with Something:
--------------------Move SplashCircleSprite to Position of Something
-----For Each Hurtable
-----------Hurtable is overlapping SplashCircleSprite
--------------------------------Hurtable private variable Energy minus 10
Hurtable private variable Energy equal to or less than 0
-------------------Destroy Hurtable
The 'picking' system automatically (in ways defined by the plugin) picks the objects relevant to the condition. So any actions under a condition, so for example:
On Sprite Collides with OtherSprite
would automatically only act on the particular Sprite(s) and OtherSprite(s) involved in the collision
[quote:2lknlr9u]
Also, say I want to create my own plugin for sounds, using maybe OpenAL, or cAudio. In your XAudio2 plugin, it has 64 channels, but the I would do it would not to have channels. The audio API manages all of that(including mixing) and simply returns pointers to sounds, which you need in order to stop or change position(3d sound) of the currently playing sound. Now if you can't easily return/send actual C pointers to/from the plugin, I could simply create a data structure to hold all the pointers, and return an index. But, can you describe a little how that would work, either pointers or simple integer indices???
you can do any type of c++ you can think of in a plugin, period. plugins are able to communicate with eachother if necessary and pass any type of data through void pointers.
you design the interface for the construct user within the confines of the ActionConditionExpression system.
Basically, you decide a list of possible actions (things they can do, ie. Set Reverb to 10), conditions (things they can check, or have triggered, If Player is within hearing distance of Sprite), and expressions (GetCurrentReverbLevel).
as i said before though, the plugin is just c++, you can include whatever libraries, and do whatever you'd expect to in a c++ program
...
....just reread your question, and I realize I misinterpreted it maybe, so
you mean return these pointers to the Construct user?
yes, indices in a vector, list, etc, would probably be the simplest way to give these to the enduser. The XAudio plugin has AutoPlay features that does something similar already. You can Autoplay sound "blahblah", and if the user still wanted to know what channel it was autoplayed to they can Set Private Variable MyPV to XAudio.LastChannelPlayed.
The beauty of it is how flexible it is, though:
I'm not saying this would or wouldn't be a good/bad idea, but an example of how many different ways you could approach it if you wanted to be weird/creative. for example you 2 plugins, a soundmanager plugin and a sound effect plugin. when a sound was played through Soundmanager, it would create a soundobject, which they could then move around the layout with it's xyz coordinates, even add a behavior to if they wished. It could automatically destroy itself when the sound completed playing. You actually would need SoundManager at all except for caching sounds or whatever prior to playing them if you were doing that.
welcome to the boards, btw