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. • CommentAuthoraxel012345
   • CommentTimeMay 15th 2008 edited

    
   Hi everybody :)
   
   Some needs, some idears? lol
   I will speak about all need first to speak about how we can do it.
   
   1
   I really want play a lot with energy but sometime not on the lifetime , but on many laps of time in lifetime.
   Ex : you want your particle fade to red , green , black but keep energy style when change of color .
   So you want the particle be red at 30% of energy , green at 60% and black at 100% .
   
   These needs is to manage the evolution of particle in space and time.
   
   2
   Another need in action is to have conditionnal action, like the deathzone , but when the particle is not in a safe zone , the action do nothing.
   Ex : the particle will not change color in this zone, in others yes
   
   3
   Each zone can be a getter of point location for particle right?! Initializer use it for that.
   I think we can have for each type ( Square , Rectangle , Circle , Ellipse ... ), different type of method to have point:
   RANDOM default one and use a lot for effect
   LINEAR give point left to right after give next line etc
   LINEARREVERSE the same that linear begin by the bottom
   RADIAL start from center and give point arround
   RADIALREVERSE start from out to the center
   Maybe miss some , the 3 first is the really needs
   
   
   A lot of other classes but maybe more specific to my needs so not for this time lol.
   
   If want to change this, how to do it :
   We can maybe to more abstract classe or interface but we can give some pretty calcul function of energy ( for idear 1 )
   ActionConditionnal
   Zone ( add function setMode, some mode of getting point )
   
   Axel
2. • CommentAuthorRichard
   • CommentTimeMay 19th 2008 edited

    
   1. The energy property is controlled by an easing function. To do what you wish will require a custom easing function and/or a custom action. There is no requirement for the easing function to change the energy from one to zero only. The TwoWay energyEasing functions, for example, change the energy from zero to one and back to zero again.
   
   2. The Jet action does this for acceleration. I like your suggestion of implementing this for other types of action too. I would suggest we need an action that takes a zone and another action - it applies the second action only to particles inside (or outside) the zone defined.
   
   3. I think these will only be relevant to a limited number of zones. I would suggest, rather than adding another property, we define some new zones based on the existing ones and override the getLocation method. In particular because I can envisage lots of settings we should allow for these controlled emission zones. For example
   
   package org.flintparticles.zones
{
public class LinearRectangleZone extends RectangleZone
{
public function LinearRectangleZone( left:Number, top:Number, right:Number, bottom:Number,
start:String = ZoneConstants.TOP_LEFT, direction:String = ZoneConstants.HORIZONTAL,
horizontalStep:Number = 1, verticalStep:Number = 1 )
{
super( left, top, right, bottom );
}

override public function getLocation():Point
{
// override get location here
}
}
}
3. • CommentAuthorRichard
   • CommentTimeMay 19th 2008

    
   Re 2: I've created a ZonedAction action for applying an action only within a particular zone.
   
   Re 3: I've created a LinearRectangleZone as described above.
   
   They are in SVN but I would like some feedback before I add them to any release version of the library.
4. • CommentAuthoraxel012345
   • CommentTimeMay 22nd 2008

    
   Hi Richard :)
   
   Really nice , for the ZonedAction it's another way to do the job but it's ok and more useful in this way i think so .
   For zone , you have right two they have many possibility to begin end etc... so why not each in class, many time to write all lol, maybe a package will be necessary lol.
   
   Another thing that i have see in Emitter , particle is put in array with a unshift so after in frameUpdate we have an invert order of the Zone giving.
   Ex : LinearRectangleZone with default parameter , will have particle action apply from right to left , event if we have use topleft and hoizontal.
   I don't know why you use unshift ( speed enhancement maybe ? ) , and curious to know , and have don't change it. For keep the good order in initializer , and after action parsing of particle i have change a for in frameUpdate in Emitter.
   replace line 632 for ( i = 0; i < len2 ; ++i ) by for ( i = len2; --i ; ) less memory consumer too ( very light lol ).
   
   Another suggest for initializer of position is to take in count some information about particle , like size.
   I have particle of 5x5, i want all position of 5x5 to fill a rectangle , with linearRectanglePosition i can't.
   In more it's can be nice to have it for all type of zone too...
   An idear to integrate in a cool way ? :)
   
   Thanks for your answer and adds :)
   
   Good day :D
5. • CommentAuthorRichard
   • CommentTimeMay 23rd 2008 edited

    
   replace line 632 for ( i = 0; i < len2 ; ++i ) by for ( i = len2; --i ; )
   
   That needs to be for ( i = len2; i--; ) or you'll miss the first item in the array. I used to do my loops like that in AS2, where it is faster. But in AS3 the forward loop is the faster.
   
   The reason for the unshift in the particle array is so that the renderers draw the newest particles first. This places older particles on top, which looks better visually in most circumstances. I'm curious that you seem to be suggesting that the order matters to your actions. Why is this?
   
   The LinearRectangleZone class allows you to specify the vertical and horizontal spacing in the last two parameters -
   
   new LinearRectangleZone( 0, 0, 500, 300, ZoneConstants.TOP_LEFT, ZoneConstants.HORIZONTAL, 5, 5 )
   
   Is this the what you're after, or have I misunderstood?
6. • CommentAuthoraxel012345
   • CommentTimeJun 9th 2008

    
   Hi :)
   
   Ok right ! must replace by " for ( i = len2+1; --i; ) " if you want the fastest way :D.
   
   Ok for the unshift, no problem for me , no need to manage in which order particles are positionnate.
   
   I just need to have action apply on particle in an order , with the linearRectangleZone , i can too use the inverse but i think it's wrong.
   
   Normally action must apply in order particle has been add, more logic to me.
   
   And for the space in zone , it's ok , i haven't seen the two last :) , so perfect for me :D
   
   Wait your answer :D
7. • CommentAuthorRichard
   • CommentTimeJun 9th 2008

    
   In hindsight, it would make more sense for the particles to be added to the end and the renderer to loop backwards through the particle array when drawing them. But, if I changed it now, would that cause too many problems or would it be a good thing?
   
   I'm still curious as to why your actions care about the order. My thinking was that actions should be independent of the order (this enables, for example, reordering the particle array for optimization purposes - something I'm doing in the very soon to be alpha released 3D version). Actions are just guaranteed to be applied to every particle, with no guarantees about what order they are applied.
8. • CommentAuthoraxel012345
   • CommentTimeJun 11th 2008

    
   The same way i need order in zone , i need order for visual purposes in apply of action .
   But yes we can ask many question , normally all action must apply sequential on particles .
   
   I think the order must be give ( if some ) by the zone ( LinearRectangleZone maybe ;) ) , so the first particle give by getLocation in LinearRectangleZone must be the first particle to have action apply on it.
   
   Like this it's very simple , you want to invert the way ?! change your LinearRectangleZone instance , very simple :) .
9. • CommentAuthorRichard
   • CommentTimeJun 11th 2008

    
   I'll change the sequence as suggested - push particles on the end of teh particles array and reverse the order in the renderer.
   
   But consider, because other actions may kill particles the remaining particles may not be in the expected order anyway (if a particle dies, the others will move up the list). I would suggest it's better to use a custom initializer to set a custom property on the particle that indicates the sequence, then your custom actions can use that property to know the sequence the particles were created without caring what order they are accessed.