Wondering if the app launch (load) time was dependent on how much “stuff” i had in the initial scene? If so is it common to have an initial barebones scene like a game menu or something? I am asking this because the app launch time (time between icon touch and app screen loaded) is around 20-30 seconds which is way slow. Another problem I have with this load time is that the device becomes unresponsive to the home button when it is initially launching. This seems like an awfully long time to hijack someone’s phone/ipod.
I am currently using ‘indie’ version and I suppose the ‘pro’ version somehow fires up quicker?
I think the core problem is my initial scene is too populated with objects and that is adding to the overall launch time. Wondering if anyone else was using a ‘menu’ or initial load scene that solves this.
You will get some load time reduction in Advanced produced apps if you use build size stripping (as less engine code needs loading), and I do believe that a trimmed first scene should help too.
Wow 8 seconds for a barebones scene? That’s an awfully long time to hijack someone’s phone, definitely pushing the threshold to return the phone to a usable state in time to miss a call. I’m not trying to imply anything about user discretion or expectations wrt to calls or other aspects of the device, I’m just saying 8 seconds is a long time to load a barebones scene.
Do we have any benchmarks on the pro version and how much time that version shaves off the load time??
We always load a splash scene with a skybox, a single game logo (GUITexture), and an mp3 music loop. The Default.PNG usually appears on-screen for about 3-4 seconds before the splash scene takes over. This is using pro with the build size stripping.
8 seconds is easy. The majority of the games you find on iphone have at least 4+s before you can do anything again, I’ve several games with 10-15 seconds till they respond initially (to the home button)
you are definitely breaking your head to much there
That’s quite a difference between the indie and pro versions, we’re talking 50% reduction in launch time. Obviously there’s a lot of overhead in the indie version.
I appreciate the fanboy response but anything over 4 seconds seems unacceptable to me. Let’s forget about what is ‘common practice’ as it is also common practice to release half-baked apps. If you notice users are happy to reciprocate with a bad review and I see a lot of complaints posted in the reviews about performance. My app download numbers may suck but I never got less than a 4 star review and I would love to keep it that way.
Any iPhone app – any app at all – has this load time issue. Contacts, Safari, whatever. That’s why the Default.png file is loaded by the OS, to cover the load times. And that’s why some iPhone developers have tried to generate Default.png files at runtime, like Contacts does, to make the app seem to be loaded, when it’s actually not.
In the enhancement pack I made, you can load a second splash screen, which happens before the engine is initialized. This happens as soon as the app is done launching. I was surprised by how short the second splash screen was actually up for my test app – but my test app has very few assets to load.
I totally understand the purpose of default.png but pretty much any apple app has a loading time (time between when default.png is shown and applicationDidFinishLaunching delegate is invoked is 2 seconds or less.
I did some side by side comparisons with Unity and SiO2 and I’m seeing about 20 seconds on my 2G phone (big initial scene) before default.png is released and a simple SiO2 scene takes about 2 seconds or less to release default.png. I think there is some room for improvement here.
When default.png is visible the device does not respond to the home button and suspends user input. This time should be minimized because the device is unusable during this time meaning that asynchronous operations such as phone calls would not be user-enabled until applicationDidFinishLaunching is invoked.[/b]
The home button is frozen out during the engine initialization. The engine is initialized inside appDidFinishLaunching: so the app’s runloop never begins, so the app never has a chance to catch the button press.
Have you tried making a first level that is basically empty, and have that level load another level that has your content? That might get the Home button working.
Also, you can move the engine initialization after appDidFinishLaunching: (like I did in the enhancement pack) by moving it to its own method and calling it with performSelector:afterDelay: with a very short delay. That gives the runloop a chance to get started, which lets the app catch events, so the home button will work before the entire Unity app is loaded.
I fear you will have to work with sources directly if you are worried about this issue that you start to compare apples with stones.
If you need short loading times you won’t be able to avoid to roll your own technology which does exactly what you need and when you need it and not the smallest bit more to avoid any unneeded initialization and handling. Especially one that does not have that many different libraries which are all loaded at init.
But with your given loading time I would first recommend that you retarget your project realistically. You are developing for a phone, not for a computer, so skip the idea of large complex scenes with masses of polygons and especially masses of textures unless you start to accept the related loading times as well.
I would guess that you made a far too large scene and forgot about the fact that levels are loaded at once.
If this is the case and you want shorter loading times, make friends with loadleveladditive and GarbageCollectUnusedAssets.
The only optimization Unity right now is missing is automagic asyncronous load of scene parts but thats exactly what above “be friends with” commands are for.
And this has very little to do with fanboy stuff but with the fact that you claim something here without the slightest proof. Your 30s loading time actually is more of a proof that your scene is serious trash when it comes to target platform oriented design.
I agree with everything you said but especially what’s quoted above. Also got some meaty technical info (finally) which is what I was looking for. I would like to see Unity really pushing the performance thing to the top of the priority list and especially for the indie version, why should you burn your smallest customers by passing poor performance onto their users?
I think all this has made me realize that I am just not happy with nor will I be happy with the performance of Unity, granted I haven’t seen the performance difference between the Pro and Indie versions but I have seen enough. Also realized I approached this whole thing from a place of fear that it would be too difficult to use a bare metal framework like SiO2 but I realized that’s exactly what I need because it’s all about the game requirements and no more as you said. Game performance just doesn’t come cheap on this small device and every additive resource or feature should be considered carefully. Thanks for the advice.
In my experience, if the app is taking that long (20+ seconds) to load it is because you have big uncompressed audio files being loaded (like >5MB) If that’s the case, then you (or more likely your customers) may also experience a problem with Unity crashing due to low memory conditions. … just something to consider.
there is no performance difference between Basic and Advance
both have the same renderer, the same occlusion culling
the loading time difference comes due to the stripping which removes libraries that are not needed. Library not present → iPhone OS will not need to load the library
Without stripping that can’t be reduced without removing further language capabilities for the basic users. a good 8MB of library just needs its time to be loaded and that is not avoidable as those 8MB is the .NET core which is required to run any scripting at all
Stripping is one of the strong reasons to upgrade the Basic license to Advanced
I have a single scene app that consists solely of 1 texture.
This texture is written to the screen using GUI.DrawTexture, followed by a GUI.TextInput for input, a GUI.Label for output, a GUIButton for Calculate and a GUI.Button for Quit (which obviously does nothing in iPhone)…
Anyways, this is my entire app… no music, 1 Texture (way bigger than the iphone’s screen at 640x480 as it was a straight port from Windows App) and that is it… Takes exactly 18 seconds to load…
Of course in general, like with every possible improvement, it would be cool if app launch times could be improved in an unity iphone update.
Besides that, what the others said is right:
-Empty initial scene helps with keeping noticable load times shorter
-stripping feature of advanced license helps some,too
-iphone enhancment pack second splash screen display makes it feel a bit shorter
-anything that takes long to process on iphone will of course also have negative impact on load times.
This is in particular very obviously noticable for big mp3s and big (especially uncompressed) images.
That brings me to this post:
I think (one of) your problem(s) is that you´re maybe using non square non power of two textures.
Unity iphone gives wrong feedback for a certain combination of these where it tells you its fine but in reality the graphic then ends up non compressed on the iphone which leads to massive load times for big graphics (next to common crashing problems because too many ressources are used).
Besides all this:
-Earlier i was doing a multi scene setup, so having a pretty empty first scene, then titlescreen menu etc scenes. This kept my initial load times shorter but lead to other downsides, like:
-There are load times between each scene
-When having a constantly playing bg music and switching scenes the music stutters for several seconds which feels very buggy
-Other things like transitions can stutter for a noticable while,too when switching from one big scene to another
-In the current release version unity iphone still has some memory leak issues which are made more obvious when one often changes scenes and things in some cases don´t get removed
Overall these and some other reasons made me meanwhile switch to a single scene setup where i handle switching between virtual scenes myself (enabling/disabling stuff etc). The initial load time is a bit longer but in return there very short-not noticable at all “load times” now throughout the rest of the game and music/game display doesn´t get stuck when switching between menus/gameplay etc.
So bottom line is i think its of course good to keep load times short but also consider which things are more important to you, shorter initial load time or smoother playback and switching around during the game.
interesting question:
My other app has a “default” plash screen, a game over splash screen, a “please buy the full version” splash screen, a “button config” splash screen, 5 gameplay info splash screens and a high scores splash screen…
All of these are 480x320 (since the game only runs in horizontal mode).
All of these load onto a cube which is setup to perfectly fit the screen. Now 480x320 is NOT powers of two. Am I to understand that making all my splash screens 256x256 and stretching them to fit (contains fonts, mind you… stretched fonts…) or (more likely to use) 518x518 would actually decrease my loading times even though they are larger than the actual max resolution of the iPhone???
Using square power of two dimensioned textures (even if those are bigger dimensioned than non square non power of two textures) will drastically reduce your ressource usage, cause one is compressed and the other not, one can be used in compressed form by the iphone hardware and the other not.
erm. no
Its not larger=smaller
Its about which is larger, the compressed or not compressed one.
And its about which one can be used compressed and which one not. And if a graphic can´t be used in compressed form cause it isn´t available in the form the iPhone hardware needs it, then yes, its used in uncompressed form and that is massively bigger in filesize.
