Messages

1

NGUI 3 Support / Re: Slow frames when enabling panels with many widgets

« on: May 21, 2014, 09:41:17 AM »

This is an issue in our game as well on NGUI 3.5.7. At the root of every UI pop-up the player sees is a panel. Usually only 1 or 2 are visible at a time. We enable/disable the root of these panel/widget hierarchies to toggle visibility state.

When enabling one of these panels there is a huge spike on the CPU and many mono heap allocations. When enabled, our in-game store (simply sprites, buttons and text labels) causes a 1 to 2 megabyte mono heap allocation to occur. Our code doesn't allocate anything when this happens, it's just a gameobject.setactive operation. This isn't something that happens only once when the store is instantiated; it happens every time the user opens it.

In almost all of our panels the order of widgets never changes and no widgets are added at runtime to the prefab the UI was instantiated from. This seems like a common use case and something that should be fast.

I guess we can refactor the code to never disable these panels and just move them off camera when they shouldn't be visible but I agree with a previous poster... that solution seems like a hack.

2

NGUI 3 Support / Re: Transparent Texture with UITexture ?

« on: March 07, 2014, 07:22:10 PM »

Unlit/Texture is an opaque shader. Use a material with a shader that supports transparency.

You can either feed the UITexture component a material that is using something like Unlit/Transparent or feed the shader to it directly via the inspector.

3

NGUI 3 Support / Re: NGUI in front of Vectrosity

« on: March 07, 2014, 03:58:21 PM »

try setting the uipanel's renderQ value to something over 3000

This should work. We're using Vectrosity and NGUI together with the same camera with NGUI panels rendering on top.

4

NGUI 3 Support / Re: Prefabs and anchoring

« on: January 15, 2014, 10:41:00 PM »

We do essentially the same thing in our game when it comes to dynamically spawning UI prefabs. My advice - use more than one panel. In fact, depending on how your UI is setup and how many of your prefabs are visible at one time, consider using a separate panel at the root of EVERY prefab.

Adding a few draw calls is NOT going to kill your game's performance on modern hardware, including mobile. We're not on the iPhone 3G anymore.

5

NGUI 3 Support / Re: OnClick and private methods

« on: January 08, 2014, 01:22:14 PM »

I agree that in general Unity encourages making WAY too much information public in components. I also use the SerializedField attribute on all of my components when exposing data to the inspector so that the fields can be kept private if they are truly private data to the class.

I like this idea, @JosephFerano, but I wanted to mention another approach that you can follow to hide this information from the inspector. Simply, don't use the OnClick notification in UIButton and instead setup your event listeners programmatically using the UIEventListener class.

Example:

1. UIEventListener.Get(_targetButton.gameObject).onClick += gameObjectClicked =>
2. {
3.   // do something to respond to the event
4. };
5.  

On our team the guy who makes the UI prefabs doesn't write any code so he's not going to be setting up OnClick handlers in the inspector anyways. We find the programmatic approach works best for us. As another bonus for larger teams, it makes it easier for other programmers to see what is going on when looking at a code file they didn't write without having to instantiate a UI prefab and dig around in the inspector.

6

NGUI 3 Support / Re: Suggested change to UIPlayAnimation

« on: January 03, 2014, 04:48:56 PM »

I found a small bug in the update with more than one button using UIPlayAnimation in the same panel.

1. Click and hold down the left mouse over button #1 - animation played forward (good)
2. Drag off of button #1 - animation played backward (good)
3. Drag on top of a different button, button #2 - animation played forward on button #2 (debatable if this is good or not... in my opinion this should not occur)
4. Let go of the mouse button while hovering over button #2 - button #2 is stuck in the fully "forward" position, the animation doesn't play backwards on button #2 on OnPress(false)

I'm going to PM you my version of the file, a simple modification from 3.0.8f3, which doesn't have this behavior and will hopefully be useful reference. My modification may not cover all UIPlayAnimation trigger conditions but it does give me the behavior I'm looking for when using OnPress.

7

NGUI 3 Support / Re: Suggested change to UIPlayAnimation

« on: January 03, 2014, 01:10:03 PM »

Thanks, works great.

8

NGUI 3 Support / Re: Suggested change to UIPlayAnimation

« on: January 02, 2014, 01:27:11 PM »

I made a screen recording video with narration showing the behavior that I think should be changed. Hopefully this will explain it clearly.

https://dl.dropboxusercontent.com/u/2003612/UIPlayAnimationSuggestion.mov

~7.6mb

9

NGUI 3 Support / Suggested change to UIPlayAnimation

« on: December 31, 2013, 02:54:38 PM »

Hi there,

Currently if you setup a UIPlayAnimation component on a UIButton to trigger on OnPress, it will play its animation in reverse twice if you follow this sequence of events:

1. Click/Touch the button and hold down your mouse/finger.
2. Drag off the button - OnDragOut() is called and UIPlayAnimation plays the animation in reverse (good so far)
3. Release your click/touch - OnPress(false) is called and UIPlayAnimation plays the animation in reverse again

#3 is the problem - I don't think the animation should be played again here. It looks odd.

I've fixed this locally by simply adding a bool that tracks if OnDragOut() occurred after OnPress(true). If that bool is true, OnPress(false) does not play the animation in reverse again.

Is this something that should be integrated into NGUI directly? I can't think of a use-case for the current behavior.

10

NGUI 3 Support / Re: Font Scale per UILabel

« on: December 17, 2013, 02:33:29 PM »

We just upgraded from 2.7.0 to 3.0.7 and this change has caused a lot of visual problems for us as well. We are using bitmap fonts and want to set an explicit target glyph scale, like we used to be able to via the transform scale in 2.7.0.

Scaling the transform of the UILabel works but as JeremyBurgess said you then have to scale the size of the dimensions to compensate for it. This feels like a hack, especially after the push to hit a uniform 1 transform scale to allow NGUI widgets to be parented to one another, and it's something I'd prefer to avoid.

So +1 to re-adding this functionality as a property of UILabels for bitmap fonts. We love the new UILabel functionality but losing this is causing us a large amount of rework to address it in our project.

11

NGUI 3 Support / Re: My NGUI suggestions.

« on: March 28, 2013, 11:47:31 AM »

Attached is a quick and dirty port of SlicedTiledSprite to NGUI 2.5.0c / Unity 4.1. I moved the functionality into UISprite.cs to match the recent Sprite refactor.

I had to change how spritePixels and texPixels were calculated in SlicedTiledFill() to function correctly with our setup. To be honest, I don't know why I had to make the change to that code and I don't have time to research why.

I hope this is helpful for someone.

-Mark / shinyshoe.com