Similar Topics:
http://www.tasharen.com/forum/index.php?topic=8780http://www.tasharen.com/forum/index.php?topic=7101http://www.tasharen.com/forum/index.php?topic=8067http://www.tasharen.com/forum/index.php?topic=10221http://www.tasharen.com/forum/index.php?topic=8103I have used NGUI in a few projects over the years and am just looking for some feedback on a particular high-level approach to dynamically loading UI elements.
Our core foundation is using StrangeIoC and we have recently upgraded to NGUI 3.6.9
Our Situation:
A. We currently spawn all the UI and GameObjects into the scene as we need them. Although we would like to have all our UI built in the scene already, to make it easier for our artists and designers, we do not do this as to avoid scene conflicts.
B. Some of us are used to using UIAnchor and UIStretch which have the default behavior of using the UICamera if a target is not explicitly set, this comes in handy with the dynamically loaded UI. The new Anchor system makes sense for UI prefabs that have elements which they can anchor to, but does not for prefab elements that need to be anchored to the screen because it is not intended for that type of behavior (i.e. default camera anchoring).
C. In some instances we have a panel at the top of the prefab which we do not give dimensions and anchor the child elements to the panel if it should be tied to the screen. But this is not ideal because more panels means more draw calls.
Possible Solutions
1. Continue using UIAnchor and UIStretch despite the warning. This is not the best solution for two reasons, we understand that it is using a different anchoring system from the new one provided essentially having the functionality in two spots, and we don't know when support for it will actually be dropped.
2. Make a custom script which sets the Anchors in code, but this will just add another component that our artists would need to input the same values too as well as having to pretty much replicate the editor ui for anchoring if we want to keep the WYSIWYG experience of editing screen anchors.
3. Bring all our UI into the Scene where we can explicitly hook up all the anchors to any reference and deal with scene conflicts as they occur. Kind of resilient based on the floating point scene changes that can occur with anchoring.
Random:
I also found that anchoring in a manner similar to stretch to fill a screen using Unified Anchors results in a column of blank pixels on the right side, I have to add 1 to the right side to get rid of it.
Any feedback on any aspect of this from anyone would be appreciated.
Thanks
