Messages

1

NGUI 3 Support / Re: Scrollview and Grid issue - empty space at top and bottom

« on: December 15, 2014, 07:08:38 PM »

Whoops, sorry I missed that you said that. Could you show us the scene hierarchy when it's populated? The content border is definitely not being set correctly (as you can see by the orange box). I'm thinking that maybe it's factoring in some sort of drag area widget?

2

NGUI 3 Support / Scrollbar not respecting CancelIfDragFits

« on: December 15, 2014, 06:33:46 PM »

Hi Aren,

I was looking into a problem today where if the scrollbars are set to always visible, and the content of a scrollview doesn't fill the content area there are some problems.

One is that the scrollbar will show the extra space on the content area.
Two is that the scrollbar will not respect the cancelIfDragFits property and will allow you to scroll the scrollview.

Could you update the code so that always visible scrollbars will respect this property and not allow scrolling internally?



If you make a code change can you post it here until the next version is available?

3

NGUI 3 Support / Re: Scrollview and Grid issue - empty space at top and bottom

« on: December 15, 2014, 06:02:37 PM »

Keep a reference to the scrollview and the layout view and then after populating the content perform the following.

gridReference.Reposition():
scrollReference.ResetPosition();

That should help reset the scrollview and grid view correctly.

4

NGUI 3 Support / Re: Onscreen Keyboard Disappears - Vodafone 785

« on: December 14, 2014, 06:06:08 PM »

Sounds like a Unity bug to me. I'd create a test case with TouchScreenKeyboard class in Unity and see if the problems persist with the keyboard disappearing after typing one character. If it is, submit the bug to Unity.

5

NGUI 3 Support / Re: Change UITexture runtime

« on: December 12, 2014, 08:26:59 PM »

Don't put the new texture directly into the material's mainTexture as it will not trigger a rebuild of the draw call for the UITexture (which keeps a duplicate material on the backend). My recommendation would be to userImg.GetComponent<UITexture>().mainTexture = fbProfileImage;
Setting the UI Texture's mainTexture property should trigger the change properly.

6

NGUI 3 Support / Re: How to avoid the cost by the Update() in UIRect

« on: December 10, 2014, 07:12:43 AM »

From what I'm seeing in the code there are only some flag checks and editor checks that are performed in order to determine if a UIRect.Update has any work to do. These are if the anchor is set to Update(), if the editor not in play mode, if the sprite/texture is set to fixed aspect, if the sprite is animating or if the sprite was changed. Most of these checks can be boiled down to a simple flag that is set on the widget to tell the panel that it needs to be re-evaluted for receiving the Update(). Then in the Panel's UpdateWidgets() it could re-evaluate the widget's update need and manage the list there for the widgets that need them. I could be wrong as well. Regardless, it's only a suggestion for Aren or whomever to consider.

7

NGUI 3 Support / Re: How to avoid the cost by the Update() in UIRect

« on: December 10, 2014, 06:09:05 AM »

Yeah, I just want to stress that the UIRect.Update is not insignificant. I was working on a pretty UI heavy game and had 4-6% of frame CPU for UIRect.Update() with 8-10% for the UIPanel.LateUpdate() without deep profiling. It is a problem that NGUI devs need to be aware of and to know how to reduce. Looking at the code the best option right now are to reduce the active UIRect count, reduce Update() anchor calls, and finally avoid fixed aspect ratio on sprites/textures.

Ideally, I would imagine that the the NGUI panel would keep a collection of all of the UIRects that needs to be updated and remove the ones that don't. Then there would be an Update() at the panel that calls the OnUpdate() on only the rects that need updates. This would reduce the per frame overhead associated with essentially unnecessary logic checks and Update() calls.

8

NGUI 3 Support / Re: Combining NGUI and Unity's LineRenderer

« on: December 10, 2014, 05:24:18 AM »

Yeah, I meant as long as the camera isn't culling out the renderer due to the culling layer mask is what to check. Make sure that the camera component includes the same layer as the layer that the line renderer is on.

Another thing to try would be is if you have a very controlled scene you can explicitly set the render queues on the UIPanels. By default transparent geometry is rendered in the 3000 queue. So if you setup a BG panel and set it to < 3000 and a FG NGUI panels > 3000 it should render the line renderer between the two properly. This doesn't help with the NGUIPanel clipping (which you would need to investigate those other solutions for), but it will help if all you need to do render some sprites in front or behind the line renderer.

Hope that helps.

9

NGUI 3 Support / Re: Force interface to middle monitor in 3 monitor setup

« on: December 09, 2014, 03:30:05 AM »

I recently worked on a problem similar so I might be able to help.

The solution I came up with is to move/adjust the viewport of Camera component that the UICamera uses. So if you support 16x9 as the widest aspect ratio and you have a constrained height you can determine what the camera's viewport should be based on the current Screen.width compared to the max UI width (Screen.height * (16/9)) to get the viewport percentages that you can input into the viewport rect on the Camera component.

Hope that helps!

10

NGUI 3 Support / Re: Combining NGUI and Unity's LineRenderer

« on: December 08, 2014, 01:26:26 AM »

Assuming that the renderers that you are using are in the correct unity layer it should render behind all of the other UI/Panel geometry by default.

If the problem is that the lines aren't being clipped properly by NGUI panels, you only have a couple of options.

• The best solution would be to create a simple NGUI Sprite based line renderer. Using sliced sprites I don't imagine it being too hard to get something working depending on your requirements.
• Use a different clipping mechanic such as a stencil buffer. (Now available for free users) However, this will require you to write some shaders to read/write into the buffer.

11

NGUI 3 Support / Re: Momentumless ScrollWheel?

« on: November 13, 2014, 09:47:27 PM »

Nevermind, I figured it out. Just ended up setting the scroll wheel factor to 0, and wrote a script to handle the Mouse ScrollWheel input for the scrollview.

12

NGUI 3 Support / Momentumless ScrollWheel?

« on: November 12, 2014, 03:11:24 PM »

Hello,

I was digging around the code for UIScrollView today because it was requested that the mouse ScrollWheel not have any momentum to it when it moves a ScrollView. From what I was able to determine it appears that the code for UIScrollView does a momentum shift on it regardless of the input Axis value received and the momentum value on the scrollview. I want it to work like a PC scrollbar where it will stop immediately after the scroll wheel stops moving.

Is there an easy way that I can turn ScrollWheel momentum off? (Ideally through existing properties so that it isn't overwritten via NGUI updates)

Also as an optimization, I noticed that you're using a mMomentum.magnitude check in the LateUpdate() where a mMomentum.sqrMagnitude should be fine.

13

NGUI 3 Support / Re: Odd anchoring bug occuring when parent panel is being animated

« on: October 22, 2014, 12:55:57 AM »

I've had situations similar occur. NGUI has some optimizations on widgets/panels that are too small or too transparent for it to care about. (i.e. When the scale is 0 or when the alpha of a widget is 0). In the scale problems, changing the tween from a starting value of 0 to a starting value of 0.01 seems to have helped. This might be what your problem is.

See if you can keep the widget from culling itself by having its alpha start at a very small number rather than 0. 

14

NGUI 3 Support / Re: Optimization: Can we set OnEnable to UIRect.updateAnchors as default value?

« on: October 22, 2014, 12:39:24 AM »

I do agree that OnEnable should be the default behavior of the anchoring system. If I have a couple dozen widgets all calling Update() it adds up, especially on mobile. From my tests, an Update() that does nothing is not as quick as a direct method call from a controller/manager. We avoid Update calls in all but the necessary controller scripts for this reason. I understand that OnUpdate is probably safer in regards to users getting the expected behavior, but I feel that having a runtime performance impact of Update() is more significant.

15

NGUI 3 Support / UIPanels no longer offset internal widgets

« on: October 10, 2014, 10:27:46 AM »

I just recently noticed that this was a new bug. However, there seems to have been some change in 3.7.4 behavior of the NGUI panels no longer changing the internal local positions of their children.

NGUI Panel (Soft Clip or Contrain but no clip)
--UIGrid
----Widget
----Widget
----Widget

If I anchor the panel to a widget that is anchored to the camera's bottom left, the UIGrid's position doesn't seem to update when I change the aspect ratio. As a work around I am adding a widget to the UIGrid object and anchoring that to the UIGrid's parent. Was this an intended change? Did anyone else notice this problem?

NGUI Version: 3.7.4
Unity Version: 4.5.4p3

Thanks!