I'm working on an iPhone game using OpenGL ES. I recently updated my iPhone 3G to iOS4, and ever since the update, when I've been play-testing my app I've been getting very high latency on my accelerometer and touch events -- my phone will often respond a second later than it should, which makes the game unplayable. This doesn't occur all the time -- about half the time the game works perfectly. I've set up the accelerometer following Apple's guidelines; one of my view controllers calls [UIAccelerometer sharedAccelerometer] in its init method and implements the appropriate delegate method which just grabs the x-component of the UIAccceleration object, and I have another view connected to a view controller that detects touches using touchesBegan:withEvent: and the other touch event handlers.
I emphasize that this worked fine when I was running 3.1.3. I'm totally stymied. Has anyone run into this problem before? Is this a known bug with the 3G and iOS4? Should I update to CMMotionManager?
I think it's been widely reported that 3G and iOS4 don't play nicely... very sluggish lack of responsiveness over all. You would be wise to do iOS4 testing on an iPhone4 or 3GS.
Touch events shouldn't lag. What you might be experiencing is some form of render lag (not sure how deep the render pipeline, but in many PC games it's noticeable at not-so-low framerates), which feels like input lag.
Apart from that, I dunno. CMMotionManager produces much nicer data, but only works on iPhone 4 IIRC.
Related
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've just started playing with OpenGL ES, mostly on iPad and have noticed some problems I cannot find the answer to. First I've tried using two EAGLViews using separate renderers in the same window. Basically think the OpenGL ES example project in XCode but with two EAGLViews and two renderers etc. Now this does not seem to work in the simulator, it only shows one of the views (it seems to run the rendering code, but only one view is displayed with openGL) but when run on the device (an iPad using iOS 4.2) it does work, at least kind of which leads to the next question.
The updates to the rendering is triggered using CADisplayLink on both these views. This does however cause some problems. Most of the time, after just a short while, the updates on one of the views stops, its CADisplayLink stops triggering. This only happens on the device and not in simulator. It can be "fixed" by using timers instead of CADisplayLink, or timer on one view and DisplayLink on the other, I would like to know what is causing this though. I'm creating the display link like this (in both views):
self.displayLink = [NSClassFromString(#"CADisplayLink") displayLinkWithTarget:self selector:#selector(drawView:)];
[displayLink setFrameInterval:animationFrameInterval];
[displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
Now the last question is about an odd thing I have noticed. When running the OpenGL ES example project provided in Xcode in the iPad simulator with the view resized below 760 in width, it does not render anything to screen, It only concerns the width though, the height can be resized in any way. It only happens in the simulator, not on the device.
So the questions are basically if the things mentioned above are bugs, features or if I'm just doing it wrong?
Thanks
/j0h
I found a similar problem running two OpenGL views at once, each running on a separate CADisplayLink, both running forMode: NSDefaultRunLoopMode. When testing on an iPhone 4S running iOS 5.1, there were no issues except for when exiting the MPMediaPickerController, one of the views would stop rendering. However, on the iPod Touch 3rd gen running iOS 5.0.1, I did notice the issue where one or the other view would stop rendering randomly (due to CADisplayLink not firing). I was able to fix it by switching to NSTimer for both views (just doing it for one or the other wouldn't work). Sizing to multiples of 32 did not make any difference for me.
I can't find any information on this but really need to know for sure if it doesn't happen, or if the documentation that proves it does happen is just too hard to find!
The background story:
When my app is running on an iPhone that has a weak 3G signal, and therefore switches backwards and forwards from a weak 3G to a strong 2G and vice-versa, it seems to freeze (the app, a complete freeze for 5-10 seconds). I have had reports of this from far and wide but it's something I can't replicate as my 3G signal is too strong in my area!
If I squeeze my iPhone 4 tightly, then I can dim the signal enough that I get an alert telling me that there is no cellular data network ... before it switches to 2G briefly. This DOES cause a freeze, and I tracked it down to the alert causing the app delegate method "applicationDidBecomeActive" to be called after the alert is dismissed, but no "applicationWillResignActive" as I had expected when thinking of the normal suspend/resume process.
I changed some of the logic in my code to deal with this, and that problem is now resolved.
The question:
Are any app delegate methods called when the phone switches from 3G to 2G and vice-versa? Does the app momentarily lose it's active state and then regain it like it does in the above situation? The problem above seems to replicate exactly what my users are experience EXCEPT from the fact that I get the "no cellular data network" alert which obviously changes things a bit. They don't get this alert, but they still get the freeze.
Thanks
You might be able to track this using Reachability.
You can find it here.
I have a game that runs fine as is (around 30fps), but fps went down the drain when I tried to implement ads. I tried Greystripe and iAds but with same result (iAds were maybe bit worse). Average fps is almost same, but there are huge spikes all the times (1-2 spikes per second) and game is unplayable.
I guess it is because ad is in another view. I read somewhere that opengl apps on iphone don't like having another views with them, but there is plenty of games with ads on app store. How do they do it?
My implementation should be ok. I did everything as documentation and samples told me. I have my opengl view and ad view as subviews in app window, adview being in front of opengl view and thus covering part of it. Could this be the problem? Is it better to make opengl view smaller to left space for ad so they don't overlap? Do you have any other ideas what could be wrong?
Lope, I've created a gist at this link with a singleton "AdManager" class I wrote to handle iAds using cocos2d. Cocos2d sits on top of OpenGL, of course, and I've found that this code doesn't affect FPS even for relatively complicated games.
You'll have to modify this a bit to work with your application, changing out the cocos2d calls, etc, but this will give you asynchronous loading of iAds, which should help the FPS issue.
To use this class, include its header and call
[[AdManager sharedManager] attachAdToView:self.view];
wherever you need iAds. The ads will remain hidden until an ad loads, at which time they'll pop up at the top of screen. (The class works for iOS 4.0, 4.1 and 4.2).
Also, I should add that I have cocos2d running inside of an overall UIViewController that I call "Cocos2DController". When I attach the ads to a cocos2d view, I'm using
[[AdManager sharedManager] attachAdToView:[[CCDirector sharedDirector] openGLView]];
Best of luck!
We can hit and miss with apple's choices, but go for the sure thing and implement the ads in other parts to be appealing and not intrusive. It will be better for the framerate, and for you.
Try downloading the ads in a seperate, low priority, thread. You can, thus, nsure that the ads loading does not take too much CPU time. With a bit of CPU synchronisation you can make sure you don't try to display the new ad until it is completely ready to display. Sure it will suck some CPU time away from what you are trying to do but set your priorities right and it should only suck time when you are busy doing nothing.
Please excuse the thread necro'ing here, but I've used Stack Overflow a lot to help me through the problems I've had during coding, and thought my experience might be useful to someone in the future.
My simple cocos2d game ran with decent FPS (rarely changed the FPS display at all) until I implemented AdWhirl (integrating AdMob + iAd only). It would then run OK for the first few iterations, but upon upon the 9th or 10th scene refresh (single screen game, time in each scene < 5 seconds on average) the FPS would dive to ~20FPS, and drop again each time the scene refreshed.
Turns out, in my n00biness (this may be particular to me :) ), I was calling the scene from within itself. That is, once the actions had finished, the last action was to call the main scene again (a lazy way of rebuilding the scene for the user to have another go). This init'd the views and view controllers I had inserted to handle the AdWhirl ads all over again, and not only did I have a memory leak, I had 10+ view controllers all trying to request and service ads from AdWhirl. Once I got a clue and took that self-referring loop out, all was good.
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).