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.
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.
Right now I'm developing application for iOs by Unity3D, and I have no idea what's happening with all my graphic. All textures are absolutely distorted and I've been struggling with this for a long time with no success.
I believe Unity compresses textures before convert the project to iOS, but I really can't find out how to change this setting or even knock it off. I appreciate any help from you guys. Here's the screenshot of my Texture Settings. I've setup it according to Ray Wenderlich lesson.
P.S.: I've tried to use "Point" for Filter Mode, but it had made the texture even worse.
I would suggest disabling mitmaps to see if this solves your problem, and making sure you have the best quality settings in Edit>Player Settings>Quality
As an aside, how large is your button image? You're overriding the max size to be 2048 for what seems to be a button. That sounds a little excessive.
By "distorted" you mean "blurred"? Try to uncheck "Generate Mip Maps".
I'm developing a simple kinetic menu UI component for AIR for iPad. It's basically a lightweight fill-in for a combobox that matches the style of iOS. I have a sprite containing any where from 2 to 60 item buttons that pops up and lets you flick/ scroll through them, only showing about 7 items at any given time.
My first attempt at this used a mask over my sprite, moving my menu sprite up and down under the stationary mask. This produced lackluster results on the test device (< 20 fps).
I then tried a blitting solution, leaving the menu sprite off the display list and using BitmapData.draw() to render only the part to the list i needed visible. This produced the best results on my Windows dev platform, but this time the framerate dropped below 10 fps on iPad. I am assuming I was incurring either a taxing CPU usage or a GPU readback penalty. Originally I had hoped to be able to run my app a 60 fps, however I've ratcheted my goal down to a more humble 30 fps.
Which brings me to my 3rd attempt at this UI component using the sprite's .scrollRect masking function in conjunction with .cacheAsBitmap . Again, the observed behaviors differ wildly between AIR on Windows vs. iOS. On Windows it only redraws the part of the menu sprite bounded by the dimensions of the scrollRect as it should. With iOS i can touch the area of the screen above or below the visible area of the menu sprite and still drag the menu even though my finger is over "empty" space! The performance here is decent, hovering between (19 - 25 fps) and would almost certainly be perfect at 30 if it worked as it did on windows.
Does anyone have any ideas either about the scrollRect feature's behavior on AIR for iOS or a better way of implementing an iOS native style gliding menu in AIR for iOS?
Note, the above methods were tried in both CPU and GPU mode, but CPU mode performed vastly better. I used AIR 2.7 installed on top of Flash Pro CS 5.5, with FlashDevelop as my IDE.
http://esdot.ca/site/2011/fast-rendering-in-air-3-0-ios-android#comment-10
Really nice guy from the above link: "Ya, scrollRect is basically a no-go on mobile, basically forget that API even exists. Believe it or not… old school masking is the way to go. Round and round we go!"
It looks like when I shoot video with UIImagePickerControllerQualityTypeMedium, on an iPod Touch it comes out 480x360, but on an iPhone 4 it's something higher (can't say just what as I don't have one handy at the moment) and on an iPad 2 presumably the same as the 4, if not something different again.
I'd like to shoot the same quality on all devices -- I have to add some frames and titles, and it'll make my life a lot easier if I just have to code that for one resolution. Is there any way to determine what the different UIImagePickerControllerQualityType values correspond to at run time? (Apart from shooting video with each and then examining the result, that is.)
Or is my only choice to use UIImagePickerControllerQualityType640x480?
If you need more customization/power on iOS than you get wish the higher level objects, such as UIImagePickerController, it is recommended to work at the next lower level: AV Foundation Framework. Apple has some excellent documentation on AV Foundation programming that should come in handy for that purpose.
Unfortunately, even there you are limited to capturing at 640x480 if you do want it standard across all devices. There, however, is a great chart available at the same link (but anchors are broken in the docs, so Ctrl+F to "Capturing Still Images") that lists all the resolutions for various devices under certain quality directives.
Your most solid bet, assuming 640x480 is too small, is to work out some sort of scaling algorithm that would allow you to scale according to the overall resolution.
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.