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).
Related
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 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 am working on an OpenGL application for the iPhone...
My app has only 2 views:
An OpenGL view and, as a subview for the OpenGL view, a view with the sole purpose of catching touch events...
The problem is that after about 10-15 minutes of keeping the app running on the device, I get a big (0.5s-1s) delay between every touchesMoved:withEvent: call
The animation runs smooth, and CPU usage is also not the problem (10% at most)
I have no idea what might be causing this
That is weird, eh.
This happens ON THE DEVICE right? When you are not running tethered from XCode?
I would guess you are using up a lot of memory, either a leak or just in some way using up more and more memory as time goes on.
Are you familiar with the various memory tools to watch what is going on?
Also, what about this: launch a few other large apps that remain in the background. Run your app until the problem exhibits. Then, kill the other apps. Does the problem suddenly go away? If so that would suggest you're low on memory.
Would be interested to hear.
I'm writing a finger sketch type app and had the app working great on iOS 3.0. However, running the app under iOS 4.0 or greater is causing problems. Specifically, I am receiving touch events to my app approximately 5x slower on the new OS than on the old. This obviously causes my app to draw poorly because I'm capturing 5x less data points to draw between.
Any ideas on how to speed up touch event frequency on iOS4?
Certain graphics operations take a lot longer in iOS4.x than in 3.x (somewhere between 2X to 10X slower). The longer graphics execution times could be blocking the main UI thread, and not leaving enough time for the main thread run loop to handle user (touch) events.
Profile your drawRect code and see if it's now taking longer that one refresh rate tick time. If so, try speeding up or breaking up your graphics renders, or try a lower frame rate, and see if any of that helps.
You should profile your code with Shark to see where the bottleneck is. What is probably happening is some of your code that executes on the main thread (most likely something that runs in response to a touch) is taking longer than expected which is preventing your app from receiving touch events
Block the main thread less.
I have a project where it rotates 2 spindles 360 degrees both at different speeds over time. I have noticed that it runs well on simulator but when I test it on a device it is significantly slower. The timing taken to make the first 3 full rotations on the simulator and the device are:
On Simulator: 7.0, 7.2, 7.2
On Device: 19.3, 19.5, 19.7
Essentially the project works but I'd like to find out why there is such a big difference between device and simulator and I thought CGContextRotateCTM might be the source.
Sounds right.
Don't forget, when you run the simulator, you are actually compiling native code to run on your native x86 hardware. Assuming your Mac runs faster than the 800MHz ARM chip in the iPhone - no surprise it will run faster in the simulator.
If you need deterministic timing in your application, your going to need more work to achieve that. This is where people use things like the UIView animation timing, NSTimer calls, or cocos2d inter-frame timers to give deterministic time to their animation calls.
If you don't - when the next gen device comes out with a faster CPU - your app will again be messed up.
Remember when they used to have "Turbo" buttons on PCs to deal with this?! :-O