Messages

31

NGUI 3 Support / 3.5.8 Old-Style Localization Bug

« on: April 21, 2014, 11:02:47 AM »

Hi ArenMook,

I noticed that there is a bug when using the old key=value localization approach. In the SelectLanguage() in UILocalize it only checks the "new" dictionary instead of mOldDictionary. So, we should also probably check the old dictionary size before cleaning up and returning null.

I think it should check both, maybe something similar to this:

1.         static bool LoadAndSelect (string value)
2.         {
3.                 if (!string.IsNullOrEmpty(value))
4.                 {
5.                         if (mDictionary.Count == 0 && !LoadDictionary(value)) return false;
6.                         if (SelectLanguage(value)) return true;
7.                 }
8.  
9.                 //NEW - If we have loaded an old dictionary we are OK here too
10.                 if(mOldDictionary.Count > 0) {
11.                         return true;
12.                 }
13.  
14.                 // Either the language is null, or it wasn't found
15.                 mOldDictionary.Clear();
16.                 mDictionary.Clear(); //NEW - We should probably clear the new dictionary too
17.                 if (string.IsNullOrEmpty(value)) PlayerPrefs.DeleteKey("Language");
18.                 return false;
19.         }
20.  

Are you planning on removing the Key=Value localization in the future? Our games can use thousands of keys and loading all of the languages associated with these keys in the dictionary would use unnecessary RAM and increase the size of the GC heap (thus reducing GC performance). Keeping the lower overhead Key=Value suits our needs better, but if it's going to be inevitable I guess I'd like to know so we can go through the process now.

32

NGUI 3 Support / UITweener.Play Implementation Question

« on: April 16, 2014, 05:39:39 PM »

Hi Aren,

We're using your tween library a lot in our game, which seems to be working pretty well except for a situation that occurs sometimes. When we are using a tween's PlayForward and PlayReverse we sometimes run into situations where the mFactor not being reset when calling PlayForward or PlayReverse would cause the tweens to sometimes not play because the first update would think that it is already done. This would occur in situations where you call PlayForward and then call PlayForward again. It would not start from the beginning but rather just immediately terminate.

Is there a reason why the UITweener's mFactor is not reset in the Play() method like so?

1. public void Play (bool forward)
2. {
3.         mAmountPerDelta = Mathf.Abs(amountPerDelta);
4.         if (!forward) mAmountPerDelta = -mAmountPerDelta;
5.         mFactor = (mAmountPerDelta < 0f) ? 1f : 0f; //NEW CODE HERE
6.         enabled = true;
7.         Update();
8. }
9.  

Without that I found us doing things like this which ended up rather ugly.

1. mTweenVisible.PlayForward(); //Need to put the delta amount in the correct direction
2. mTweenVisible.ResetToBeginning(); //Reset the mFactor
3. mTweenVisible.PlayForward(); //Now play through correctly
4.  

33

Misc Archive / Re: Our game, with extensive NGUI UI, now available on all mobile platforms

« on: April 16, 2014, 05:23:12 PM »

Hey it looks pretty good! Thanks for sharing!

Although as an engineer myself, I would argue that separating the engineer away from the design/art is often a bad idea for workflow. Granted, a designer should come up with the basic needs, but I feel that it is often in the engineer's best interest to actually be a part of the design process of the UI so that he can provide optimization tips/recommendations to the artist. Also nudging the design to be a little more reusable is also always good. Also pushing the design to fit within the already created NGUI components/restrictions is always a plus. Otherwise you end up with 60 similar dialogs instead of 1 dialog that is more modular. Maybe it is just the artists that I have worked with in the past, but most do not think of the optimizations (slice9, flipping half sprites, fill rate, etc.) or maintenance (Dialog/view reuse) that is often critical for successful UIs.

Edit: We might want to move this thread to the Developer's Cave forum.

34

NGUI 3 Support / Re: About a better way to update NGUI

« on: March 31, 2014, 07:23:28 PM »

We use GIT and this is not a problem since there is only a .git at the parent level of the repository. In fact with GIT it will recognize that the files are virtually the same and keep the revisions.

I haven't used SVN since I switched to GIT, but don't new versions of SVN also just keep a single root level .svn folder?

35

NGUI 3 Support / Optimization Tweaks?

« on: March 31, 2014, 03:58:23 PM »

Hi ArenMook,

We're doing an optimization pass on our game and there were a couple things that I was seeing that might be candidates for optimization.

Currently in UICamera 1239 there is an alloc that is happening every frame due to:
inputHasFocus = (mCurrentSelection != null && mCurrentSelection.GetComponent<UIInput>() != null);
It's appearing as a 0.6KB GC alloc in the profiler. Would it be possible to check/remember the current selection's input by doing that check only when the selection is changed in Changed Selection? It appears that ProcessTouch/Mouse() methods set mCurrentSelection directly, but I'm wondering if they could go through the ChangeSelection coroutine and then only check for UIInput if a new selection was made?

My UI as a whole is consuming about 10% of my CPU frame time:
6% UIPanel.LateUpdate
3.1% UIRect.Update
1% UICamera.Update

These aren't awful by any means, but I notice that you were using the standard Update() on the UIRect. In the profiling tests that I've done, directly calling a MyUpdate() from a manager object is faster than relying on Unity's Update() call (which I would assume is using a slower reflection call). Since all widgets are managed by a UIPanel in the sense of draw calls, would it be possible to have each panel call a MyUpdate() on the widgets instead of relying on a Unity's Update()?

If I'm misinformed, please let me know.

36

Misc Archive / NGUI for UE4?

« on: March 21, 2014, 06:25:10 PM »

Like most people, I am extremely tempted to do more research into Unreal Engine 4 with their new pricing model. I am a UI guy and spend a majority of my days in NGUI. I briefly looked at UE4's UI (SLATE) and had me realizing just how easy I have it with NGUI and Unity. I was wondering if ArenMook might consider making an NGUI for UE4 and releasing it on the Marketplace? Knowing that there was a tool as great as NGUI waiting for me on the otherside would be great.

I realize that most people would want to have Scaleform (GFx) integration for UE4, but I've never been a big fan of Scaleform (DIE FLASH DIE!). However, there doesn't seem to be a great indie UI solution for devs on UE's side?

37

NGUI 3 Support / Re: Do you need Unity 3 support?

« on: March 13, 2014, 10:34:30 AM »

All of my projects are on Unity4. However, I agree that you should just be very clear about it in the release notes and here that support will be ending. I'm sure some users will stomp their feet about their Unity3 projects, but it's not like Unity is supporting/updating Unity3 at this point. The old version of NGUI won't just stop working either. I think the bigger issue for dropping Unity3 support is that an old version of the plugin would still need to be supported. Either as a separate unitypackage (similar to the 2.7 upgrade tools) in the main download or another way would be important for these users for awhile.

38

NGUI 3 Support / Re: Build warning: Shader is using clip instruction....

« on: February 27, 2014, 02:14:40 PM »

Shaders from NGUI shouldn't be using the clip() anymore due to this warning. Instead I believe that they just make it alpha transparent. I'm pretty sure that this was changed before the 3.0 transition so I'm surprised you still have those shaders in your project still. I'd upgrade your project to the latest version of NGUI. There are performance improvements that you can take advantage of. Also, you will not get any support unless you're running the most up-to-date version.

39

NGUI 3 Support / Re: 3.5.1 Bitmapped UIFont Corruption

« on: February 26, 2014, 09:00:35 PM »

We'll just use dynamic fonts until 3.5.2 is ready.

Curious, I haven't used bitmapped UIFonts in awhile, but did you remove the ability to have the font OFF the atlas and on its own material at some point? I think that it still might be useful for some use cases? Was there a reason why it was removed or am I missing the way to do that?

Also just a friendly reminder that UIFont needs a documentation entry in the documentation forum too. So if you're refactoring it, it might be a good time to get that written if there is a new system incoming.

Thanks!

40

NGUI 3 Documentation / Re: Localization system

« on: February 26, 2014, 08:54:29 PM »

I hope you don't get rid of the old key = value formatting because it works for some projects better than having all of the languages in the same file. If you're like us and have a potentially gigantic string table and don't want to keep all of the strings in memory for every language. Could you try to include the mechanics for loading the old style of languages as well in the documentation? You can delete this post after you do.

If you want to use the old localization format. You can having a .txt file in the resources directory that is the same name as you set to Localization.language. So if you have a English_US.txt file located in the Resources directory you can load this string table by setting the language: Localization.language = "English.US";

ProTip: If you don't want to put the language at the root level of the Resources directory you can set the language to be the filepath to the resource such as: Localization.language = "Strings/English_US";

41

NGUI 3 Support / 3.5.1 Bitmapped UIFont Corruption

« on: February 25, 2014, 08:07:37 PM »

Thanks for your continued work on NGUI. I updated our in-development project from 3.4.9 to 3.5.1 and we're having a problem.

I'm experiencing what appears to be a bug with bitmapped UIFonts (old school). It appears that when I make a UIFont that appears on the Atlas it will initially work, but when I rebuild the atlas for any reason the bitmapped UIFont will have corrupt UV coordinates. The only way to fix this is to delete the UIFont object and remove it from the atlas and rebuild and recreate the UILabels? Can you see if you can reproduce?

Thanks!

42

NGUI 3 Support / Re: Dynamic Localization Possible?

« on: February 03, 2014, 05:49:10 PM »

In your localization file make the string something like this:
StringKey = {0} attacks for {1} damage!

Then when you use that string use something like the following:
LabelText.text = string.format(Localization.Localize("StringKey"), Attacker.Name, amtDamage);

This should produce something like "Ranger attacks for 3 damage!" if the name was Ranger and the amtDamage variable was 3.

43

NGUI 3 Support / Re: mac & windows different colors?

« on: January 10, 2014, 06:12:35 PM »

Could be a monitor calibration issue. Macs have a different gamma setting on their monitors than the typical Windows setting which could cause things to look different on a Mac than Windows. Recalibrate your monitor using a 2.2 Gamma via System Prefs > Display and see if that helps.

44

NGUI 3 Support / Re: 3D UI Anchor Question/Problem

« on: December 19, 2013, 03:11:35 PM »

I ended up just using the old UIAnchor script to anchor to the 3D camera and it didn't have this limitation. Which is fine, but felt like it might be worth looking into so the new anchoring system could work in a perspective camera. Unless I'm anchoring it incorrectly. I found if the panel's z-depth from the camera isn't 1/2 the clip difference it will not anchor to the camera's edges consistently as the aspect ratio changes.

45

NGUI 3 Support / 3D UI Anchor Question/Problem

« on: December 18, 2013, 03:00:29 PM »

I'm trying to get a 3D UI setup in NGUI. However, I want to have static 2D UI on this 3D camera as well in the corners to allow me to have a 2D overlay in my 3D camera. I don't really need another 2D UI in the scene (at least I don't think I do). However, I'm basically just trying to figure out how to properly anchor sprites using a 3D UI system.

I have the following scene
UIRoot/Panel
--UICamera (perspective 3D camera)
----TopLeftPositionedSprite (Anchored to UICamera top left)

The problem appears to be that if the z depth isn't 0.5 of the camera's clip plane the calculations are off. It seems that the anchor system depends on this by the following code:

1. Mathf.Lerp(cam.nearClipPlane, cam.farClipPlane, 0.5f)
2.  

There seems to be a lot of this in the code for determine World or Viewport points. So I'm curious if we need to position anchors with 3D do we need to make sure that the UIWidgets are in a z-space that is exactly 1/2 of the camera's near/far clipping depth in order to get these elements positioned properly? Is this a known limitation? Wouldn't it make more sense to get the depth of the object by performing a target.position.z - camera.position.z?