12

I'm writing an iOS game, using SpriteKit. At, apparently random, times during gameplay, the frame-rate will drop from 60 FPS to 40 FPS (always 40). I'm running this on an iPhone 6. The bug is present when building for release and debug.

I typically have around 30 nodes on screen at a time (sometimes less), most of those nodes have physics bodies, however, all but around 5 have dynamic set to NO. The aforementioned physics bodies do not collide with each other, however they do collide with the player node. The player node is not moving quickly, and usually is only touching around 5 or so nodes at a time. When the player node comes into contact with some of the other physics bodies, their dynamic property is set to YES. It might also be worth mentioning, that I have a couple of UIViews and UIImageViews overlaying the top of the SKView, acting as the HUD.

It strikes me that this is not a particularly intensive simulation. I have gone through my - update: methods, actions, contact listeners, etc. and not found anything that might be causing this. I've spent the last few days in Instruments (Time Profiler), hoping it might shed some light on the matter, but again, I've not found anything that jumps out at me. However, I'll admit to being quite new to Instruments.

Right now, I have no way of reproducing the bug. I just have to play the game, and hope to encounter it. Sometimes it will happen when the scene loads in (quite rare), just during normal gameplay, or not at all. If I pause the game (pause the view and scene), and resume it, the frame-rate goes back up. Sometimes the frame-rate will return to normal after several seconds. I'm completely at a loss of what to do here. Any help would be much appreciated.

Thanks in advance.

baxterma
  • 811
  • 1
  • 11
  • 22
  • Have you tried rebooting the phone, and running the app in release without the debugger connected? (unplug the cable) And try it without the UIView components for testing, as they might interfere, especially if you have a couple of them. – CodeSmile Dec 05 '14 at 15:55
  • @LearnCocos2D Hi, thanks for your suggestion. Before I try that, something I forgot to mention, I also have a couple of `UIButton`s overlaying the `SKView`. Should I remove those as well? – baxterma Dec 05 '14 at 16:33
  • 1
    Removing the UIKit items just as a test certainly doesn't hurt. The other thing you can do, just for "verification" is add some code to measure the intervals between updates. See how consistent they are. – Mobile Ben Dec 05 '14 at 17:33
  • One other question is how many textures do you have? Are you using texture atlases? How large are the textures? And what is the generalized draw order? – Mobile Ben Dec 05 '14 at 17:35
  • 1
    @MobileBen Hi Ben, just removed all UIKit items (including `UIButton`s). Don't want to speak too soon, but this appears to have fixed the problem. Will do some more testing (can't quite believe it :) ) and report back. Re. your second comment. I'm not using any textures. Could you explain what you mean by "generalised draw order?" – baxterma Dec 05 '14 at 17:37
  • 1
    If you are finding UIKit is problematic, then I would recommend seeing if you could find SpriteKit "equivalents". So for example, all my buttons are actually SpriteKit buttons that roughly act like UIKit buttons. – Mobile Ben Dec 05 '14 at 17:43
  • What I mean by generalized draw order is sort of what it sounds like. The order in which items are drawn in the tree. So depending on if you are not ignoring sibling draw order, the order is your node tree. This affects your distribution of textures which are needed to draw. Depending on the size of textures, the amount of diff textures, it can affect draw speed. However I suspect you may not have that issue if you are on an iPhone 6 with only 30 nodes. – Mobile Ben Dec 05 '14 at 17:44
  • 3
    The problem with UIViews is that they aren't "realtime friendly", some less so (UIScrollView) than others. For instance scrolling in a scroll view is known to freeze or drop fps of OpenGL views, or the other way round where the scroll view is "jumpy" due to OpenGL view using too much resources and CPU time (on the same thread). Depends on how the game loop is implemented. It may also make a difference if the UIViews are children of the SKView, or whether they are siblings (ie both having the UIWindow as parent view). – CodeSmile Dec 05 '14 at 17:51
  • @LearnCocos2D Didn't know any of that, thanks for the info. You suggestion about removing the `UIView`s seems to have done the trick. I've been testing it for about 30 minutes and I've not come across the problem. Thanks! If you'd like to put your suggestion into an answer, I'll gladly accept it. :) – baxterma Dec 05 '14 at 19:29
  • hey @baxterma, you solved it by removing UIKit import and all its stuff? for example, im not using anything of UIKit and still game drops the frames a lot too, down to 40-45.. and this is not only happening on my game but other games i've downloaded from the app store too... i even thought this was some sort of background service my iPhone is running.. because i don't see any bug on the simulators so far.. – msqar Aug 01 '16 at 21:16
  • Did you fix your issue? I have a similar issue, the FPS drops to exactly 40FPS: http://www.html5gamedevs.com/topic/24585-p2js-performance-on-ios-fps-drops-suddenly/?#comment-140604 but I use Phaser and Coocon – XCS Aug 19 '16 at 14:01
  • I had this problem too (40 fps on iPad). There was one HUD UIView (a timer) that was updating every frame. Just reducing its updates to once per second fixed the issue. – SlimeBaron Nov 28 '22 at 15:08

1 Answers1

0

The only thing I can think of for why you would have a massive frame rate drop is if all the textures for your HUD is not already pre-rendered. So you might have the initial HUD pre-rendered and some other images but some images the HUD uses when some event is triggered in game.

SierraMike
  • 1,539
  • 1
  • 11
  • 18
  • Hi Sean, thanks for your answer, but sadly I was having this problem long before I added the images in the HUD. – baxterma Dec 05 '14 at 15:43
  • Oh I did not know that. Let me try and think of some other possible issues. Do you execute any code in your update method that can vary in how long it will take to execute? – SierraMike Dec 05 '14 at 15:44
  • As you probably noticed in the comments above, things seem to be working now. Thanks for your help, though. – baxterma Dec 05 '14 at 19:33