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. • CommentAuthorbritg
   • CommentTimeJun 6th 2008

    
   Howdy, I apologize in advance because I haven't spent any real substantive time with the flint particle system yet, but I was wondering if it is the right tool to help with starfield generation.
   
   Here is the how it will be used:
   - the game is a space shooter
   - the player's ship is stationary in the center of the screen
   - movement is simulated by the startfield reacting to user-input (i notice v1.0.3 was just released with keyboard events)
   
   I have actually written my own code for this but I have a distinct feeling it's not up to par as it maxes out my cpu while moving! haha.
   
   I don't necessarily want to know "how do I do this" as I enjoy writing the code and learning a tool. Simply, in your qualified opinion, is this the correct tool to get started with? Is there another tool out there that is better?
   
   Thanks in advance!
2. • CommentAuthorRichard
   • CommentTimeJun 6th 2008 edited

    
   Hi, and welcome. Flint could certainly do this and I don't know of any tools that are better suited than Flint for it. In fact, knowing Flint as I do, I can imagine knocking it up in half and hour or so - but I'll let you have the fun of playing with Flint. Let us know if you get stuck.
3. • CommentAuthorbritg
   • CommentTimeJun 6th 2008

    
   Thanks, good to know.
4. • CommentAuthorbritg
   • CommentTimeJun 8th 2008

    
   Here's a question for ya as I'm working through this. Is there a way to set the emitter's counter to multiple KeyDownCounters? For instance, I want particles to be generated whenever I press the Keyboard.DOWN and Keyboard.UP keys.
   
   I image that if there isn't a solution already in place, that I should modify the KeyDownCounter to accept an array of keys?
   
   

   
   public function KeyDownCounter(counter:Counter, keys:Array, stage:Stage)
   ...
   

   
   
   Am I conceptualizing this correctly?
5. • CommentAuthorbritg
   • CommentTimeJun 9th 2008

    
   Well, I think I answered my own question - I ended up not changing your KeyDownCounter and instead did the following:
   
   - went with a Steady() counter
   - added a Move() action
   - added a TargetVelocity() action instead of a Velocity() initializer
   - updated the TargetVelocity during the game loop and fed it x and y velocities
   - paused the emitter if x and y velocity go to 0
   
   This all worked better than the KeyDown classes because the ship may still be drifting when a key is not pressed.
   
   I have to say Richard, this is a great framework you've got going here! Here's the result of about 2 days of playing - still a few quirks but overall it runs well and was easy to implement:
   http://ss.as3gaming.com/spacesurvivor.html
   
   A couple of issues - can't figure out how to 'run ahead' when no Velocity initializer is in place, but to be honest I haven't tried very hard. Have any thoughts on that?
   
   Also, I placed a MultiZone comprised of 4 LineZones around the edges of the game screen so that stars can be generated from anywhere based on the velocity vector. I'm afraid though that this may be inefficient, because only 2 zones at most are producing visible particles, whereas the other 2 are creating particles that are immediately DeathOffStaged(). Is this a valid concern, and do you know of a better way of doing it?
   
   Again, thanks for sharing this great library.
6. • CommentAuthorRichard
   • CommentTimeJun 9th 2008

    
   can't figure out how to 'run ahead' when no Velocity initializer is in place, but to be honest I haven't tried very hard. Have any thoughts on that?
   
   I assume this is about filling the screen with stars at the start. The run ahead simply calculates and applies a number of frames based on the current settings. If you tell it the ship is moving - whatever the effects of that are - then the stars should move accordingly (and instantaneaously, so you don't see the movement.
   
   However, a better option may be to operate the emitter in two phases. The first phase uses a position initializer using a rectangle zone covering the stage and a blast counter to create a number of particles. You call start on this emitter, causing the particles to be created and placed randomly over the stage. then you change to phase 2 - change the counter to a steady counter and change the zone on the position initializer to the four lines around the stage, so now the system works as you've designed.
   
   I placed a MultiZone comprised of 4 LineZones around the edges of the game screen so that stars can be generated from anywhere based on the velocity vector. I'm afraid though that this may be inefficient, because only 2 zones at most are producing visible particles, whereas the other 2 are creating particles that are immediately DeathOffStaged(). Is this a valid concern, and do you know of a better way of doing it?
   
   I don't think it's of great concern - you don't seem to be having any speed issues. Also, it's worth noting that a DeathZone with a rectangle the size of the stage is a lot more efficient than a DeathOffStage, so if you have speed issues switching to a DeathZone would be the first thing to change.