Messages

1

NGUI 3 Support / Re: UIDraggableCamera alternate

« on: April 26, 2018, 11:13:48 AM »

Bump! 
So, to get our stuff to work with the "can't believe it still exists" UIDraggableCam I made the changes mentioned above:
If (enabled == false) return;
at the start of Press(), Drag() and Scroll()

I also made a similar change to UIDragCam, checking if the draggable cam was enabled before moving forward:
// if (enabled && NGUITools.GetActive(gameObject) && draggableCamera != null)
// the above was changed to below
if (enabled && NGUITools.GetActive(gameObject) && draggableCamera != null && draggableCamera.enabled)

My question is if these two files are still on the permanent non-supported list, in which case I'd rather just take our changes versions and move it into our own stuff instead of updating the files every NGUI update. 
Thanks!

2

NGUI 3 Support / UILabel line break/formatting

« on: October 02, 2017, 10:53:44 AM »

We're using a UILabel to display some text info about our game.  We've got it anchored so it forces the Overflow to Shrink Content, which works fine most of the time but we're not happy with the way the line breaks sometimes.  For example, this is one of those cases:



What we want to be able to do is avoid the situation where the 2nd line is very short compared to the top line, so it looks cleaner.  I was going to start looking into ways to detect how many characters were after a line break, but when I tried that it turns out there weren't any.  I looked at the UILabel component and sure enough the string for that above is this:
"we would like to be able to not have the line split here"

(minus the quotes of course). 
Is there some other way that we can find out where the line break appears in the string, or is there perhaps another formatting trick we could try?  Remember this is anchored because we're supporting multiple screen resolutions and will eventually support multiple orientations as well.
Thanks!
-Mo

3

NGUI 3 Support / Re: Strange behavior with advanced anchors

« on: July 25, 2017, 07:32:51 AM »

Well the question was why does the object animate to it's position when it's not set to left justify.  We got the issue solved but we're not sure why.

4

NGUI 3 Support / Re: Strange behavior with advanced anchors

« on: July 21, 2017, 01:45:08 PM »

UPDATE: So my boss took a look and figured out that to stop the Pink widget from animating, you set it's anchor to left.  And for the right side Dark Blue widget set the anchor to right.  I'm not exactly sure why this works but we're going with it for now.  Is there reason why this works?  Seems like a good op to learn more about the nuts 'n bolts of NGUI.
Thanks!

5

NGUI 3 Support / Strange behavior with advanced anchors

« on: July 21, 2017, 01:05:29 PM »

We're sorting out our multiple aspect ratio issues and came across a weird effect of anchors. I've set up a simplified scene to show off exactly what the issue is so don't mind the Atari 2600 looking art.
The scene is a rectangular blue widget (Menubar) with two square widgets (Pink, Dark Blue) anchored to it's sides.  There's also a white rectangle which represents where these objects are supposed are supposed to be for this aspect ratio, so when the scene starts the Menubar widget's size and transform's position get set via copying the values from the white rectangle, then the anchors are supposed to take care of the two side objects.  We need those two objects on the side to always be anchored to the sides and remain square. 



The way I set up the Pink anchor is I anchored it's left side to the Menubar left, it's top and bottom to Menubar top and bottom, then left the right anchor blank and set the Aspect value on the widget to be Based on Height, which gave me what I needed.



I did the same thing for the Dark Blue but anchored the right instead of left. As you can see in the image above, it looks fine, and changing aspect ratios in the editor looks fine as well.  The issues begin when the scene actually starts or gets loaded at runtime (I've tested this on devices as well).  What's happening is that while the squares end up where they are supposed to be, they don't snap there right away like all the other anchors I've used (and i've used plenty heh).  What happens is that it animates into position over about a half a second. Not much, but certainly noticeable.  The only thing I can think of that's causing it is that missing anchor, because when I anchor all sides to Dark Blue, it doesn't give me the position I need but it does happen automatically.



I've taken a video of what happens when i start the scene and as you can see the Dark Blue square snaps immediately but to the wrong spot, while the Pink square goes to the right spot it just animates. Neither one is what we're looking for.

https://www.youtube.com/watch?v=77P9P8e1v0g&feature=youtu.be

So what I'm wondering is either a) how to get the behavior we need another way or b) stop the animation part for happening.

Any help appreciated!  Thanks!
-Mike

6

NGUI 3 Support / Re: UIDraggableCamera alternate

« on: July 18, 2017, 08:57:05 AM »

Excellent, modifying it to our hearts content is what we did!  Well, by that we did exactly what you mentioned and just put the check for the enabling.  It's literally just

1. If (enabled == false) return;

in the Press(), Drag() and Scroll() functions.
If that's all you are going to do (or equivalent) then I'll just keep an eye out for the next update and make sure it all works and then hopefully we can get back to our 100% not tweaking the NGUI source heh.
Thanks!  I'll keep an eye out and keep you informed.
-Mike

7

NGUI 3 Support / Re: UIDraggableCamera alternate

« on: July 11, 2017, 02:16:11 PM »

Oh BTW what I meant in a) above as far as "just do what we need" I mean since it's so legacy could we have free reign to modify UIDraggableCamera and UIDragCamera as much as we want without ever worrying about it getting updated by you?  If so, then we could be in much better shape than I thought we were even before discovering the UIDraggableCamera/UIDragCamera archaicness.
Thanks!

8

NGUI 3 Support / UIDraggableCamera alternate

« on: July 11, 2017, 01:47:19 PM »

OK so our entire control system for the main part of our puzzle game was a combination of UIDraggableCamera, UIDragCamera and SpringPosition.  We were having a weird issue where we wanted to shut off the dragging, but shutting off the UIDraggableCamera didn't do it.  Checked the UIDragCamera code and it doesn't check to see if the UIDraggableCamera is active before calling it's code.  So I went to the forums to find some tips and I discover all sorts of posts about "I don't know why UIDraggableCamera exists" and "UIDraggableCamera is from NGUI 1" etc etc etc.  We've put a TON of time into this system before discovering this, and TBH it's worked out ok for us for the most part.  However, we do need to sort out this issue so I'm wondering if

a) We can just do what we need with UIDraggableCamera and UIDragCamera since they'll never be updated again or
b) We have some sort of alternate solution that won't require us to rewrite our entire control system (we did a ton of stuff on top of the NGUI stuff to get the functionality we wanted).

Any tips appreciated, I hope we didn't waste a TON of time.

-Mo

9

NGUI 3 Support / FitOnScreen but adjusts size, not position

« on: April 11, 2017, 12:04:30 PM »

We're handling all movement and camera zooming with in our game by adjusting the camera, not any objects themselves.  Now I've gotten good at being able to adjust the camera's position to get a transform to be at a certain spot, and I noticed that in NGUITool you have a bunch of FitOnScreen functions.  However, both what I'm doing and what FitOnScreen does is adjust the camera's position, what I need is to be able to get a transform to a certain point just by adjusting the orthographic size.  That might sound sketchy, but our game is a puzzle game that will always have a playing area of a perfect square (thanks to UIGrid heh).  However, the # of cells per side might change.  The grid could be 15x15, 13x13, 20x20.  The cells will always be the same size, but we need to know at what orthographic size to set the camera so that all the elements will fit exactly.  So far, in both Unity and NGUI, I've not seen anything that can accomplish that.  What I've done so far is a crazy, inefficient loop that just tries different sizes until I get what I need (upperLeftPosition is the position at the upper left corner of the first square in the grid):

1. float size = 1f;
2. while( size < 1.3f )
3. {
4.         puzzleCamera.orthographicSize = size;
5.         Vector3 wtv = puzzleCamera.WorldToViewportPoint( upperLeftPosition );
6.         Debug.Log( "wtv: " + wtv2.ToString("0.0000") + ", size: " + size);
7.         size += .0001f;
8. }

At orthographic size 1f, the WorldToViewportPoint is at (-0.1113, 1.1113, 0.0000).  Turns out that an orthographic size of 1.222737f is what I need to get that point to (0,1,0).  Is there any way to calculate what size directly with any NGUI tools or code?  Or is it some simple matrix thing that I haven't learned yet?
Or perhaps there is no way? 
Thanks!
-Mo

10

NGUI 3 Support / Re: Sprite sharpness

« on: April 11, 2017, 10:58:33 AM »

Will give it a shot.
Thanks!!!
-Mo

11

NGUI 3 Support / Sprite sharpness

« on: April 07, 2017, 01:18:59 PM »

I've been fiddling around with shaders all day and can't seem to figure out how to get my sprites to be as sharp as the source material.  In our game, we have very simple black and white squares in a grid.  I'm using this image as the source for the sprite.



However, when I put the UISprite in the game, there's fuzziness around the edges.  It gets more pronounces as we zoom in (zooming is a big part of our functionality).
Here's a single sprite zoomed in:



And when I make a grid of them, with the grid spacing matching the size of the squares exactly, there's little breaks in between the cells.
Here it is with no zooming:



Here it is zoomed in:



Like I said I've been messing around with shaders and can't seem to find anything that makes the squares as sharp as the source material. Is there something else I'm missing that could help out with this?
Thanks!
-Mo

12

NGUI 3 Support / Re: UIRoot behavior with orientation changes

« on: March 23, 2017, 09:45:29 AM »

Excellent, we've been moving forward.
Thanks!
-Mo

13

NGUI 3 Support / UIRoot behavior with orientation changes

« on: March 09, 2017, 11:51:48 AM »

We plan on supporting all aspect ratios and orientations for our project.  We've gotten the basics down on how to use all the NGUI stuff, but what we were curious about was how the UIRoot deals with orientation changes.  For example, right now our UIRoot is set to 1024x768, Contrained, and both "Fit" buttons are unchecked.  So if we're working on a screen that's at that size, positioning a UISprite at 0,-768 will position the sprite at the bottom of the screen with the bottom half cut off (pivot is all centered).  That makes sense since the screen height is 768.  However, when we switch to Portrait mode, the screen size is now 1024, but to get the sprite positioned at the bottom, you don't set the Y to -1024, you still set it to -768.  I'm sure there's lots of behind the scenes that explains this but it's a bit confusing for laying stuff out, especially with our less technical staff members who want to set up things at the bottom of a Portrait screen but the numbers don't make sense in the current orientation.
What we were thinking of doing is (both at edit time and run time) if an orientation change is detected, we'd update those numbers accordingly.  So in landscape it's 1024x768 and in portrait it's 768x1024, so the layout positions would make more since.
However, since we're still not 100% sure how the UIRoot works behind the scenes, we were wondering if doing this is a horrible idea, a great idea, and what the reasons would be either way.  We're going ahead with testing this but please let us know if there's any reason why this would be bad.
Thank you!! 
-Mo

14

NGUI 3 Support / Re: Scroll Bar Functionality Breaks With 2D Colliders

« on: February 08, 2017, 09:53:03 AM »

Awesome, thank you!
-Mo

15

NGUI 3 Support / Re: Scroll Bar Functionality Breaks With 2D Colliders

« on: February 07, 2017, 05:46:25 PM »

OK I did discover something that sorts this out, but it involves changing NGUI source files and I really don't want to commit to this, but I think it could be a bug.  In NGUITools.cs in the UpdateWidgetCollider (BoxCollider2D box, bool considerInactive) function, the code currently is this:

1. Vector3[] corners = w.localCorners;
2. box.offset = Vector3.Lerp(corners[0], corners[2], 0.5f);
3. box.size = corners[2] - corners[0];
4.  

I took the code from the 3D collider version and changed it to this

1. Vector4 region = w.drawingDimensions;
2. box.offset = new Vector3((region.x + region.z) * 0.5f, (region.y + region.w) * 0.5f);
3. box.size = new Vector3(region.z - region.x, region.w - region.y);

This gets the expected behavior where it doesn't matter if it's 2D or 3D colliders, the foreground collider will always match the sprite. 
Now the fact that this could break who knows what is the reason I'm not going to commit to this, but I wanted to try and help see if it could get to a more formal solution.
Thanks!