I made a board game with includes just some little animations. I reduced the fps from 60 to 30 to reduce the processor load. But the device still gets very warm.
Another application made without cocos2d is not heating it so much.
Are there any methods to calm the iPhone down?
The device state is as follows:
Wifi is always enabled
The app uses gamecenter
GPS is inactive
fps is always on 30
I use cocos2d-iphone as engine
It might be worth experimenting with different director types, e.g. kCCDirectorTypeNSTimer, and seeing if that helps at all. Those will have the biggest effect on the main loop of the game.
You should also spend some time with Instruments if you've not already, as that will show you where the CPU is spending its time and give you some hints on where you could ease things up.
I've noticed that a sequence of small time animations in cocos2d takes a lot of processor time. I've tried making tips at the level which will pulse in size. 0.1 second pulse up, 0.15 down and 0.2 stay. And i've put it all in a repeat forever sequence. Everything was terribly slow. Then i've just made the animation manually and the device calmed down and fps increased back to 60
When showing menus or dialogs that do not require animation, you can actually lower your framerate even further.
Related
I am building an Unity application as a visual stimulation for a neuroscience study. Basically, my application just shows several flickering planes periodically. However, I noticed that every time after I ran the application for a few minutes, the fps dropped to around 10~30 shown in the profiler. The drop of fps happened in both editor mode or build. Since my script is totally in cycle, I am guessing there were some accumulative issues like GC or memory leak?
Also, I noticed that when the fps starts to become unstable, I can click the Pause button in the tool bar of the Editor and then resume the application, the fps will become stable for a further period. Therefore, I am wondering what actually happens when the Pause button is clicked? Does pressing the Pause button clear or reset anything so the fps can go back to full?
When I had a similar problem, it helped just turning off "Record" in the Unity profiler. Recording consumes so much memory and the fps drop, especially when there are a lot of function calls (like deep recursions).
It doesn't sound like you are constantly creating new GameObjects and not deleting the old ones, but that would be the 2nd thing that comes to mind.
If you use lot of drag-drop references or in short form [SerializeFields], you will lose performance resulting reduced FPS. Try to get everything you want in Awake, specially MonoBehaviours, this worked for me to increase FPS. By everything I didn't mean you have to keep things hard coded everywhere. Just the classes and other things like gameObjects. Floats, int, bools,strings, lists<> should be okay and better to be serialized.
I'd like to use Unity for cross platform non game development but the battery consumption is painful. Most of the usage is read only / static, i.e., the canvas doesn't change, just panning at most (sometimes zooming, but not frequent). Is it possible to turn the FPS to 0 and reduce CPU usage?
Hesitant "yes" because there might be side effects you'll have to handle on your own that aside from some general predictions I cannot know, or may not actually save any CPU usage.
But you can try fiddling with Time.timeScale so that the game updates less frequently, but it has some rather wide-ranging implications (if TimeScale is 0, then your panning and zooming aren't going to work either if they're reliant on either deltaTime (which would be zero) or use FixedUpdate (which won't be called)).
Generally speaking though, if something's using a lot of CPU then you need to go in and figure out why and optimize it. Use the Profiler. If you're absolutely sure that your application is doing nothing and the CPU is still cranked, then there might not be anything you can do (it's an Engine problem).
Application.targetFrameRate sets how many frames per second will be calculated and rendered, so setting this to a low value will actually save power. Not sure how well supported this is on mobile devices though. Especially iOS frame rate may depend on a static setting inside your XCode project.
The Unity documentation for Application.targetFrameRate states:
- On mobile platforms the default frame rate is less than the maximum
achievable frame rate due to need to conserve battery power. Typically
on mobile platforms the default frame rate is 30 frames per second.
This should mean that setting the target frame rate to a lower value will consume less battery power.
I'm making an iPhone game which has a quite intense use of pixel shaders. Some effects make my fps rate sometimes drop down to ~22 FPS in the 3GS, but it is around ~27 most of the time.
When the FPS rate is down there, the touch gesture response becomes extremely choppy. In other words, the gesture update time reaches nearly 5hz, which is much slower than the game itself.
Has anyone experienced similar problems? Is there any way around it?
Note1: I'm already using CADisplayLink
EDIT: I had a significant improvement by manually skipping even frames. I'm not sure if that is a good thing to do but the game remained quite playable and I'm sure it is using much less CPU now.
I have a similar situation in one of my applications, where I have very heavy shaders that can lead to slower rendering on older devices, but I still want to have the framerate be as fast as it can on more powerful hardware.
What I do is use a single GCD serial queue for all OpenGL ES rendering-related actions, combined with a dispatch semaphore. I use CADisplayLink to fire at 60 FPS, then within the callback I dispatch a block for the actual rendering action. I use a dispatch semaphore so that if the CADisplayLink tries to add another block to the rendering queue while one is running, that new block is dropped and never added.
I describe this approach in detail in this answer, and you can download the source code for my application which uses this here.
The GCD queue lets you move this rendering to a background thread, which leaves your interface responsive, while scaling the FPS so that your rendering runs as fast as your hardware supports. This has particular advantages on the new dual core iOS devices, because I noticed significant rendering speed increases just by performing my OpenGL ES updates on this background queue.
However, as I describe in that answer, you'll need to funnel all of your OpenGL ES updates through this queue to avoid the potential for more than one thread from simultaneously accessing an OpenGL ES context (which causes a crash).
If your app's game loop run at 22 fps, but is requesting 30 fps, that means that the app is oversubscribing the total number of CPU cycles available per second in the UI run loop. Either try putting more stuff in background threads, or turn your requested frame rate down to below what you can actually get (e.g. set it to 20 fps), so that there is more time left for UI stuff, such as touch event delivery.
I'm developing a game for the iPhone. I've decided that 30FPS is plenty so I've written some code that only allows the App to present the render buffer every 1/30 of a second. When I tried to verify this with Instruments I got varying information.
On an iPod Touch (2009 edition, 32G) it reports 30 FPS for Core Animation Frames Per Second.
On an iPhone 3G I get wildly varying results. And not just less than 30 FPS. I see >30 FPS on a regular basis. It actually seems to hang closer to 36-39.
To investigate this anomaly I added my own FPS to the app and update it once per second. I stays right at 29 FPS on both devices.
So, does anyone have any suggestions as to what might be going on? I expect Instruments to be accurate so it really concerns me that it appears inaccurate. It makes me think I have a bug somewhere, but I sure can't find it.
Are you using CADisplayLink? This might give you a little bit more precision on your main loop.
I'm using the cocos2d framework for various of my applications, and have run into the following problem. I have set up a few sequences of actions and CallFuncNDs, the actions have durations set up and when I run it in the iPhone simulator, it works just like I expect it to: transitions take the amount of time I set them to and they go in the correct order.
When I test it on my provisioned iPhone, it all plays out in less than one second. Correct order, timing is proportional between actions, but it's all compressed into one second.
Any one have any idea why the cocos2d animations would behave differently on a device? My code is all set up similar to the cocos2d effect demos, with the difference that I am animating a ParticleSystem and not a Sprite - though the problem still shows up with Sprites.
I have experienced similar difficulties where testing the code in the simulator, it runs flawlessly. But when moved over to the device, the timing appears to be off. I've attributed this difference to the Simulator's use of the desktop CPU and Memory, where as the device is utilizing it's physical hardware and the timing is off because of how Cocos2d processes things (frame by frame, in a 'game loop'). When you start doing a couple things, the frame rate drops and Cocos miscues ... especially when you have schedules that run extremely close to each other, or schedules that cancel themself and reschedule with different timings (in increments as low as 0.1 and below is where I've run into this the most).