Messages

1

NGUI 3 Support / Suggestion for UISpriteAnimation

« on: May 24, 2016, 07:17:40 PM »

I recently needed to have a number of animated sprite objects that used the same looped animation appear side-by-side, but also needed for them to not appear to be identical. I accomplished this by adding a "SetFrame" method to your UISpriteAnimation class that simply changes the value of "mframe" to a specified index. That amounted to three lines of code that allow a UISpriteAnimation to start playing at a different frame. The addition allowed me to alter which frame the animated sprite started at, and made the multiple sprites appear to present different animations using identical frame data.

I really think this is a method that should be added to the UISpriteAnimation class going forward. Currently there is no way to specify the frame on which the animation playback commences. I understand that it's an edge-case issue, but it really is just a few lines of code that extends the functionality of the class in a significant way.

2

NGUI 3 Support / Use of "foreach" loops in NGUI

« on: June 27, 2015, 10:01:24 PM »

Hey there!

There's a long-standing and well documented bug in the version of Mono that Unity 4.x is using which results in a memory leak in "foreach" loops (as I understand it, each iteration burns 24 bytes of RAM). I've been cleaning up my app to eliminate those leaks, but there seem to be a few in the NGUI code. While I'm not concerned by memory leaks in the editor tools, it'd be awesome if any foreach loops in NGUI's runtime code could be addressed.

While this may be a non-issue with Unity's switch to IL2CPP, it remains a problem for apps that are locked to a pre-Unity5 dev environment (to be fair, I'm not even sure that Unity5 has actually switched to the IL2CPP system - I'm locked at version 4.6.x for my current project, and it's not clear if they've actually "pulled the trigger" on that change).

I can certainly tweak the version of NGUI I'm using to remove the foreach loops, but it would be more optimal if they were removed from the NGUI distribution. My understanding is that foreach is less efficient than simple "for" loops, so swapping them out might also provide a small performance improvement.

Just a suggestion - if it's something do-able then that would be fantastic. If not, I can do my best to sort it out.

An FYI - I just want to say that NGUI is pretty freakin' amazing. It's not easy to sort out initially, but once you understand the relationships between panels, depths, and so on, it's a near perfect toolkit for building GUIs. It's awesome!

                    Nick

3

Misc Archive / Re: Seeking a 3D Artist

« on: October 30, 2014, 07:14:33 PM »

What are you looking for? You've not clarified - Is your goal to have a bunch of components like Kerbal Space Program? If so, can you supply the specific details of how the components are connected? Building 3D elements that connect together is not simple, and really requires a clear understanding of the underlying code that connects the components.

Have you established consistent connections between components? If I wanted to add a thruster to a command module is there a way to do that? Can I instead connect a cargo module to that same location?

Not wanting to sound negative, but the brief is really vague and as a 3D artist I'm a bit baffled about what you're trying to accomplish.

If you can more clearly explain what you're trying to accomplish then that would be good. At present your goals are unclear and, as a consequence, unachievable.

                        Nick

4

NGUI 3 Support / Re: NGUI and CPU Load

« on: October 30, 2014, 01:02:14 PM »

Nope. There are only 3 anchors, all of which are set to run only on 'enable'. There are however a LOT of separate bits that don't need to update at the full frame rate. I spent a lot of time making everything as efficient as possible before I resorted to reducing update frequency as a last resort.

5

NGUI 3 Support / Re: Buttons Not Communicating Trigger Events

« on: October 30, 2014, 12:45:19 PM »

The mouse button / fake touch events are being polled from "Input", but "Input" is reporting that the mouse/touch event is false.

See lines 1485-1487 in UICamera. For some reason the query responds with false/false regardless of physical inputs (this was equally true in both the editor and on IOS devices).

It's not NGUI's fault - it's something strange happening in Unity that I've been unable to isolate. Fortunately I can use the name of "hoveredObject" to detect that an event is occurring over a button based on it's prefix.

I tried every permutation of setting prior to digging into NGUI's guts to tack down what was actually going on

6

NGUI 3 Support / NGUI and CPU Load

« on: October 29, 2014, 08:00:08 PM »

I've been working on my game for quite a while now, and when I finally pulled the trigger and became a Unity Pro dev I discovered a hugely disconcerting issue when I fired up the profiler. NGUI was the single biggest CPU consumer in my code. Yikes!

So here's what I did to mitigate the amount of overhead that NGUI was adding to my app.

1. Only Make NGUI Elements Active When They Need To Be
- You can parent widgets under different NGUI panels. If the widget is static (not animating, not scaled, not moving) then keep it parented under an NGUI panel that is tagged as static/unmoving. If the element needs to become dynamic (it has to scale or animate or whatever) then either have a transitory element that replaces the static element which is parented under a dynamic panel *OR* move the static element from a static panel to a dynamic panel for ONLY AS LONG as it needs to update. Then switch back to, or move, the static element back to the static panel.

- Changing the parent is somewhat CPU intense, but it's far less intense than leaving the element parented to a dynamic panel, and you can use a simple local script to swap parents based on the timeout of an effect.

2. NGUI wants to update every component on every frame. That turns out to be a huge amount of overhead.

- If you're using NGUI for UI in a game with high-speed updates then it's chewing up a LOT of CPU. There's no default mechanism that lets you control how often NGUI updates panels - as written it updates on every frame and there's no way to change that behavior.

- My solution was to tweak NGUI's code so that you can choose to disable the per-frame updates and restrict widget updates to 1/16th of a second (which is the minimum of human persistence-of-vision). This change improved my overall frame rate from 15FPS to 60FPS on current IOS hardware. Wow!

- I also set the update time to an initially random period so that updates to specific panels wouldn't occur on the same frames (mostly, since the random period is... well... random). Thus far, things are distributing fairly evenly and working well.

If you're using NGUI this info hopefully helps you get your project running faster. Fingers crossed that some of these optimizations find their way into products in the future

                        Nick

7

NGUI 3 Support / Buttons Not Communicating Trigger Events

« on: October 29, 2014, 06:52:05 PM »

A couple of days ago I upgraded from the March version of NGUI and suddenly my buttons stopped working during screen fade in/out events.

After a lot of investigation this seems to be a problem that's resulting from Unity providing invalid responses to touch/input events. While I can't find the precise cause of NGUI getting bogus input states, I was able to work around the issue by identifying my input objects within the NGUI code and forcibly setting the click-state to true when one is encountered. Yeah, I had to hack the NGUI code to deal with this.

Basically I've added a check to NGUI that says "if a collsion object has a specified prefix then ALWAYS treat it as being a valid collision (button press)". Doing this has eliminated the non-responsive button issue, but only works because I went to the effort of insuring all my button GameObjects had "bt" prepended to their names.

So, likely a Unity issue, but certainly one that everyone should be aware of.

                                   Nick