I'm wondering about providing an user selected option to lower the framerate in my opengl based game to conserve battery life, and in general detect parts of the game where no movement occurs and lower the framerate there as well (when saying framerate I actually mean the number of times per second the entire screen is redrawn using opengl commands)
The opengl app is made pretty much the same way as the opengl template that comes with xcode.
Did anyone check if this has any significant impact on battery life?
Sure framerate have impact on battery life. It need cpu/gpu cycles to render each frame. But how much impact on battery life depends on what are you rendering. Btw, you might want to give users ability to dimmer the backlight as well (that have impact too, huge).
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.
My daydream app is working fine when used slowly. But when I rotate my head too quick it starts giving glitches first and then the app gets crashed. I am guessing it has to do something with frames/sec loaded during high quality objects rendering or something similar. If someone has a solution, please help me out.
Assuming you have no errors in logcat, visual glitches are generally indicative of extremely high per frame GPU load.
It would be good to profile your app and share the crash report - but the only way I've ever been able to actually crash an app this way is with very large textures.
Check the size and number of textures in your scene - it's possible rapid head rotation could be causing a large number of textures to need to be loaded as objects become visible. You can also see a good list of how large the assets are at build time in Unity by inspecting the editor log after a build. This can help make sure you aren't running out of RAM on device.
Make sure you have texture compression and mipmaps enabled on all textures. Disabling mip-maps on minified textures can easily overload the GPU.
Make sure you don't have too much transparency. Adding a lot of overdraw to the scene can overload the GPU.
Follow performance optimization guidelines https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html
https://unity3d.com/learn/tutorials/topics/virtual-reality/optimisation-vr-unity
Make sure renderViewportScale is around 0.7, MSAA is at 2x or less, and you aren't using post-process effects, shadows, or any kind of deferred rendering
Stay below 100 draw calls, 200k vertices on screen.
I've been noticing lately that my game sometimes has performance issues, where each frame takes a lot longer than it should to finish. I plugged it into the CPU Sampler in Instruments and found something pretty strange (I think, this is my first time using CPU Sampler so I don't understand all of it).
glClear is apparently taking up an insane amount of CPU time (it currently reads 36%, and is steadily rising). This is a fairly processor-heavy game, so there is no way one call to glClear should be taking up so much time.
glClearColor(backgroundcolor[0], backgroundcolor[1], backgroundcolor[2], 1);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
This is only called once per frame. I don't have an active stencil buffer, so that's not the problem. One thing that might be problematic is that my game allows you to move off virtually as far as you want in any direction, meaning that your x and y location can get very far from the origin. Does glClear try to clear the entire landscape you've covered or does it only clear the dimensions of the screen? And if that's not a problem, than does anyone know why it is being so expensive on my processor?
glClear is waiting on the rest of your commands to complete (which, afaik on iOS means vsync?).
If you
glFlush();
glFinish();
at the end of your rendering, you'll see a lot of the time spent in glClear move to glFinish.
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.)