Particle effect performance on iPhone
by Craig Fortune · in iTorque 2D · 09/05/2009 (12:57 pm) · 16 replies
I've just got round to the point where I can start adding some nice effects to my game. I'm wanting to know if anyone else is suffering CRAZY fps loss when they try using particle effects, even simple ones.?My game goes from running up near 40 fps (not even using PVRs yet, so there is another gain to be had there admittedly) to chugging and being unplayable as soon as I use particle effects.
I'm pretty sure I'm not asking anything particularly unrealistic to expect from the iPhone (the particles don't move, they just get spawned and then shrink while their opacity goes to 0. There aren't even that many!) So I'm making the assumption there is some horrid rendering or integration code for particles in iTGB somewhere - results from instruments seem to support this theory too.
Is this going to be addressed with some proper optimisation?
I'm pretty sure I'm not asking anything particularly unrealistic to expect from the iPhone (the particles don't move, they just get spawned and then shrink while their opacity goes to 0. There aren't even that many!) So I'm making the assumption there is some horrid rendering or integration code for particles in iTGB somewhere - results from instruments seem to support this theory too.
Is this going to be addressed with some proper optimisation?
#2
Seems ridiculous but possible that it will be better for me to create lots of staticsprites instead of just having a particle emitter emit particles that will do the same thing. I suppose least this way I don't have to consider physics slowdown.
09/05/2009 (2:47 pm)
My particles for this particular situation sort of form a trail behind moving objects (think of it almost as a path made of dots).Seems ridiculous but possible that it will be better for me to create lots of staticsprites instead of just having a particle emitter emit particles that will do the same thing. I suppose least this way I don't have to consider physics slowdown.
#3
09/05/2009 (3:50 pm)
You might be creating too many particles. How many particles is your emitter creating?
#4
Each object has about 5-10 particles existing from its mounted emitter at any one time. It starts chugging from 5-10 objects. MIN/MAX particles range is going to be 25/100... thats nothing imo.
09/05/2009 (3:53 pm)
Nah, would be VERY surprised.Each object has about 5-10 particles existing from its mounted emitter at any one time. It starts chugging from 5-10 objects. MIN/MAX particles range is going to be 25/100... thats nothing imo.
#5
09/05/2009 (4:48 pm)
I'm not sure then, physics engine would be my only guess.
#6
09/05/2009 (6:46 pm)
Did a super quick test (read: hack) where I just created staticsprites at intervals to get a similar effect to what I was doing with particles - MUCH better fps this way. Seems like it is definitely physics being the pain! 
#7
If such detail degree is what you seek I would highly recommend to render them in a particle rendering dedicated app (or TGB on the desktop) to an image strip with alpha and just play that one.
That will perform worlds better than particles ever will and additionally offer you full artistic freedom, not "how many particles can iTGB handle on device XY" constraints.
09/05/2009 (8:27 pm)
100 particles from a single emitter would definitely not lead to much joy, not as long as iTGB does not get batching added.If such detail degree is what you seek I would highly recommend to render them in a particle rendering dedicated app (or TGB on the desktop) to an image strip with alpha and just play that one.
That will perform worlds better than particles ever will and additionally offer you full artistic freedom, not "how many particles can iTGB handle on device XY" constraints.
#8
09/05/2009 (9:05 pm)
I never said 100 particles from a single emitter. I said in total, I was quite clear on that I thought... As stated before, the particles form a trail, so doing them in a dedicated app is kinda not the issue here.
#9
I assumed the Min / Max in relation to the effect itself.
Sorry for this missassumption.
With that in total and only very few emitters active its a whole different story naturally.
09/05/2009 (9:27 pm)
Ah I see.I assumed the Min / Max in relation to the effect itself.
Sorry for this missassumption.
With that in total and only very few emitters active its a whole different story naturally.
#10
I think I'm going to go the route of doing some little system to handle doing sprites etc. Not exactly ideal having to do that work instead of using what I should be able to... but nm.
09/05/2009 (9:44 pm)
nps.I think I'm going to go the route of doing some little system to handle doing sprites etc. Not exactly ideal having to do that work instead of using what I should be able to... but nm.
#11
One thing, depending on what you want to achieve, that I would look into is actually writting a small animated sprite descendant / sibling / decorator. An animated trail.
the difference to the sprite is that it would generate a 4 - 12 tri (depends on your needs) trianglestrip which uses the animation instead of a single quad (thats a common way to handle it when particle effects either can not be used due to trail length or desired visual effect or when the overdraw from particles would just cost too much performance as it can potentially happen on the iphone)
09/05/2009 (11:52 pm)
I know.One thing, depending on what you want to achieve, that I would look into is actually writting a small animated sprite descendant / sibling / decorator. An animated trail.
the difference to the sprite is that it would generate a 4 - 12 tri (depends on your needs) trianglestrip which uses the animation instead of a single quad (thats a common way to handle it when particle effects either can not be used due to trail length or desired visual effect or when the overdraw from particles would just cost too much performance as it can potentially happen on the iphone)
#12
As such, I just want to drop a textured quad down every now and then. Fade it over time and then kill it. Each object will only be allowed to have X amount of footsteps existing at one time. The trail is almost like a dotted path behind it.
09/05/2009 (11:59 pm)
I think we are talking cross purposes inters of the "trail" I mentioned :) You could almost think of the trail I'm wanting as footsteps.As such, I just want to drop a textured quad down every now and then. Fade it over time and then kill it. Each object will only be allowed to have X amount of footsteps existing at one time. The trail is almost like a dotted path behind it.
#13
Had a trail like the fire of a rocket and alike in mind where the trail is the result of a static particle emitter on a moving object and where a "continous stream" is the desired result.
ok in that case its naturally something different and static sprites are a good option without drawback basically :)
09/06/2009 (12:22 am)
Ah I see, that kind of trail ...Had a trail like the fire of a rocket and alike in mind where the trail is the result of a static particle emitter on a moving object and where a "continous stream" is the desired result.
ok in that case its naturally something different and static sprites are a good option without drawback basically :)
#14
Also, the VR chip in the iPhone doesn't like alpha polys (blended or tested), so all in all, I'd recommend finding other ways to cheat the effect that you are looking for if at all possible.
09/06/2009 (6:26 am)
The particle system in Torque is notoriously old and slow... it is bad on modern PC hardware, nevermind battery-friendly ARM devices!Also, the VR chip in the iPhone doesn't like alpha polys (blended or tested), so all in all, I'd recommend finding other ways to cheat the effect that you are looking for if at all possible.
#15
Maybe sprites are better than particles if you generate them slowly (one by one) like in the case of a trail. but if you need to generate a ton of new sprites in a single hit, like explosion or fireworks. I found that particles are actually better.
09/06/2009 (1:37 pm)
I actually just transfered my sprite particles into particle system and got much better results to my surprise. the effect that I have is fireworks(each sprite made out of little colorful star). the reason I was using sprites is because I wanted collision for each sprite, the idea is that you pick up these stars with your ship and you get points. the main problem was creating 30 sprites in a loop was killing my fps momentarily, but it totally sucked. when I changed it particles (with collision) it seems way better and I can blast 60-80 particles at once without getting the same performance hit.Maybe sprites are better than particles if you generate them slowly (one by one) like in the case of a trail. but if you need to generate a ton of new sprites in a single hit, like explosion or fireworks. I found that particles are actually better.
#16
Thats actually bad in this case as TGE was opted for hardware similarily "bad" as the iphone (slow cpu, low end gpu, low memory constraints), unlike TGB which has overproportional high requirements.
09/06/2009 (10:11 pm)
Luke: TGB actually does not have the same stoneage torque particle system present in TGE, TGEA or T3D. Its the one with the by far most modern system.Thats actually bad in this case as TGE was opted for hardware similarily "bad" as the iphone (slow cpu, low end gpu, low memory constraints), unlike TGB which has overproportional high requirements.
Torque Owner Bret Patterson