Hey there. I'm wishing to work on particle effects, especially impacts such as explosions. An effect I'm looking for is smoke trails coming off numerous pieces of shrapnel in the frame.
For one piece of shrapnel this is straight forward, just create the smoke particles and assign their positions and various effects relative to the desired piece of shrapnel. Fifty, or just two pieces of shrapnel becomes difficult, because you need to assign which smoke particle goes to which shrapnel piece, all with even numbers.
I've been working with spreading values, and have come up with a concept that I can work, but yet have I successfully created the desired effect.
Here's some psuedo-code to attempt to explain:
let n be any random number
let x be amount of shrapnel particles on screen at any time
//creates the desired amounts of shrapnel particles/objects
+execute explosion loop n times
//shrapnel properties are set, including IDs ranging from 0 to x number of shrapnel particles
-on explode loop
+create shrapnel particles
+assign shrapnel positions and velocities
+spread from 0, shrapnel IDs
//starts a smoke particle creation loop as many times as there are shrapnel particles, and moves the shrapnel pieces
+execute smoke trails loop x times
+move shrapnel particles according to respective velocities
//creates x smoke particles and assigns their IDs evenly between all of the shrapnel particles
-on smoke trails loop
+create smoke particles
+spread smoke particle IDs evenly between 0 and x
//sets the smoke particle positions to the shrapnel pieces evenly
-if smoke particle ID is equal to shrapnel particle ID
+set smoke particle position to respective shrapnel particle
Now all this code works up to the last few lines, at the last condition. Essentially this comes down to one question, how do I assign the smoke particle IDs evenly between the shrapnel particle IDs, so every time the loop is executed, every piece of shrapnel receives 1 smoke particle?
If you're doing a scrolling game, you should also limit it so that it's not too distant from the player or too distant from the center of the visible area. That way you don't have a ton of particles being created too far out of view, causing performance to drop.
Ahh! Thankyou! I was having issues due to the fact that I wasn't setting the object creation relative to the spawn object. I was using position setting events that weren't working as the particles were created at an absolute position instead of relative to the shrapnel... so the smoke particles were being positioned only at the first instance of the shrapnel particle.
Wait... thankyou for your assistance but i'm having the same problem as before, the thing about what i'm doing is i want to perform operations on the smoke particles after they have been created, which is where the problem lies. i can spawn particles at every piece of shrapnel fine, i was doing that with the 'launch object' function, but i am using custom movements with float variables for positions for everything, including smoke particles.
-the shrapnel particles are on screen with variable co-ordinates
-every frame a smoke particle is created at every shrapnel piece (this is fine for static smoke particles)
-once i perform operations such as scaling- relative to the parent shrapnel piece- problems occur, and only one smoke trail is scaled on screen at once
this is why i think i need IDs. because i need to keep clarifying which smoke particle came from which shrapnel piece. because once i start making post operations on the smoke particles that take data from the respective shrapnel piece, issues start arising from exactly which shrapnel piece they should take it from, as the only relative operation that works for now is the initial position the smoke particle is created at.
it's hard to make this totally clear so i hope you can understand what i'm trying to say. thanks for all the help!
Sounds like you will need ID's. There was a recent post in this board about pairing objects, and someone said that MMF pairs objects just fine without messing with spreads as long as there are exactly as many parent objects as ...kid... objects (wth do you call them??). Personally, I think this kind of thing is one of those things that end up being messier in MMF than actual code.