Author Topic: Feature request: More generalised UIStretch  (Read 3754 times)

electrodruid

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 48
    • View Profile
Feature request: More generalised UIStretch
« on: March 12, 2013, 10:39:54 AM »
... Or, possibly, just a bit more control over a UIDraggablePanel? I think the former would give more flexibility, but whatever works best.

UIStretch does a good job of stretching transforms to proportions of the screen size, but it's not really enough when you're dealing with different aspect ratios and resolutions. For my current project, I've had to copy/paste and adapt UIStretch to create several new but very similar components:

  • UIAspectStretch - to stretch widgets (particularly non-sliced sprites) whilst maintaining their original aspect ratio (because using UIStretch alone, a sprite that looks normal on an iPhone will look squashed on an iPad because of the different aspect ratios)
  • UIPixelStretch - Like UIStretch but with an additional pixel component in addition to relativeSize, so you can say "I want this to be 0.75 of the screen width, minus 20 pixels". Again, this allows for more precise layouts when building something to run in different aspect ratios, by making the horizontal and vertical gaps between things always be consistent
  • UIPanelStretch - changes a UIPanel's clipping region, rather than an object's Transform. This is essential if you want to have a UIDraggablePanel that's clipped to some proportion of the screen size rather than an absolute amount
  • UIGridStretch - Also for UIDraggablePanels, but for any use of grids in which the grid elements are scaled: Changes the grid spacing depending on the size of some scaled widget, and updates the grid positioning. Means that if you have a grid of things on (say) an iPad2, and you stretch them to be the same relative size on an iPad3, the grid doesn't leave them overlapping but spreads them out properly
  • UIColliderStretch - Again, made necessary by having a scaled UIDraggablePanel. Scales the BoxCollider for an object to keep all the collision working properly

None of that was difficult to do, but it was a bit annoying that it was necessary, and it involved a lot of copy/pasting of the code. In general, they all calculate the rectangle size in the same way as UIStretch, but then all do different things with them. In future, I'm wondering if it's possible to have UIStretch be able to adjust these things as well as just the transform, or for it to be refactored in such a way that the code to calculate the scaling rectangle is more re-usable.

Also, it would be brilliant if stretching didn't have to happen every Update, but only when something external has changed (i.e. the window the game is running in, or the size of some object that the stretch is using as a reference). It would save a lot of unnecessary processing, although I admit that it doesn't sound easy to properly propagate the information that relevant reference points have changed.

jeldrez

  • Sr. Member
  • ****
  • Thank You
  • -Given: 8
  • -Receive: 4
  • Posts: 352
    • View Profile
Re: Feature request: More generalised UIStretch
« Reply #1 on: March 12, 2013, 03:20:24 PM »
  • UIAspectStretch - to stretch widgets (particularly non-sliced sprites) whilst maintaining their original aspect ratio (because using UIStretch alone, a sprite that looks normal on an iPhone will look squashed on an iPad because of the different aspect ratios)
Along time ago I was so close to posting a request for this, but I thought it could be done adjusting the 'Relative Size' on the UIStretch options. But I never could make it work.

I was using SlicedSprites when the windows is longer, but I think is not the best way either.

I think at least this one should exist. +1

electrodruid

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 48
    • View Profile
Re: Feature request: More generalised UIStretch
« Reply #2 on: March 12, 2013, 07:44:15 PM »
I should add: This is likely to only be an issue for people who have their UIRoot set to PixelPerfect - the FixedSize variants sidestep some (although not all) of these problems, which might be why these issues don't seem to be prevalent for many people, and yet I've run straight into them. However, there are good reasons for wanting to use PixelPerfect and to have everything work easily. In my case, I'm working with a very fastidious artist who wants to ensure that all of the sprites they create for the UI are pixel-perfect on all of the platforms we're supporting (because automatic rescaling can make the textures look muddier and less crisp). We know it means a bit of extra work in laying out the UI elements to be flexible enough to cope with such things, but I didn't realise that if you run with PixelPerfect, NGUI gives you automatic resolution-specific control over transforms in the form of UIStretch and UIAnchor, but not over any of the other things you might want to make resolution specific (panel clips, colliders, grids, and respecting the aspect ratios of individual elements)