1
NGUI 3 Support / Re: ETC1 breaks Atlas
« on: September 17, 2015, 12:46:53 PM »
I have had similar difficulties in the past and for those textures I chose no compression on the texture.
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.
2
NGUI 3 Support / Re: ETC1 breaks Atlas
« on: September 17, 2015, 12:37:12 PM »
I may be incorrect but I believe you need to change the texture(compression) you are using. It is not a shader issue but the compression on the texture.
3
NGUI 3 Support / Re: rendering stopped?
« on: September 17, 2015, 12:34:56 PM »
I am also having this happen. Once in a while (mostly device however a couple times on a pc where the pc was running very slowly) a uisprite in my case which is attached to a gameObject with a tween on it will not update its display. In the editor I have verified that the transform is correct. If is change any part of the transform (add .00001) it shows up.
My guess is that for some reason the sprite is not being recognized as dirty and redrawing itself.
I will post more if I find a solution.
Also anyone experiencing this - do you have a delay on the tween?
My guess is that for some reason the sprite is not being recognized as dirty and redrawing itself.
I will post more if I find a solution.
Also anyone experiencing this - do you have a delay on the tween?
4
NGUI 3 Support / Re: UITexture Being Converted to UISprite?
« on: February 17, 2014, 08:45:26 PM »
Please considering searching the forum for answers
please see this http://www.tasharen.com/forum/index.php?topic=6127.msg38222#msg38222
please see this http://www.tasharen.com/forum/index.php?topic=6127.msg38222#msg38222
6
NGUI 3 Support / Re: UISlider bug?
« on: January 17, 2014, 01:06:42 AM »
NP! Thanks. Glad that we were able to communicate and that I was able to finally describe this bug.
I have also discovered why the code was there. It prevents popping of the thumb after the user moves the first time. If the user grabs the side and begins to move the current code keeps it relative to that position. My way pops just slightly.
Possible Solution:
Hopefully this will help you, the problem boils down to the center of the thumb moves from one extreme to the other of the background. BUT the ScreenToValue only provides values within the extents of the background. So anything on either side of the thumb that is outside of the background extents will return min/maxed values.
Playing around with LocalToValue, i removed the Mathf.clamp01 and I think of all the "hack" I have tried this seems like it actually fixes the issue.
I have tested changing the size of the box collider, the size of the thumb, the collider on the thumb... all seemed to function correctly.
Basically this allows the ScreenToValue to return negative numbers. The value seems to clamp itself so in general I think this is the fix that doesn't break anything and fixes the issue. Especially since progressbar doesn't actually call this and scrollbar overrides it.
I have also discovered why the code was there. It prevents popping of the thumb after the user moves the first time. If the user grabs the side and begins to move the current code keeps it relative to that position. My way pops just slightly.
Possible Solution:
Hopefully this will help you, the problem boils down to the center of the thumb moves from one extreme to the other of the background. BUT the ScreenToValue only provides values within the extents of the background. So anything on either side of the thumb that is outside of the background extents will return min/maxed values.
Playing around with LocalToValue, i removed the Mathf.clamp01 and I think of all the "hack" I have tried this seems like it actually fixes the issue.
I have tested changing the size of the box collider, the size of the thumb, the collider on the thumb... all seemed to function correctly.
Basically this allows the ScreenToValue to return negative numbers. The value seems to clamp itself so in general I think this is the fix that doesn't break anything and fixes the issue. Especially since progressbar doesn't actually call this and scrollbar overrides it.
7
NGUI 3 Support / Re: UISlider bug?
« on: January 17, 2014, 12:16:12 AM »
So I loaded the tutorial 7 slider and it has the exact same problem
highlight "Slider - Horizontal" in the hierarchy
with the mouse select the far left of the thumb and drag left, Notice the value it doesn't reach zero.
Now grab the the far right of the thumb and drag right, it won't reach 1.
If you want to reach 0 or 1 you have to drag multiple times.
highlight "Slider - Horizontal" in the hierarchy
with the mouse select the far left of the thumb and drag left, Notice the value it doesn't reach zero.
Now grab the the far right of the thumb and drag right, it won't reach 1.
If you want to reach 0 or 1 you have to drag multiple times.
8
NGUI 3 Support / Re: UISlider bug?
« on: January 17, 2014, 12:00:38 AM »
im using the old widget wizard.
If I just add the uislider script and attach it up.
I have a zip of a project if I can give it too you?
If I just add the uislider script and attach it up.
I have a zip of a project if I can give it too you?
9
NGUI 3 Support / Re: UISlider bug?
« on: January 16, 2014, 11:48:56 PM »
the current one as of 3 days ago off of the bitbucket site
I just grabbed the latest again and and made a new project and create one and it has the same problem.
The larger the thumb the more problematic it is. If you select the thumb on the side you will be dragging it to and drag once it won't make it to the end. It requires several clicks to actually make it to the end.
I just grabbed the latest again and and made a new project and create one and it has the same problem.
The larger the thumb the more problematic it is. If you select the thumb on the side you will be dragging it to and drag once it won't make it to the end. It requires several clicks to actually make it to the end.
10
NGUI 3 Support / Re: UISlider bug?
« on: January 16, 2014, 10:57:09 AM »
I just created a default slider. (don't know if any of this is specific to the problem but just for exact duplication)
Empty was a sliced sprite 9x16 w/2 pixel borders
Full was a sliced sprite 2x2 with left/right 1 pixel boarder
Thumb was sliced sprite 160x50 with 18 pixel borders
Once added simply run and grab the extreme far right of the thumb and drag.
In the inspector you can see the Value and it won't reach 1.
If you click on the thumb on the left side and drag back to 0, it won't reach it on that side.
Including a pic.
clipboard1 shows the slider and where I am clicking for best reproduction results for moving right(to 1)
clipboard2 shows the same for moving left (to 0)
Empty was a sliced sprite 9x16 w/2 pixel borders
Full was a sliced sprite 2x2 with left/right 1 pixel boarder
Thumb was sliced sprite 160x50 with 18 pixel borders
Once added simply run and grab the extreme far right of the thumb and drag.
In the inspector you can see the Value and it won't reach 1.
If you click on the thumb on the left side and drag back to 0, it won't reach it on that side.
Including a pic.
clipboard1 shows the slider and where I am clicking for best reproduction results for moving right(to 1)
clipboard2 shows the same for moving left (to 0)
11
NGUI 3 Support / UISlider bug?
« on: January 15, 2014, 06:09:26 PM »
When I drag the foreground of a slide to an extreme, it doesn't reach the end, dependent on where the foreground is contacted.
On windows player if I create a horizontal slider whose value is displayed
and I use the mouse to touch the extreme far right of the foreground sprite and drag, the display value will never reach 1. On the other hand if I grab the foreground sprite anywhere left of center and drag the value will reach 1.
What I believe is the bug:
mOffset is set to a of value - ScreenToValue() which in the case where you are clicking to the right of center will be a negative number.
As you drag value is set based off of the new ScreenToValue + mOffset (which is negative) and since ScreenToValue will never return a value larger than 1, dragging the slider to the right will never result in reaching a value of 1.
Thus the bug: depending on where the foreground is grabbed directly effects whether the slider can reach min/max
POSSIBLE FIX: remove mOffset. Slider is able to be drug to the min/max
On windows player if I create a horizontal slider whose value is displayed
and I use the mouse to touch the extreme far right of the foreground sprite and drag, the display value will never reach 1. On the other hand if I grab the foreground sprite anywhere left of center and drag the value will reach 1.
What I believe is the bug:
mOffset is set to a of value - ScreenToValue() which in the case where you are clicking to the right of center will be a negative number.
As you drag value is set based off of the new ScreenToValue + mOffset (which is negative) and since ScreenToValue will never return a value larger than 1, dragging the slider to the right will never result in reaching a value of 1.
Thus the bug: depending on where the foreground is grabbed directly effects whether the slider can reach min/max
POSSIBLE FIX: remove mOffset. Slider is able to be drug to the min/max
12
NGUI 3 Support / Re: UIGrid bug - ConstrainTargetTobounds
« on: January 04, 2014, 12:02:31 PM »
Sounds good I appreciate you looking at this and confirming.
13
NGUI 3 Support / UIGrid bug - ConstrainTargetTobounds
« on: January 03, 2014, 01:16:33 PM »
On line 192/3 of UIGrid, A call to ConstrainTargetToBounds was added.
I believe this is an inaccurate addition. It breaks the concept of a grid and directly relates a grid to ANY parent panel. I believe a grid is used to align its children with respect to itself. *** I don't believe it should take any action to move itself ***
Here is the circumstances where it is being used and why it is breaking.
I use grid as I believe it should be used, to align children. Here is the hierarchy.
Panel
- GridEx (an extended grid class to use x number of children, rotating them so that you can display "infinite" number as the window scrolls.) May want to offer this in the future as it is extremely useful
- Inventory GameObject(there are multiple of these)
- Sprites/Text/etc
- Grid
- sprite
- sprtie
- ...
In this case I use the Grid which is under the Inventory GameObject to align its children sprites with respect to its parent gameobject. Here is where the problem arises, the grid itself changes it location to fit with in the Panel which is incorrect behavior. It doesn't seem like the Grid should do any repositioning of itself. It needs to remain in the location I placed it with respect to its parent.
Does this seem correct to you?
I believe this is an inaccurate addition. It breaks the concept of a grid and directly relates a grid to ANY parent panel. I believe a grid is used to align its children with respect to itself. *** I don't believe it should take any action to move itself ***
Here is the circumstances where it is being used and why it is breaking.
I use grid as I believe it should be used, to align children. Here is the hierarchy.
Panel
- GridEx (an extended grid class to use x number of children, rotating them so that you can display "infinite" number as the window scrolls.) May want to offer this in the future as it is extremely useful
- Inventory GameObject(there are multiple of these)
- Sprites/Text/etc
- Grid
- sprite
- sprtie
- ...
In this case I use the Grid which is under the Inventory GameObject to align its children sprites with respect to its parent gameobject. Here is where the problem arises, the grid itself changes it location to fit with in the Panel which is incorrect behavior. It doesn't seem like the Grid should do any repositioning of itself. It needs to remain in the location I placed it with respect to its parent.
Does this seem correct to you?
14
NGUI 3 Support / Re: UIInput Max char - Mobile keyboards don't respect setting
« on: July 12, 2013, 12:10:02 PM »
For those that are interested, if you change the order of two lines of code, it works
UIInput.cs ~ln 320 Function Update()
Switched to
What this does is UpdateLabel correctly sets the length of mText dependent on Max Chars.
Then you set that text back to the keyboard.
UIInput.cs ~ln 320 Function Update()
- if (mText != text) mKeyboard.text = mText;
- UpdateLabel();
Switched to
- UpdateLabel();
- if (mText != text) mKeyboard.text = mText;
What this does is UpdateLabel correctly sets the length of mText dependent on Max Chars.
Then you set that text back to the keyboard.
15
NGUI 3 Support / UIInput Max char - Mobile keyboards don't respect setting
« on: July 12, 2013, 11:10:31 AM »
If an input maxChar is set to say 10 and on either an IOS or an android the users types more than 10 characters, the native input accepts it but the UIInput doesn't. Is there any suggestion or ability to limit the keyboard input length?