I'm almost finishing my iOS game written in Swift + SpriteKit.
It's a quite simple game, 30-32 nodes at max. Only 1 thing has physics. The rest is a few animated clouds (around 6). The CPU usage is around 2-3% and max RAM usage of 75-80MB.
Including that I also get frame drops when changing from one scene to another. Why that could be?
(I'm pre-loading all the textures and sounds during game init, and not on the scenes)
When I use the simulator for 5S up to 6S Plus, I don't see any frame drop in there. So that's weird. Looks like it's not my game but my iPhone 6S?
Now, I do also have other games installed on the same device from different developers, and I frequently get random frame drops too. Lags for 2-3 seconds and then comes back to 60fps.
Does anyone know if this is something that's happening after an X iOS update ? or I was even thinking this my be some kind of background service running that's killing my phone. Call it facebook, whatsapp, messenger, etc.
Is there any way I could possibly check on what's going on?
Was this caused by the way that newer versions of SpriteKit are defaulting to Metal render mode as compared to OpenGL mode? For example, do your problems go away when PrefersOpenGL=YES is added to Info.plist? I covered a bit of this performance issue in my blog post about a SpriteKit repeat shader. Note that you should only be testing on an actual iOS device, not the simulator.
Related
In our AR app and appclip made with SceneKit, we experience very significant drops in framerate when we make our 3D content appear at different steps of the experience. We have conducted our tests on an iPhone X (iOS 15.2.1), on an iPhone 12 Pro (iOS 14), and on an iPad Pro 2020 (iPad OS 14.8.1).
For now, all of our 3D objects are in our Main Scene. Those which are supposed to appear at some point in the experience have their opacity set to 0.01 at the beginning and then fade in with a SCNAction (the reason why we tried setting their opacity to 0.01 at the start was to make sure that these objects are rendered from the start of the experience).
However, if the objects all have their opacity set to 1 from the start of the experience, we do not experience any fps drop.
It is worth noting that the fps drops only happen the first time the app is opened. If I close it and re-open it, then it unfolds without any freeze.
What would be the best way to load (or pre-load) these 3D elements to avoid these freezes?
I have been told the prepareObject:shouldAbortBlock: and the prepareObjects:withCompletionHandler methods could solve our problem.
In our case the SceneView is an ARCNView, so we can't seem to access the SCNSceneRenderer methods. We have only managed to implement the "Prepare" method to preload our assets:
https://developer.apple.com/documentation/scenekit/scnscenerenderer/1523375-prepare
It seems to be doing something because we get a significantly longer freeze at the start of the experience, however, we still experience the same fps drops during the experience when our objects appear for the first time.
Is there any documentation on how to use the prepareObject:shouldAbortBlock: and the prepareObjects:withCompletionHandler methods in an ARCNView?
I recently create a small puzzle game in Unity, just a simple one, not fancy effect or anything. It really smooth when I test run on Unity.
FPS normally cap at 200 and on the largest resolution its around 80 - 120 FPS - super smooth. After that, I build an iOS version and test on ios device, it's quite laggy. I tested on iPhone 6+, iPhone X, iPad 9.5 inches, and the outcome still the same, its a little bit lag. Maybe be I need to adjust some graphics settings on Unity ? Please I need some advice from you guys. Thanks for reading.
You can try a few things.
At the very beginning of your app, keep a target frame rate to 30.
Application.targetFrameRate = 30;
Downgrade quality settings to medium. Within that, also disable or dull down things related to lighting in case yours is a simple 2D game.
Optimize art. Pack art in packing tags, and on iOS, keep their compression at PVRTC. Only the ones looking really bad after compression should be RGB24 or RGBA32. Disable options like Generate Physics shape(if you're not using that), and Generate mipmaps.
Have a look at your UI. Anything in UI that is not interactive(like simple images, or texts, which are not buttons or input texts, etc) should have Raycasting off. The Rich Text option in texts too should be off if that is not affecting your app specifically.
In my app, I have several simple scenes (a single 80 segment sphere with a 500px by 1000px texture, rotating once a minute) displaying at once. When I open the app, everything goes smoothly. I get constant 120fps with less than 50mb of memory usage and around 30% cpu usage.
However, if I minimize the app and come back to it a minute later, or just stop interacting with the app for a while, the scenes all lag terribly and get around 4 fps, despite Xcode reporting 30fps, normal memory usage, and super low (~3%) cpu usage.
I get this behavior when testing on a real iPhone 7 iOS 10.3.1, and I'm not sure if this behavior exists on other devices or the emulator.
Here is a sample project I pulled together to demonstrate this issue. (link here) Am I doing something wrong here? How can I make the scenes wake up and resume using as much cpu as they need to maintain good fps?
I won't probably answer the question you've asked directly, but can give you some points to think about.
I launched you demo app on my iPod 6-th gen (64-bit), iOS 10.3.1 and it lags from the very beginning up to about a minute with FPS 2-3. Then after some time it starts to spin smoothly. The same after going background-foreground. It can be explained with some caching of textures.
I resized one of the SCNView's so that it fits the screen, other views stayed behind. Set v4.showsStatistics = true
And here what I got
as you can see Metal flush takes about 18.3 ms for one frame and its only for one SCNView.
According to this answer on Stackoverflow
So, if my interpretation is correct, that would mean that "Metal
flush" measures the time the CPU spends waiting on video memory to
free up so it can push more data and request operations to the GPU.
So we might suspect that problem is in 4 different SCNViews working with GPU simultaneously.
Let's check it. Comparing to the 2-nd point, I've deleted 3 SCNViews behind and put 3 planets from those views to the front one. So that one SCNView has 4 planets at once. And here is the screenshot
and as you can see Metal flush takes up to 5 ms and its from the beginning and everything goes smoothly. Also you may notice that amount of triangles (top right icon) is four times as many as what we can see on the first screenshot.
To sum up, just try to combine all SCNNodes on one SCNView and possibly you'll get a speed up.
So, I finally figured out a partially functional solution, even though its not what I thought it would be.
The first thing I tried was to keep all the nodes in a single global scene as suggested by Sander's answer and set the delegate on one of the SCNViews as suggested in the second answer to this question. Maybe this used to work or it worked in a different context, but it didn't work for me.
How Sander ended up helping me was the use of the performance statistics, which I didn't know existed. I enabled them for one of my scenes, and something stood out to me about performance:
In the first few seconds of running, before the app gets dramatic frame drops, the performance display read 240fps. "Why was this?", I thought. Who would need 240 fps on a mobile phone with a 60hz display, especially when the SceneKit default is 60. Then it hit me: 60 * 4 = 240.
What I guess was happening is that each update in a single scene triggered a "metal flush", meaning that each scene was being flushed 240 times per second. I would guess that this fills the gpu buffer (or memory? I have no idea) slowly, and eventually SceneKit needs to start clearing it out, and 240 fps across 4 views is simply too much for it to keep up with. (which explains why it initially gets good performance before dropping completely.).
My solution (and this is why I said "partial solution"), was to set the preferedFramesPerSecond for each SceneView to 15, for a total of 60 (I can also get away with 30 on my phone, but I'm not sure if this holds up on weaker devices). Unfortunately 15fps is noticeably choppy, but way better than the terrible performance I was getting originally.
Maybe in the future Apple will enable unique refreshes per SceneView.
TL;DR: set preferredFramesPerSecond to sum to 60 over all of your SceneViews.
I've been encountering some problems when testing my app from XCode to my iOS 6.1.6 iPod touch 32GB. For my game, images frequently fall and I am not sure if that is the problem. Someone told me that my app could be running slow because I have too much memory on my iPod, but I already cleared most of my memory.
My question is, how can I make my app run fast on my device?
It runs really smooth on my iOS Simulator but it's terrible after 5 seconds when tested on my device.
The code that makes my images fall is like this
imageView1.center = CGPointMake(imageView1.center.x+pos.x,imageView1.center.y+pos.y);
imageView2.center = CGPointMake(imageView2.center.x+pos.x,imageView2.center.y+pos.y);
imageView3.center = CGPointMake(imageView3.center.x+pos.x,imageView3.center.y+pos.y);
imageView4.center = CGPointMake(imageView4.center.x+pos.x,imageView4.center.y+pos.y);
pos = CGPointMake(0.0, 3.0);
I also have a timer set at 0.03.
Also, when every image falls, when it hits the bottom, a new image is made out of random. It's a loop.
Any UIKit operations frequently occur take a load on your iPods processor. Your mac CPU is so much faster and you've got a ton of more ram so that's why it works on the simulator. You could try reducing the frame rate (the timer interval) and see if that solves the problem. I'd suggest you stay away from UIKit for making games and instead use the new iOS 7 framework, SpriteKit. (A google search will find the documentation) Frameworks like SpriteKit or Cocos2d are slightly more difficult to learn, but they have engines optimized for running games and using your iPods gpu. How complex is your game? If it's more than just one screen with moving objects I'd consider rewriting the entire thing in SpriteKit. Sorry to let you down on your first game but UIKit is nearly never the way to go when making games. Good luck!
I am building a cocos2d continuous running ios game, where a character is animated to run through a scene. The background, the grounds under the character's feet and a fence behind the running character move in the opposite direction to simulate forward motion. The character itself is animated to run in place. Occasionally additional sprites move by in the scene.
All my movement (except the in place animation of the character) happens in the update method.
I notice that all the moving parts stutter when additional sprites are moving past the scene. When there are no additional sprites, the stutter goes away.
I also notice that the stutter is almost imperceptible in the ipad 3 (ios 6.0.1), whereas it is most noticeable in the iphone 3gs (ios 6.0.1) and ipad 1 (ios 5.1.1), and moderately noticeable on the iphone 4 (ios 6.0.1).
I have no idea where to begin to address this - I tried removing the actual rendering of the additional sprites, and I also tried removing the fence behind the character - but neither change had any impact on the stutter.
Any suggestions?
Update: fixed it by running time profiler as #Fogmeister suggested below. Turns out I was doing disk i/o on every update to look up some state variables. I optimized that away and the stutter is gone on all devices. Thanks!
You need to identify what is taking up the time in the code and causing the stutter.
It seems like it is just an optimisation issue as you can see more stutter on older, slower devices and less on new more powerful devices.
Analyse the app using the Time Profiler instrument. This will tell you where the time is being spent and point you almost instantly to the function (if not the line) that is taking the time.
Once you've found that you can start optimising.
What is your code for the movement of the sprites? If you are updating the positions manually in the -(void) update:(ccTime) delta {} method make sure you are multiplying each movement by delta to account for any minute framerate fluctuations.