Thank you but the problem was not the elimination of confetti out of screen, rather the fact that sooner or later the carrier will also contain less than 5 elements
Just make a check first something like this
if #confettis is less than 5 then X=#confettis, else X=5
then use for i=1, X do
Anaqim
or even use:
for i=1,math.min(#confettis,5) do
Anaqim
I’m trying this way
local function test() if(random(1,100) == 1) then local pos = random(1,#confettis) local hitX = confettis[pos].x+random(-opt.width\*.5, opt.width\*.5) local hitY = confettis[pos].y+random(-opt.height\*.5, opt.height\*.5) confettis[pos]:applyLinearImpulse( random(-1, 1), -1, hitX, hitY ) end end
However I can not give the effect of the video that is that of the image I attach. Where the movement is not linear. In the red circles the confetti make a rotation for the direction change and not a random rotation.
looks like perhaps you have gravity/physics on these confettis?
Yes, right
Hi, you could perhaps use a particle effect for it?
Our software Radiance can be of help if you don’t want to do it all in code.
https://marketplace.coronalabs.com/asset/radiance-particles-effects-creator-v1-42
Otherwise, its using sprites and some advanced motion with random algorithm
Thank you
For the confetti I think it is excessive, I keep it in mind for another idea.
I would prefer something casual only that I can not give it that realistic effect
There is a free online particle generator (you’ll need to have flash installed) here, but I can say that Radiance is a brilliant piece of kit and is well worth it especially if you’re planning on writing more games.
Looking at the effect, there are two parts, there are the confetti parts that explode away from the pignata and then there are ones that fall from the top.
For the explosion, you could generate 20-30 individual pieces of confetti and give them a physics body and apply a linear impulse to them at a random angle away from the pignata and you can also apply some torque to them to give them spin. Vary the amount of force so some speed away, others will not go as far and look like they are falling.
Now for the ones falling from the top, generate how many of them at a random X value and off screen vertically (.y = -20 or so). Give them physics bodies so they will fall. You might want to vary the graphics scale for each so they fall at different rates. You can also give each one a Runtime enterFrame listener that will randomly apply a different torque every few hundred milli-seconds to get that back and forth motion. That enterFrame listener can also check their .x and .y to see when they are off the bottom or sides of the screen to remove them.
Rob
@Appletreeman Thanks, I saw the generator is very useful!!! It might be interesting to also take Radiance
@Rob Miracle Thank you very much for trying to do something like that. I think though in this case the physics might conflict with other elements (but with filters settle at all instant), rather since you talk about a function at runtime i wonder if it is not better at performance level avoid using physics and Just add something to that control…
You can stop the confetti to conflict with other bodies by setting the property isSensor to true or setting the filters for each object correctly.
And you can also achieve this with the transition library if you don’t want to use physics
Hi @maximo97,
It’s important to make the distinction between visual particles which are output by display.newEmitter(), and physical “particles” which are part of the LiquidFun framework revolving around display.newParticleSystem().
If you want the confetti to interact with other physical objects, you’ll need to attempt setting up the latter (LiquidFun). If the confetti just needs to be a visual effect, then you should use the standard particle emitter.
Brent
Well, thanks to all the advice. Now I should succeed
Hi again,
On a sidenote, I have not yet made any games where I’ve used physics.
It’s more a habit i think but just wanted to let you know that there are more than one way of doing things.
If I’d opt not to use particle effects, I’d probably use a sprite pool, some timers, transitions and the onFrame listener to achieve that pinata effect. Not much different from what Rob descriped, except no physics.
Good luck with your project!
Anaqim
Thanks again.
I want to understand one thing, the particle effects are very heavy? I ask why I avov in mind to use them for other games and I would like to know how it is their expense
Hi,
“particle effects” sound very advanced but are just a premade behaviour code that draw a lot of small sprites.
From my own tests, performance seems to be linked to how much texture memory and draw calls you are using.
It doesn’t matter is it means drawing a sprite, playing a sprite animation or drawing sprites using the particle engine (code).
I’d say that using particle effects is in most cases more efficient and lighter since you can draw many object that change in size etc over time, without any overhead from drawing “blank space” between pixels.
I might be arrested on this by those who are more knowledgable regarding draw calss and such, but this is how it seems to me.
I learned a lot while creating Radiance Particle Editor 
Take care!
Anaqim
Thanks again
I was doing a try with Rob’s advice, to give the confetti a boost every few seconds inside the runtime listener I have to use a random number like this:
local function test() for i = #confettis, 1, -1 do if(random(1,100) == 5) then confettis[i]:applyLinearImpulse( 0, 1, confettis[i].x, confettis[i].y ) end end end Runtime:addEventListener( "enterFrame", test )
Or is there a better way?
i dont know if its the more optimized way of using the onFrame event but the logic looks fine to me
Rob probably know more.
Anaqim
To optimise…
local function test() for i = 1, 5 do local confetti = confettis[math.random(1,#confettis)] confetti:applyLinearImpulse( 0, 1, confetti.x, confetti.y ) end end Runtime:addEventListener( "enterFrame", test )
This way you randomly choose 5 elements and you are not looping them all and then doing a random check.
@anaqim, emitters are handled directly by the framework and as such will always be optimal. User code (as shown above) is not always optimal. Saying that, you can create sub optimal emitters by using too many particles.