I’m a few weeks fresh into developing for the iPhone using Unity, and I must say I am very impressed with what the engine can do. I’ve also been reading and following discussions on optimization techniques and that sort of stuff, however, I could not find one that specifically outlines what one should (and shouldn’t) do when creating a game hud for the iPhone.
I was able to find a couple of threads that suggested not using UnityGUI, but I need concrete answers as to why this should be the case. Some of the more simpler questions that I have in mind are:
Would having more than one camera affect the general performance of my game? One camera used for gameplay, and one for displaying the hud.
Is there a huge benefit if one creates GUITextures for the HUD elements when compared to building them programmatically in scripts (e.g. using GUI.Label() in the Lerpz tutorial)?
There’s really no other way to display GUI stuff without putting them inside the OnGUI function is there?
GUITextures are not related to the other Unity GUI components and do not need to be drawn in OnGUI. And yes there is a huge benefit in using GUITextures (which can be done in script or in editor) as opposed to GUI.Label or other GUI components.
More than one camera will affect performance, but in quite doable in many situations.
I have been using Sprite Manager 2, and EZ GUI together to make super cool animated interfaces, and all with 1 draw call. Careful planning is the key, but it is easily doable with one draw call.
I see, knowing that I can implement GUITextures without going thru OnGUI is good info, thanks JohnnyA.
@jingato and melmonkey funny I came across that same thread just a few minutes ago and there is no doubt (based on testimonials) that EZ GUI is one heck of a good chance to have a smooth implem of my GUI. Only problem is, I don’t have the resources to purchase it :))
Once I do though, it’s an easy buy for me. Kudos to the creator of that slick piece of middleware! (Brady was it?)
Initially I used OnGUI in my game, but changed to using GUIText and GUITextures and saw a decent improvement in frame rate. Also only update your GUI information when needed rather than every frame, unless of course you have something that is constantly variable.
You can use GUI.DrawTexture rather than GUI.Label which is probably(?) equivalent to using GUITextures outside of OnGUI as there is no styling involved. I find this makes the code neat/simple, but I have done no speed tests…
you can also make your complete gui in cocoa, in case you know about xcode and obj c.
That way, your app most likly will be a lot smaller, because you don´t need to use big textures. Just hook in jpgs or png and you are fine. That also makes it easier to handle rotation of the screen and the retina display.
Only thing you should not do is have a gui element there that sends or recieves something to or from unity per frame. think of a virtual joystick constantly sending coordinates.
In case you know nothing about xcode, it´s obviously a hard task.