Welcome, Guest

Want to take part in these discussions? Sign in if you have an account, or apply for one below

• Forgot your password?
• Apply for membership

1. • CommentAuthorericr
   • CommentTimeMay 8th 2008 edited

    
   So consider the game Super Mario Bros. Lets say Mario violently takes down a row of five enemies of differing types [minding their own business, of course] with fireballs. Let's say they should all fly off in different directions when they get hit, starting at their current location.
   
   Let's say that when they're hit, some crazy "functionality" converts them into Flint Particles. How would, given a single Renderer object (spanning the play space, of course), one set up each Particle in the correct location with an Emitter? Is this currently possible? Would this need to be implemented possibly as a new Initializer?
   
   Further, if the Emitter is already running, is there a way to dynamically instruct it to generate new particles?
2. • CommentAuthorRichard
   • CommentTimeMay 10th 2008

    
   Look at the addDisplayObjects method in the Emitter, this will do what I think you want.
3. • CommentAuthorericr
   • CommentTimeMay 14th 2008 edited

    
   Potential bug in Emitter::addDisplayObject():
   
   I would wrap line 466 in an if-block. If someone never added the DisplayObject "obj" to the Display List then that will result in a null pointer exception. If they didn't add it the point would default to (0,0) which, to me, is fine.
   
   Perhaps something like:
   
   if(obj.parent)
{
obj.parent.removeChild( obj ); // Line 466.
}
   Thoughts?
   
   Other than that, the function looks to do exactly what I need :}
4. • CommentAuthorericr
   • CommentTimeMay 15th 2008 edited

    
   Beyond the bug I mention above, it's not exactly what I need. It's close, though. I will modify the function until I get what I need and I'll post it here.
   
   The problem for me in that function is that you reset the (x,y) location to the Emitter's origin point. D'oh!
   
   The problem was on my end: I was removing the DisplayObjects from the Display List prior to adding them to the list. This caused the prior offset to disappear; the system assumed global coordinates in the localToGlobal() function call. Whoopsie!
   
   That said, I've expanded the code "fix" I had above to the following (this is the whole function):
   
   private function addDisplayObject( obj:DisplayObject ):void
{
var particle:Particle = _particleFactory.createParticle();
var len:uint = _initializers.length;
for ( var i:uint = 0; i < len; ++i )
{
_initializers[i].initialize( this, particle );
}
var displayObj:DisplayObject = DisplayObject( _renderer );
var r = DisplayObjectUtils.globalToLocalRotation( displayObj, DisplayObjectUtils.localToGlobalRotation( obj, 0 ) );
if (obj.parent)
{
var p = displayObj.globalToLocal( obj.localToGlobal( new Point( 0, 0 ) ) );
particle.x = p.x;
particle.y = p.y;
obj.parent.removeChild( obj );
}
else
{
particle.x = obj.x;
particle.y = obj.y;
}
particle.image = obj;
particle.rotation = Maths.asRadians( r );
_particles.unshift( particle );
_renderer.addParticle( particle );
}
   That works for my purposes. I'm not sure if it's the correct default behavior (puts freshly created [read: no modifications to x/y/etc values] DisplayObjects at the renderer's origin point instead of the Stage's origin point).
   
   Thoughts?
5. • CommentAuthorRichard
   • CommentTimeMay 19th 2008

    
   That looks sensible, so I've added it to the code. My only change is to also make the globaltoLocalRotation conditional on the object having a parent. Thanks.
6. • CommentAuthorericr
   • CommentTimeMay 19th 2008

    
   Sounds good! Good point about the rotation, too. I'm not worried about that yet (though may very well be soon) and hadn't put any thought towards it. Nice!