Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - serioustommy

Pages: [1] 2
1
NGUI 3 Support / Re: UIPanel.IsVisible considerations
« on: May 01, 2015, 10:18:26 AM »
Sure I already considered that but the private fields in UIPanel makes it not possible.

I guess the next question would be why don't I just modify the NGUI source. We try to avoid modifying/branching any third party plugin just to avoid headaches merging and updating the plugins later on (I guess you've heard this one million times already). Obviously if we are doing major changes or refactoring to it then we'll do that but this change we feel is something that NGUI can incorporate very easily as an improvement.

Right now it just doesn't make sense that when checking a point it takes clipping into account but not when checking 4 points (a rectangle). Currently you need to read the source code to understand the distinction. Inconsistency is my key point here that makes the code as it stands more confusing than necessary.

2
NGUI 3 Support / UIPanel.IsVisible considerations
« on: April 30, 2015, 06:16:16 AM »
Hi,

There are a few overloaded UIPanel.IsVisible, and they currently don't seem to be consistent in their checking criteria.

For example, IsVisible (Vector3 worldPos) and IsVisible (UIWidget w) take clipping into account, whereas IsVisible (Vector3 a, Vector3 b, Vector3 c, Vector3 d) don't.

The one I really need is to be able to know if a point is inside a panel or not, regardless of clipping type. Right now I can work around it by calling IsVisible(a, a, a, a) and supply the same point in the 4 parameters but I'm hoping that we could have a safer and clear way of doing it since that particular overloaded method could be "fixed" in the future to have the same clipping check.

In any case I think all IsVisible should be consistent in what checks and early outs they do before actually getting to evaluate the points.

3
NGUI 3 Documentation / Re: UIWidget
« on: October 09, 2014, 06:27:03 AM »
But a "target" is needed for that. What is the target when I want the target to be the whole screen? Do I need to create a dummy transparent panel that resizes to represent the whole screen?

4
NGUI 3 Documentation / Re: UIWidget
« on: October 08, 2014, 12:19:22 PM »
I'm trying to replicate what I used to do in UIAnchor in UIWidget but it doesn't seem possible (at least not without some custom scripts).

Basically I'm just trying to anchor relative to the screen size like setting the "relative offset" values in UIAnchor. If we want to be able to anchor to the screen is the best practice now to create a dummy panel/widget and attach some custom script to resize it to fit the screen size?

5
NGUI 3 Support / Re: UIDraggablePanel Crash in Android
« on: October 29, 2012, 09:15:39 AM »
I'd just like to say that I got hit by this as well and soft clipping is what fixed it. Took me a lot of time to figure out though.

Unity didn't warn at compile time because the shader with clip instruction is only swapped in in real time when the draggable panel uses hard clipping.

I think a warning by NGUI in the console will save a lot of people headaches and time.  :)

6
yeah I thought about that Nicki but the thought of having to waste rendering time on a transparent sprite makes me feel dirty for some reason :) I know it doesn't cost much though so that's another solution.

Aren, the problem is that if you move or resize the clipping area of the panel the contents will end up being clipped in the wrong place. An example is that you want to leave a margin on the edge of the screen but you still want the contents to be clipped by the edge of the screen. Hence I thought a tweakable offset would be beneficial.

Again I'm just hoping that if it's supported officially I wouldn't have to apply my changes after every update. Not a big issue though. Thanks for being a good support.

7
NGUI 3 Support / feature suggestion: UIDraggablePanel bound offset
« on: June 15, 2012, 01:52:41 PM »
Currently the bounds for the content within a UIDraggablePanel is the union of the bounds of all the widgets within it. However this means that the content will always spring back so that the edge of the content aligns with the edge of the UIDraggablePanel's clipping box, without any space in between.

I've added a very simple offset support for modifying the bounds in UIDraggablePanel if anyone is interested:

  1. public float    boundTopOffset;
  2. public float    boundBottomOffset;
  3. public float    boundLeftOffset;
  4. public float    boundRightOffset;
  5.  
  6. public Bounds bounds
  7.         {
  8.                 get
  9.                 {
  10.                         if (!mCalculatedBounds)
  11.                         {
  12.                                 mCalculatedBounds = true;
  13.                                 mBounds = NGUIMath.CalculateRelativeWidgetBounds(mTrans, mTrans);
  14.                                
  15.                                 // apply bound offsets
  16.                                 Vector2 min = mBounds.min;
  17.                                 min.x -= boundLeftOffset;
  18.                                 min.y -= boundBottomOffset;
  19.                                 mBounds.min = min;
  20.                                
  21.                                 Vector2 max = mBounds.max;
  22.                                 max.x += boundRightOffset;
  23.                                 max.y += boundTopOffset;
  24.                                 mBounds.max = max;
  25.                         }
  26.                         return mBounds;
  27.                 }
  28.         }
  29.  

Perhaps something similar can be added to the official release as well, if there's a cleaner way of handling this.

8
NGUI 3 Support / disabling UIImageButton
« on: May 29, 2012, 12:09:05 PM »
Currently UIImageButton still responds to mouse events even when it's disabled. Is it possible to do the same fix as UIButtonScale, or is there a reason for this? Thanks!

9
NGUI 3 Support / Re: localization support for csv file?
« on: May 29, 2012, 09:53:09 AM »
I would really rather not make changes to NGUI classes, just to avoid future headaches when updating. Imagine having to keep track of 10 little changes like this and having to double check them to see if they are overwritten by NGUI's update every time.

Maybe the next update can include your second change so that it supports both? Thanks for the suggestion though.

10
NGUI 3 Support / Re: localization support for csv file?
« on: May 29, 2012, 09:09:54 AM »
Well I could also easily change the separator in ReadDictionary from "=" to "," but I'd rather not break compatibility to NGUI from future updates with little changes here and there. Maybe we need a simple pluggable reader that we can inject into NGUI for custom formats?

11
NGUI 3 Support / localization support for csv file?
« on: May 29, 2012, 05:43:36 AM »
I thought spreadsheet is a convenient way for working with localized strings. Since csv is one of the default output from google doc wouldn't it be nice to have NGUI parse that directly? I know it's easy to just replace all the "," with "=" but when you have 6 languages and multiple changes a day it does get a bit tedious.

Or perhaps I just need to look into how to write a google plugin that outputs the correct format...

12
Ah thanks that works.

However instinctively I thought the clipping region should only be moved when "Reposition Clipping" is clicked, and not when ResetPosition() is called which I thought should just reset the position of the contents. Maybe a ResetContentPosition() that does just that in the future? Just a suggestion :)

thanks again for the help.

13
yeah just updated to 2.07 this morning in fact.

So if I don't call ResetPosition then the clipping rectangle stays the same. The only problem is just that the added widget won't be in the correct default position. So basically I'm just looking for a way to reset the position without the clipping region getting moved.

14
Thanks for the reply.

What you said makes sense to me, but it seems like ResetPosition changes x even if scale x has been set to 0. Could that be a bug? I tried calling ResetPosition both before adding the dynamic widgets as well as after but it doesn't seem to make a difference.

Here's a few images which might help:

Before adding widgets to the panel:


after adding widgets to the panel, notice the pink rectangle moves to the right so it aligns with the left side of the widgets:


mouse over the second button causing the button to be clipped on the left (notice that the red rectangle is now outside of the pink):


Thanks again for any help you can provide!

15
I don't really understand but there's probably a reason why by calling ResetPosition it attempts to move the clipping region of the UIPanel.

However I need to be able to reset the draggable content positions after adding them to the panel without modifying the panel's clipping region. Since the contents are buttons that scale up when moused over, the buttons then go out of the moved clipping region causing them to be clipped. They also get moved in the x axis even though the x scale is set to 0 just so they get moved back into the clipping region.

Is there anyway to add a boolean parameter to ResetPosition so it leaves the clipping region alone?

Pages: [1] 2