How does someone check if an Apple device is suitable for playing a game a developed. I realised that in some cases, the devices that are 3 years old have too humble performance and my games have a lag because of that. Is there a test I can run to determine if my app can be played on for example iPad3 or iphone 5.
The only way to tell is to run it on that device. Apple has made a few of these options better by allowing you to test things with Xcode server, unfortunately most of the time it has to be done manually.
It's also worth noting that you could optimize for older devices by making changes to the game such as lowering textures, particle effects, shaders and more.
Related
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.
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!
Currently I am working on an Air app for iOS and Android. Air 3.5 is targeted.
Performance on iPhone 4 / 4s has been acceptable overall, after a lot of optimising: gpu rendering, StageQuality.LOW, avoiding vectors as much as possible etc. I really put a lot of effort in boosting performance.
Still, every once in a while, the app becomes very slow. There is no precise point in time or action or combination of actions after which this occurs. Sometimes, it doesn't occur for days. But when it occurs, only killing the app and launching it again helps, because the app stays slow after that. So I am not talking about minor hiccups that
The problem occurs only on (some) iPhones 4 and 4s. Not on iPad 3,4, iPhone 5, any Android device...
Has anyone had similar experiences and pointers as to where a solution might be found?
What happens when gpu memory fills up? Or device memory? Could this be involved?
Please don't expect Adobe Air to have performance as Native Apps. I am developing App with Adobe Air as well.
By the sound of your development experience. I think it's to do with memory issue, because the performance is not too bad at the begging stage, but it gets bad overtime (so u have to kill the app). I suggest you looking into memory leaking issue.
Hopefully my experience can help you.
I had a similar problem where sometime during gameplay the framerate would drop from 30fps to an unrecoverable 12fps. At first I thought I was running out of GPU memory and it was falling back on rendering with CPU.
Using Adobe Scout I found that when this occurred, the rendering time was ridiculousness high.
Updating to Air 3.8, I fixed the problem by limiting the amount of bitmaps that were being rendered and in memory at once. I would only create new instances of backgrounds for appropriate levels, and then flagging them for garbage collection when the level ended, waiting a few seconds and then moving to the next level.
What might solve your problem is if you reduce the amount of textures you have in memory at one time, only showing the ones you need to. If you want to swap out active textures for new ones, set all the objects with that texture data to null:
testMovieClip = null;
and remove all listeners from it so that garbage collection will pick it up.
Next, you can force garbage collection with AIR:
System.gc();
Instantiate the new texture you want to render a few frames after calling gc. Monitor resources with Scout and the iOS companion app to confirm that it's working.
You could also try to detect when the framerate drops, and set some objects to null then force garbage collection. In my case, if I moved my game to an empty frame for a few seconds with garbage collection, the framerate would recover and the game would resume rendering with GPU.
Hope this helps!
iPad simulator is too slow to test OpenGL graphics. Is there any way to make it faster?
In my experience, the iPad Simulator has almost always been faster than running on an actual device. On my early 2010 i7 MacBook Pro, the Simulator has been significantly faster than the iPhone 4 and iPad 1 with almost every OpenGL ES application I've developed.
The Simulator does appear to do software-based simulation of certain iOS hardware features, particularly in the area of shaders. If you have a shader-heavy OpenGL ES 2.0 application, you can see a significant drop-off in performance when running in the Simulator.
In particular, the Simulator can't match the rendering speed of the iPad 2 when it comes to fill-rate-limited OpenGL ES applications, because the iPad 2 has a GPU that excels at this.
Beyond telling you to buy a faster computer, there's nothing that can be done to speed up the Simulator. As long as it has to simulate certain operations in software, you're going to get a little slower performance when doing certain types of rendering when compared to the very latest iOS devices. You're welcome to file an enhancement request at http://bugreport.apple.com to ask for performance improvements, but I don't know how much better the team at Apple can make this. They seem fairly conscious of performance issues from what I've seen.
As always, the Simulator should be used to test if something works at all, and all actual fine-tuning and anything else performance related should be done on actual hardware. I've found that the build-install-test cycle on the iPad 2 was almost as fast as dealing with the Simulator when I was developing my last application.
A few days ago a client asked me if the transition to the iPhone 4s retina display was a difficult one, development-wise.
This made me ask myself whether I should have considered iPhones with high resolution dispays even before the iPhone 4 had been announced - creating artwork with higher resolution, preparing codepaths... (while, of course, creating high resolution artwork is never a bad idea, considering its use for marketing, porting to other platforms etc.)
Now, with the iPad being around for some months, first rumors of a future iPad with retina display emerge from the depths of the www. And I start wondering - would it make sense to prepare new projects for such an iPad? I'm pretty sure that apple will in fact release a retina iPad at some point in the future, because it would be quite a logical step. So, I guess the important question is "how soon can we expect such a device?". There is much to consider when thinking about that, most of all production difficulties and the impact of a resolution of 2048 x 1536 (if apple sticks to simply doubling the "old" specs) on a mobile devices performance...
So, what do you think? Will it pay up to prepare new projects for a retina iPad, starting now? Or do you think the overhead is not worth it, yet?
Maybe some of you are already developing with the retina iPad in mind..?
I'd be glad to hear some of your thoughts! Thanks alot, guys!
Edit:
Well, Apple just answered my question. Yes, it was in fact reasonable to consider a Retina iPad..!
I wouldn't spend too much time making your app work on a theoretical device. But that doesn't mean you can't be prepared. Ever since they started changing things around I've been considering the following:
Use vector art wherever practical. That way resizing should be simple
Don't assume that the screen is 768x1024 or 320x480. Try to make your views gracefully resize
Don't assume that there will be an on-screen keyboard
So far Apple have allowed time between announcing products and making them available, and even there un-optimised apps have still worked.
Most of my work is for a client who has their own designer, who provides me with layered Photoshop files to pick image elements out of. I now have a policy with them that ALL images will be provided to me at double resolution. I don't care if it's just text, if it's only going to be on the iPad, I want it at 2x no matter what.
That takes a lot of thinking and judgement out of the hands of the designer (who's a good designer but not a particularly good technician or strategist), and allows me maximum flexibility in what I'm building.
Right now, I don't think I'd build #2x support into an iPad app just now (although presumably 4.2 will allow you to do it and have it downgrade nicely, just like 4.1 does), but I have the graphics here ready to install when needed.
A few of Apple's apps (such as iBooks) have already been seen in the wild with #2x iPad graphical elements (mistakingly?) left in, so it is clear that a retina iPad is coming as soon as it is practical for Apple to affordably include such an incredibly hires panel.
It might be later this year, it might be a year from now, or it might be two years from now.
It doesn't hurt at all to prepare now though. It is easy to downres graphics, but it is often impossible to upres graphical elements without redoing them from scratch.
So short answer - do everything in #2x resolution now, but wait to include it with your app until the time is right. When Apple issues the call for retina iPad apps, you'll be ready to go and able to be featured on day #1.
I'm going to agree with the others. I'll go out on a limb and say I think it is highly likely that a Retina iPad will have 2x horizontal and vertical resolution compared to the current iPad screen, just like the did with the iPhone, because it is such a freaking clever idea in terms of the relative ease of support of the new resolution for developers, the backwards compatibility with apps that have not been updated, and it also gives Apple a mechanism for preventing developers from making a I'll-cram-in-more-UI-on-the-high-resolution-version interface...
So absolutely, planning ahead for this is a good idea. That said, the ideal would be to plan for full resolution independence where possible, using vector artwork and so on so you can re-export at new resolutions with minimum hassle.