I have a problem with fps while using particles. In game I have coins which uses particles.
I have tested my application on iPhone 3gs, 4, 4s, 5 and on iPad 3. FPS goes down to 30-35 on 3GS and iPhone 4. But when I stop using particles FPS goes to 50-60.
I used also CCParticleBatchNode but didn't help :(
The code I used with batchNode:
CCParticleBatchNode *batchNodeParticle = [CCParticleBatchNode batchNodeWithFile:#"image.png"];
CCParticleSystemQuad *particles = [CCParticleSystemQuad particleWithFile:#"particles.plist"];
[batchNodeParticle addChild:particles];
[self addChild:batchNodeParticle];
Any suggestions?
Thanks and sorry for bad english.
Particle effects are very easy to use performance killers. Here are a few suggestions:
Reduce the number of particles. Usually one is tempted to start out with far too many particles. Anything above 100 should make you feel uneasy, anything above 250 should cause a mild panic attack.
Multiple particle effects running at the same time multiply the number of particles. 10 particle effects with 100 particles are just as bad performance-wise as a single particle effect with 1000 particles.
Don't use overly large textures. Most particles look fine with a 64x64 texture or even less.
There's no real need to provide a -hd version of the particle effect. Particles get scaled up on Retina devices and look the same automatically. The only benefit from using -hd particles is using higher resolution textures, which in 99% won't make any visual difference on Retina devices. This is because most particle effects are somewhat blurry in nature to begin with.
Particle batching only improves performance if you add multiple particle effects (using the same texture) to the same particle batch node.
Related
Currently, I’m trying to create a game in swift’s SpriteKit, and I’m trying to give it a smoother framerate than it has currently. Right now, whenever I, say, press a button, the framerate suddenly jumps to a much lower value, causing the player sprite (whose movement is based on a value multiplied by a deltaTime value) to suddenly jump forward. Is there any way to smooth the framerate such that the changes in framerate aren’t so sudden and drastic?
Code running in the simulator isn't a good test of the graphics performance of a Sprite-Kit (or Scene Kit) application.
This is because SK will, in order to perform certain graphics effects, utilise calls to the specific graphics hardware available in an iOS device whereas in the simulator, these calls will need to be emulated in software by the host machine, causing a reduction in graphics performance (some operations will be affected a lot, other less so), even if the underlying graphics card in the host machine is nominally more powerful that the one in the iOS device.
Simulator testing is good for testing functionality, and it can give an indication of performance. For example, an application that was running OK in the simulator suddenly starts performing poorly after a change. Checking the displayed 'draw count' shows that the number of 'draws' required to render the scene has increased, possibly causing the slowdown. Or conversely, a change may lead to an increase in performance and a reduction in draw count.
However, the only way to be sure is to test the application of a real device.
I am writing a game in SceneKit, and it is divided into levels. Each level uses different basic shapes (the ones that come in Xcode/SceneKit as default, found in the object library) as "obstacles" that the player must avoid. So level one has blocks as obstacles and runs at 60 FPS on iPhone 6 and a below, yet when the player plays level two, which uses Pyramids as obstacles, the FPS drops to 10. There are less than 500 nodes in each level. It runs at 60 FPS on iPhone 8. What is occurring and how can it be fixed?
Here is a youtube link that displays how they are being used in the game. It is run on an iPhone 8 Plus and has no FPS issues; however, if run on an iPhone 5s or lower the frame-rate drops very low for the first level, but not the second.
This link provides it with statistics running. WaitDrawable takes up a big portion.
Here are images of the wireframes, with and without materials.
The issue was that Physics was being called on every frame, then performing some logic. The player was hitting the floor, used to center the block, every frame. I changed the contact bit mask and all the issues went away.
The goal is to simulate the explosion of the building. Currently developing a simulator to Unity 3D. However, now in the time of the explosion, at 4000 colliders fragments building FPS drops to 0.
Impression that unity3d can not provide the necessary performance.
Are there alternatives to the optimal physical calculation and a sufficient level of graphics (lighting, explosion sprites, textures etc)?
4000 colliders is excessive, specially if all start colliding at the same time. You can always optimize and "fake" things. Depending on the scope of your simulation you might not need all generated particles to collide. For example, dust and tiny particles could be voxels.
If your simulation is calculation heavy, which any Physics simulation should be, then you should delegate the number crunching to C.
In Unity you can also take advantage of the shader language and send packages to the GPU to help you render. You should also look for ways to optimize, such as caching Components. Good read on optimization in Unity.
You can also tell your simulation to ignore certain collisions between certain objects, such as, ignore collision between A and B.
Once you hit the ground or a certain condition you could also add this line of code:
rigidbody.isKinematic = true;
That will make Unity ignore Physics for that Rigibody. Info here.
I'm working on a relatively simple 2D side-scrolling iPhone game. The controls are tilt-based. I use OpenGL ES 1.1 for the graphics. The game state is updated at a rate of 30 Hz... And the drawing is updated at a rate of 30 fps (via NSTimer). The smoothness of the drawing is ok... But not quite as smooth as a game like iFighter. What can I do to improve the smoothness of the game?
Here are the potential issues I've briefly considered:
I'm varying the opacity of up to 15 "small" (20x20 pixels) textures at a time... Apparently varying the opacity in this manner can degrade drawing performance
I'm rendering at only 30 fps (via NSTimer)... Perhaps 2D games like iFighter are rendered at a higher frame rate?
Perhaps the game state could be updated at a faster rate? Note the acceleration vales are updated at 100 Hz... So I could potentially update part of the game state at 100 hz
All of my textures are PNG24... Perhaps PNG8 would help (due to smaller size etc)
It's really hard to debug graphics problems with this. Try using the openGL ES instruments to find where are the bottlenecks. It's quite handy. Also, look at the WWDC videos on openGL. They're really good.
One thing I noticed is that you said "I'm rendering at only 30 fps". Does it mean you're manually setting up a timer or something? This is not a good way, instead you should use CADisplayLink to get notified when the screen wants to update. It could improve your smoothness.
To complete Mo's answer on the 30fps...
The fact that you request the update at 30fps does not mean you're going to get it. I'm not an iphone programmer, but I can tell you that if your frame rendering takes 100ms, you're guaranteed to never update faster than 10fps. And if you're actually rendering at 10fps, then smoothness is gone.
So, measure the time you take to render to get an idea of what actual frame rate you get. As to how to optimize the rendering specifically for iphone, I'll leave that to people more expert than me on the subject.
I try to draw rain and snow as particle system using Core Graphics.
In simulator rendering proceeded fine but when I run my app on real device rendering is slow down.
So, advise me please approaches to increase particle system drawing performance on iPhone.
May be I should use OpenGL for this or CoreAnimation?
OpenGL would be the lowest level to drop to for the rendering, so should offer the best performance (if done right). CoreAnimation would be close enough if there are not too many particles (the exact figure depends on other factors, but upto about 50 should be ok).
When you say you're using CoreGraphics at the moment do you mean you're redrawing based on a timer? If so then CoreAnimation will definitely help you out - as long as you can seperate out each particle into a view. You could still use CoreGraphics to render the individual particles.
Are you using a physics engine to calculate the positions?
If you are simply drawing a view with Core Graphics, then redrawing it every frame to reflect the movement of the particles, you will see terrible performance (for more, see this answer). You will want to go to OpenGL ES or Core Animation for the particle system animation.
My recommendation would be to look at CAReplicatorLayer, a new Core Animation layer type added in iPhone OS 3.0 and Snow Leopard. I've seen some impressive particle systems created just using this one layer type, without using much code. See the ReplicatorDemo sample application (for the Mac, but the core concepts are the same), or Joe Ricioppo's "To 1e100f And Beyond with CAReplicatorLayer" article.
It's hard to give advice with little to no information about your implementation. One thing that is a major bottleneck on the iPhone from my experience are memory allocations. So if you're allocating new objects for each particle spawned, that would be the first thing you might want to fix. (Allocate a pool of objects and reuse them.)