Author Topic: Moving back to NGUI - Unity Sprite Support  (Read 2229 times)

ferretnt

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 23
    • View Profile
Moving back to NGUI - Unity Sprite Support
« on: October 13, 2017, 05:07:24 PM »
After 18 months of using Unity UI, we are strongly considering reverting to NGUI for our next app. We do relatively complex app layout (nested panels, etc as opposed to just game menus) and Unity UI seems to be a broken minefield of undocumented scrollview and autolayout nastiness, augmented by a bunch of half arsed community scripts on unity forums by people who really don't understand what they're doing.

The only thing about Unity UI we like is the sprite atlas system (just rect sprites are fine, but we like the flexibility of Unity's texture format choices when packing for optimization, rather than trying to manually create e.g. PVRTC, 16-bit and 32-bit atlases.) We also like the intuitive-ness of using the hierarchy to control sprite draw order. Is it now possible to use Unity Sprites throughout your NGUI widgets and use the hierarchy to manage depth, or is this not advised?

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Moving back to NGUI - Unity Sprite Support
« Reply #1 on: October 19, 2017, 02:22:24 AM »
You can use UI2DSprite components, which draw Unity sprites using NGUI's backend. As for the hierarchy controlling depth... the historical reason why NGUI didn't do this dates back to Unity 3 days when hierarchy wasn't adjustable via code in an expected fashion. Plus, hierarchy-based approach would be quite a bit slower if I was to add support for it to NGUI. I personally organize everything by panels: one panel per window. Inventory window gets its own panel, character stat sheet gets another panel, quest log gets another panel etc. I also use a window manager that automatically shows/hides windows one at a time (mostly the same one as Starlink UI kit's). In situations where I need to have multiple windows open, such as inventory / trade windows, having them each on their own panel means I can easily bring something to the front by clicking on it by adjusting its panel's depth, which is a single value. Seems easier than changing the hierarchy, code wise. The hierarchy approach looks like a good approach if you're designing everything in the editor, but it's less convenient when working with code.