Messages

1

NGUI 3 Support / Re: Serious question -- NGUI 3.0?

« on: March 24, 2013, 05:48:09 AM »

The real question for me is which direction offers the best performance, that was 50% of the reason I bought NGUI in the first place.
If there is better performance and the difference is enough to justify the work to migrate then it's worth it.
For any new projects being created, it's worth it.
If the difference isn't large, but there is some advantage beyond the ease of migration, it's worth it, IF there is a substantial discount for existing licensee's.

2

NGUI 3 Support / Re: NGUI as DLLs

« on: February 14, 2013, 07:18:22 AM »

Ahhh. Didn't realize there were a lot of platform switches in as well. I've only been working with Android and haven't had to delve too deeply into the source. That's understandable then. Thanks for your time Aren. Go ahead and close the topic.

3

NGUI 3 Support / Re: NGUI as DLLs

« on: February 13, 2013, 05:59:31 PM »

NGUI has platform-specific code inside (for example UIInput) which won't work if I compiled it as a DLL.

You can set the debug switches in the compiler options. just have to make sure for each compile it references the correct versions of UnityEngine.dll and UnityEditor.dll as well before compiling. As I said I've done it myself and it worked fine. I couldn't use them in my current project because it breaks the meta-data connections in the existing scenes and prefabs and it would be too tedious to set them all up again, but I definitely will in my next project because of the massive advantages in a 2-man 1 programmer team of simply updating DLLs instead of syncing the project folder. I don't even need to run Unity. Just have the artist download the latest DLLs from the git repository which saves us a licensing seat for Unity since only one person has to run it.

4

NGUI 3 Support / Re: NGUI as DLLs

« on: February 13, 2013, 05:53:33 PM »

We've had too much trouble with plugins as dlls, where we have had to wait for whichever plugin developers to get their act together and fix their shit. If NGUI changed to being compiled into dll's we would not use it anymore.

Not suggesting changing it, just including precompiled as well for convenience and allowing the compiled DLLs to be used as a re-distributable. The former being the cherry on a sundae since it has to be compiled twice to produce a set for 3.x and set for 4.x of Unity. The latter meaning the re-distributable has all of the power of the full package for scripts that rely on it as well as allowing external DLLs to reference it as a dependency.

5

NGUI 3 Support / NGUI as DLLs

« on: February 12, 2013, 07:02:14 PM »

It would be nice and make for easier upgrading if NGUI was also released as a pair of DLLs (One for \Plugins and one for \Editor) I've done this myself and it works just fine. As for people who are modifying the original NGUI scripts that can still be done in most cases by creating new classes that derive from the originals and override or add functions and events as necessary. This would also provide a way of having a project with a full featured re-distributable version of NGUI that is functionally identical but doesn't include any sourcecode.

6

NGUI 3 Support / C# Function to set properties and fields of NGUI components

« on: February 05, 2013, 07:20:26 PM »

Here is a method I have in my Utilities toolbelt. I use it from MonoBehaviours in external dll files to access properties and fields of NGUI widgets.

1. public static void GenericValueSet(object targetObject, string propName, object value)
2. {
3.         Type objectType = targetObject.GetType();
4.         PropertyInfo info = objectType.GetProperty(propName);
5.         if (info != null && info.CanWrite)
6.         {
7.                 Debug.Log("Setting property " + propName + " to " + value.ToString());
8.                 info.SetValue(targetObject, value, null);
9.         }
10.         FieldInfo finfo = objectType.GetField(propName);
11.         if (finfo != null && finfo.IsPublic)
12.         {
13.                 Debug.Log("Setting public field " + propName + " to " + value.ToString());
14.                 finfo.SetValue(targetObject, value);
15.         }
16. }

Feel free to remove the debug messages and shorten variable names, they are there for troubleshooting purposes when first getting used to using the method. I tried to make it as easy to read as possible.

7

NGUI 3 Support / Re: Best practice for very large grid of tiled sprites

« on: February 02, 2013, 06:44:15 PM »

Actually redhawk it's a 2.5d destruction game. The sprites aren't meant to be clickable and have box colliders on them for physics. I shudder to think what that many mesh colliders would do to framerate. 
Tried changing the shaders and it had zero effect Aren. Thanks for the suggestion though.
I guess I'll have to do the quadtree system after all and make it a sparse one, only updating data to changed elements.
Should be able to reduce drawcalls to below 10 but I was hoping NGUI would save some time in Blender.

8

NGUI 3 Support / Re: Best practice for very large grid of tiled sprites

« on: February 02, 2013, 03:07:29 PM »

Nope. There are 1024 x 256 sprites. Each of which is a 16x16 texture. I've got it to do that in the editor in 3 seconds if the hierarchy window is closed (It was causing the massive delay). To speed things up I was thinking of doing a quadtree and dynamically displaying the sprites as the scene scrolled but if NGUI is fast enough I'd rather just spawn at load and leave them there.
Oh and there are less than 200 (16pixel x 16pixel) textures in the atlas. Currently it's batching down to about 25 drawcalls (Since it never has all of the different sprite types onscreen at once). It's running at about 40 fps on a Galaxy Tab 10.1 for example, and I'd like to speed it up.

9

NGUI 3 Support / Best practice for very large grid of tiled sprites

« on: January 31, 2013, 07:58:17 AM »

What would be the best method to use (on mobile) to instantiate an array of 1024 x 256 sprites using NGUI?
I find after anything bigger than a chunk of 24x24 tiles of 2 triangle panels. I have to wait for 2 vsyncs to let the draw calls batch or it falls behind and the scene freezes after it's finished loading so it can catch up. Sometimes as long as a minute or more. I'm hoping there is a faster way to do this with NGUI.

10

NGUI 3 Support / Re: Cover Flow Style Scrolling Panel

« on: January 14, 2013, 11:25:33 PM »

If this is for a commercial project there may be trademark issues as well if it's being released in the U.S. market. Apple is a fairly litigious company and they have at least 2 trademarks on "Cover Flow" as a user interface design that I'm aware of.

11

NGUI 3 Support / Re: Enable GameObject on button click.

« on: October 01, 2012, 12:38:12 PM »

Actually it's short, not simple. It's simple if you already know about the NGUITools script and it's functions, but my artist can't be expected to know that. I just use Visual Studio and compile dll's with monodevelop while he uses Unity for the scene editing etc...

12

NGUI 3 Support / Re: Enable GameObject on button click.

« on: September 30, 2012, 10:49:45 AM »

Thanks for the help mate. I'm still surprised a simple GameObject Enable/Disable wasn't included in the package though.

13

NGUI 3 Support / Enable GameObject on button click.

« on: September 29, 2012, 10:17:11 PM »

I'd like a button to enable a GameObject and it's children when clicked.
Do I need to write a script for this and trigger it with the OnClick() event or am I missing something? It seems like a basic function that should already be in the system.

Also for some reason Screen.SetResolution(xxx,xxx,true) in the WebPlayer doesn't seem to work on my NGUI button. It's just ignoring the command. I've put Debug.Log messages in the same function so I know it's firing, but it's having no effect. Is there a setting in NGUI that I missed, that might be causing this behaviour?