I tested my app with instruments:
When scrolling table views, it's around 20-50 fps, (more like 25 average). Is that good enough? I've reused the table view cells and did quite a lot of optimisations.
Slow frame rates are like pornography - hard to define but you know it when you see it.
In other words, worry about the feel, not the numbers. If it feels laggy, it is.
20-50 is great. Television has a frame rate around 30, and movies sometimes have frame rates as low as 24. For non gaming situations you can do just fine going as low as 15. Rates lower than that will start to feel laggy.
Related
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.
How do I take for example 25 photos in one second at low resolution?
I want to make a burst mode but with a lot of images at low resolution (640x480)
Later I need to increase to 40fps. I mean, take 40 photos in one second
25 frames per second is very close to the iPhone movie fps of 24.0 − 30 fps. Why not make a movie, then pull out the frames from the movie to get your shots.
The existing camera access in iOS spits out frames at about 30fps. You can't increase that, period. (I assume that this is due to the underlying hardware, but I don't really know.)
You'll also have a hard time with memory. 640x480 * 3 (RGB) * 25 frames ~= 23mb of RAM. Getting that much memory -- much less that much in a second -- in iOS is going to be challenging.
To get started with this, take a look around for AVFoundation sample code -- there's plenty of it to be had -- and experiment a bit to see what you can realistically and reliably get out of a device.
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.
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.
Specs: about 320 x 270 px, 5 seconds. I don't know exactly how many images needed for a fluid animation, but let's assume 30.
What would be the best way to playback this? As a movie file in some kind of quicktime view (if available), or as an animated image sequence with UIImageView? I'm not sure but I believe loading 30 images per second is nearby impossible on the ipod touch. Any idea?
In general, a movie will have applied some compression and possibly even used a lossy compression. This means the processor would need to work harder but it has a lot less memory to read. The CPU is a fast resource. Compared to the CPU, memory is slow. Thus a compressed movie would (logically) have the better performance.
In practice, it could depend on a lot of factors, although movies do tend to be better optimized for animations. With a slow CPU and extremely fast memory, a multi-image animation might just be faster. Also, it depends on how you store those many images. But in 99% of all situations, movies will have better performance.
Well, I guess it depends.... if it supposed to be static, than a movie is the most appropriate way... it's hardware accelerated, and easy to write the code for using it. If you plan to modify the animation, and reuse it, you could load and modify images, or load a bunch of them in succession, but I imagine it's quite coding overkill for the task.
Why would you not want to use a video file? If you don't have very specific reasons, I would recommend just using the standard video playback functions provided by Apple.
This gives you several advantages:
Even if your proposed method would run fluidly, it certainly wouldn't be as well optimised for the graphics chip and therefore use up more battery
It's very easy to implement, whereas your idea would be rather complicated, and you'd spend a lot of time on a probably less important part of your app.
It's won't introduce any new bugs and is most likely a lot better tested than your custom solution.
Check out this to get started:
http://developer.apple.com/iphone/library/navigation/index.html?section=Topics&topic=Audio%20%26amp%3B%20Video