Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - charliehelman

Pages: [1] 2
1
Couple hours of debugging under my belt, here are my findings:

Forcing unity to run at a target frame-rate of 5 frames. Long story short, we seem to run into an unexpected case in UICamera's ProcessMouse() function where Intput.GetMouseButtonDown and Input.GetMouseButtonUp are both evaluated true in the same frame. I'm not sure if this is a normal case, or even an edge case at a normal frame-rate.

The logic in ProcessTouch handles both pressed and unpressed inclusively. The logic for pressed starts a coroutine, but the logic for unpressed runs before that coroutine can continue, so (seemingly) the mSelectedObject and mNextSelection objects are garbage values by the time the coroutine has time to deal with them. And thus, the coroutine closes the popuplist at the end of the frame.

My current fix is simply to make unpressed always evaluate to false if pressed is true. However, I'm not sure if this is a good idea. It does cause the popups to work fine at the low framerate, and I wasn't able to find anything else that breaks due to the change (though I only tested briefly).

What do you think?

The code in UICamera's ProcessMouse() function, with my edit noted:
  1.         // Process all 3 mouse buttons as individual touches
  2.                 for (int i = 0; i < 3; ++i)
  3.                 {
  4.                         bool pressed = Input.GetMouseButtonDown(i);
  5.                         bool unpressed = Input.GetMouseButtonUp(i);
  6.                        
  7.                         if (pressed) unpressed = false; // CHARLIE'S (PROBABLY TERRIBLE) EDIT.
  8.  
  9.                         if (pressed || unpressed) currentScheme = ControlScheme.Mouse;
  10.  
  11.                         ... snip ...
  12.        
  13.                         // Process the mouse events
  14.                         ProcessTouch(pressed, unpressed);
  15.                         currentKey = KeyCode.None;
  16.                 }

2
NGUI 3 Support / UIPopupList closes immediately at low frame-rates (PC).
« on: January 16, 2015, 07:21:48 PM »
Hi Aren,

As suggested in the title, we discovered an issue where our Popup Lists close themselves right after being opened when the FPS drops below ~10 frames. Obviously, we're trying to fix the performance issues causing the game to run so sluggishly, but in the meantime I wanted to at least make sure you knew about the issue.

The affected popup lists happen to be for our graphical settings. We're finding users will set the options too high, then be unable to interact with the popup lists due to the ensuing framerate problems. Kind of hilarious, actually.

Anyway, have you encountered this before? Any ideas about working around it?

3
Beta 13, at the moment. We observed this in Beta 12 also; in fact it seemed fixed for a day or so after we upgraded to Beta 13.

Edit2: Nevermind. Re-serializing Assets popup does not guarantee a fix. And the same prefabs I said were fixed are broken again when I drag them into any scene. (Note the prefabs include everything, including the UIRoot)

Can I do anything else to help clarify the issue? If it's a unity bug I'll do what I can to get it reported and reproable.

This just seemed to fix itself (probably temporarily) when I closed Unity and restarted it, and was then presented with a popup window that said something about re-serializing assets (I think).

I've restarted Unity many times and had that not solve the issue, however. Maybe the re-serialization thing is a clue?

Unfortunately I'm not currently sure how to break it, or fix it. It just, does. :-/

Edit: Definitely worth noting that restarting unity only fixes for UIPrefabs currently in the scene. Applying changes to the prefab and saving the scene seems to make the fix stick (at least temporarily). However, I still see the problem with other prefabs, whether I drag them in to the same scene or if I encounter them normally at runtime.

4
1. Check the position of your UIRoot.
2. Make sure that only one camera can draw the UI.

1. UIRoot is at 0,0,0
2. This happens even in a fresh scene with only a fresh-made UI. Still, I verified that in all cases where I've seen it, only one camera can draw the UI.

5
Chiming in because I recently went through the upgrade process again.

No. It's probably not possible, and definitely not worth it. Unless you wanted to somehow go and rename all of the existing nGUI classes (for example UISprite-> UISprite_old), I guess. Even then, that's worrisome. Don't do that.

As far as upgrading the project: so many, many things have changed since 2.x, don't expect to be able to upgrade the project without nearly re-making every UI. Also, I'm not even sure the "upgrade from 2.x to 3.0" functionality is still bundled in the latest version of nGUI. I could be wrong though.

Back when 3.0 came out, we upgraded to it from 2.x. It took about two weeks to catch all of the big issues and resolve them, but even now I find things occasionally that were broken during that upgrade. And three weeks ago, we upgraded from 3.0.8 to 3.7.6. I'm still working overtime to fix issues / weird behavior.

If your deadline really is close, hold off and wait to upgrade until after you ship, if you can. I really recommend gritting and bearing it for now.

6
NGUI 3 Support / Re: Platform-independent UI that keeps aspect ratio?
« on: November 18, 2014, 07:34:40 PM »
I couldn't find anything in the patch notes specifically mentioning it, but I would guess 3.7.0. It's really just better naming. There's now also some pretty useful descriptions for each options right in the inspector, plus extra options like DPI scaling, "fit to width/height constraints", etc.

I recommend upgrading, if you can.

7
NGUI 3 Support / Re: Platform-independent UI that keeps aspect ratio?
« on: November 18, 2014, 05:07:11 PM »
FixedSize is the equivalent of Constrained in the older versions of nGUI. Try that.

8
Hi Aren,

Since upgrading from 3.0.8 to 3.7.6, we've started seeing problems where our UI doesn't show up on screen. Looking in scene view, panels simply aren't correctly lined up with our UI cameras.

The symptom looks like this, in a fresh scene (note, in a fresh project with only nGUI imported, I couldn't reproduce the issue).


In our project, it looks like this:


As you can see, something is very wrong.

Weirdly enough, restarting Unity *sometimes* fixes the issue. Sometimes it doesn't, though. And when it seems fixed, later on it breaks again for reasons I can't seem to understand.

Based on the symptoms, do you have any ideas about how I might go about fixing this problem?

9
NGUI 3 Support / Re: Anchor offsets changing inexplicably at runtime
« on: November 10, 2014, 11:38:52 PM »
Awesome, thanks for the clarification. I'll be hunting down our poorly used MakePixelPerfect calls with a vengeance. (Some of this code is 2+ years old.)

Thanks Aren.

10
NGUI 3 Support / Re: Anchor offsets changing inexplicably at runtime
« on: November 10, 2014, 09:57:52 PM »
I found another example of this and was able to fix it in this new case by removing any MakePixelPerfect calls affecting the Widget.

So it seems like with the latest version of nGUI, MakePixelPerfect will override/affect a widget's anchoring?

Maybe that's your intended functionality (I think it makes sense for most use-cases). I'm not sure why we're doing it in some of these cases; I'll work to remove these erroneous MakePixelPerfect calls as I find them, but in the original example posted above I haven't had any luck figuring out what is doing it to the battery (where we're calling MPP to it in the code).

Is there a way to work around this? Perhaps the Execute settings for the battery's anchor (OnUpdate, OnEnable, etc.) are the key?

Thanks for your time, Aren.

11
NGUI 3 Support / Anchor offsets changing inexplicably at runtime
« on: November 10, 2014, 08:29:51 PM »
Recently upgraded from version 3.0.9 to 3.7.6 and found that one of our UI elements has some very strange behavior during runtime.

Here's what the anchoring and sprite look like in editor. I've tried anchoring it a few different ways (normal offset or based off current position, for example).


However, at runtime this is what happens. Note how the battery is skewed. It's caused by the offsets you see in the inspector. If I reset those all back to the in-editor values, it looks fine.


I'm observing this in Unity 4.5.4f1.

It's worth noting that (as far as I can tell) we're not modifying anything related to this sprite's position / scale, or its parent's scale, besides calling MakePixelPerfect during initialization.

What could be causing this? As I mentioned above, this only started happening after upgrading to the latest version.

I would be *extremely* grateful for any help tracking down and solving this issue.

12
NGUI 3 Support / Re: Positioning Objects Relative to a Scaling Background
« on: February 20, 2014, 04:06:19 PM »
Why are you doing this at all? Why don't you just use anchors?

Can you provide an example where anchors would solve the problem with this use case? I've been working on a similar problem with no luck so far using anchors.

My problem is: I have a row of buttons that do not fit on iPhone 4 screens. Previously, the buttons were just anchored legacy style to the bottom left corner of the screen. Now, I need them to scale down in size so that all of the buttons fit on screen.

My thought was to make all the buttons a child object of a container (empty widget) or a panel, anchor that container so that it fits the screen correctly where the buttons should be, then I expected all the child objects to scale to fit inside that widget (because they're child objects, and... huh, as I type this I'm not sure I anchored the buttons to the container widget correctly. I'll try again, but had trouble getting this solution to work.)

Does that make sense?

Anyway, I'm sure the OP and I would both benefit from a quick example. I'll check back in once I give my idea another try (to verify I did it correctly before). Do I have the right idea? Is that what you meant by "just use anchors!"?

EDIT: In this case OP would just anchor his widgets to the "scaling background", which would make it work correctly as in this example: https://www.youtube.com/watch?v=P8JTTE0JBXQ

In retrospect, I must have anchored my buttons incorrectly. Let me give it another try and I'll check back.

13
NGUI 3 Support / Re: TweenPosition and new Anchors
« on: January 14, 2014, 10:26:57 PM »
UIRect.SetAnchor(null).

Cool! I was getting this error:
Quote
Assets/Scripts/UI/UIDisableAnchorAtRuntime.cs(12,24): error CS0121: The call is ambiguous between the following methods or properties: `UIRect.SetAnchor(UnityEngine.Transform)' and `UIRect.SetAnchor(UnityEngine.GameObject)'

I don't know how to feed null to a method any other way, so I just added an entirely new method to your UIRect script instead.

  1.     public void SetAnchorToNull ()
  2.         {
  3.                 leftAnchor.target = null;
  4.                 rightAnchor.target = null;
  5.                 topAnchor.target = null;
  6.                 bottomAnchor.target = null;
  7.                
  8.                 ResetAnchors();
  9.                 UpdateAnchors();
  10.         }

Works perfectly so far!

14
NGUI 3 Support / Re: TweenPosition and new Anchors
« on: January 13, 2014, 06:59:02 PM »
Haha!

Well, you're already going the extra mile by responding at all while on vacation. Thank you for that, good sir.

I'll survive until you are back. Meanwhile I'll see what I can figure out. Enjoy your time in Jamaica with the wife :)

EDIT: Okay, I've spent the whole evening digging around and I can't seem to find a way to disable a widget's anchoring (or set it to none) once the game is in play mode.

I looked in UIWidget and UIRect, but the solution didn't jump out at me. Anyone know?

15
NGUI 3 Support / Re: TweenPosition and new Anchors
« on: January 13, 2014, 03:59:15 PM »
I am building a iOS-app style UI where the layout needs to be responsive and stretch to fill the entire screen. It consists of a static top bar and then a series of pages below, which users swipe between. Only one page can fill the screen at a time.

The solution I'm considering is to have a horizontal scroll view that contain the pages. Currently I only have one page, but when I add more then each page will need to be contained inside and arranged by a UIGrid.

The scroll view is constantly anchored to the camera size; that's great and works perfectly.

The child object of the scroll view is an invisible widget (Page Container), which I stretch to fill the space underneath the top bar using anchors. The page elements for each page are child objects to each container, and are either anchored to each other or to the container edges.

So, the hierarchy is:

UI Root
--Camera
----TopBar (Panel)                              [Left and Right edges anchored to Camera Left & Right edges]
----ScrollView (Panel)                         [All edges anchored to corresponding Camera edges]
------PageContainer (Invisible Widget) [Left, Right, and Bottom edges anchored to Camera edges, Top edge anchored to Bottom edge of a TopBar sprite]
--------PageElement (Sprite)               [Anchors for page elements are dependent on the PageContainer dimensions]
--------PageElement (Sprite)
--------etc.

This makes the UI properly scale to fit my target screen sizes. However, if the Page Container's anchor is active at runtime, it obviously conflicts with the scroll view. This is the same problem described above when they were trying to tween objects that are anchored.

Setting the Anchor on the PageContainer to None after Start () will probably work. I'll see about doing that now and report back.

What do you think of this use case, Aren? Perhaps there's a better solution for this type of system?

Pages: [1] 2